Cómo aprender rápidamente a programar microcontroladores
Especificaciones de programación en lenguaje ensamblador de MCU
El diseño de software es más un proyecto que un arte personal. Si los estándares de programación no están unificados, la legibilidad del programa final será deficiente.
Esto no sólo obstaculiza la comprensión del código, aumenta la carga de trabajo en la fase de mantenimiento, sino que también oculta código no estandarizado. La posibilidad de errores también es relativamente alta. El análisis muestra que entre los errores generados en la etapa de codificación, los errores gramaticales representan alrededor del 20%, mientras que los errores causados por no verificar estrictamente la lógica del software y los errores de interfaz entre funciones (módulos)
Y los errores causados por errores las modificaciones de código durante la fase de optimización y mantenimiento debido a la baja inteligibilidad del código representan más de la mitad. Se puede ver que para mejorar la calidad del software, debemos reducir la tasa de error en la etapa de codificación. ¿Cómo reducir eficazmente los errores en la etapa de codificación? Esto requiere formular especificaciones detalladas de programación de software y capacitar a cada programador. El resultado final puede reducir los errores en la etapa de codificación a aproximadamente 10 y al mismo tiempo reducir el costo de probar el programa.
Este artículo se centra en cuatro aspectos: mantenibilidad del código (legibilidad, comprensibilidad, modificabilidad), lógica y eficiencia del código, interfaz de función (módulo) y capacidad de prueba.
Lo anterior describe la programación de software. especificaciones Las especificaciones se dividen en dos tipos: reglas y sugerencias. La parte de reglas es un elemento de implementación obligatoria, mientras que la parte de sugerencias no es obligatoria y se puede elegir según los hábitos.
1. Composición tipográfica
Regla 1
Utilice sangría para bloques de programa, espacios para funciones y etiquetas, y una combinación de TAB y espacios para segmentos de programa. El propósito de la sangría es hacer que la estructura del programa sea clara y más fácil de leer y comprender.
El ancho predeterminado de lt;TABgt; debe ser de 8 espacios. Dado que lt;TABgt; en Word tiene 4 espacios, para una demostración clara, se utilizan 2 lt;TABgt;
Por ejemplo:
MOV R1, #00H
MOV R2, #00H
MOV PMR, #PMRNORMAL
MOV DPS, #FLAGDPTR
MOV DPTR, #ADDREEPROM
read1kloop:
read1kpage:
INC R1
MOVX A, @DPTR
MOV SBUF, A
JNB TI, $
CLR TI
INC DPTR< / p>
CJNE R1, #20H, lectura1kpágina
INC R2
MOV R1, #00H
CPL WDI
CJNE R2, #20H, read1kloop; FINAL DE EEPROM
Regla 2
Utilice espacios para separar los operandos de las instrucciones. El propósito de escribir código de esta manera flexible es hacer que el código sea más claro. .
Por ejemplo:
CJNE R2, #20H, read1kloop; FINAL DE EEPROM
Regla 3
Escribe como máximo una declaración por línea.
Regla 4
Al definir variables, mantenga la alineación. Fácil de leer y comprobar el uso de la memoria.
Por ejemplo:
RegLEDLOSS EQU 30H VARIABLE;
TESTLED==RegLEDLOSS.0
RegLEDRA EQU 31H VARIABLE; p >
RUNLED_Flag EQU 32H;
Cambia el estado de RUNLED una vez cada 256 ms
RUNLED_Def EQU 10H;
Cambia el LED una vez cada 16*32ms=500ms Estado
2. Comentarios
El principio de los comentarios es ayudar a leer y comprender el programa. Los comentarios no deben ser demasiados ni muy pocos. No favorecen la comprensión del código y demasiados comentarios interferirán. lectura.
Por lo tanto, agregue comentarios sólo cuando sea necesario, y los comentarios deben ser precisos, comprensibles y lo más concisos posible. El número de comentarios generalmente se controla entre 30 y 50.
Regla 1
El programa debe tener comentarios cuando sea necesario, y los comentarios deben ser precisos, comprensibles y concisos.
Por ejemplo, los siguientes comentarios tienen poco significado:
MOV DXCE1COUNTER, #00H; asigne DXCE1COUNTER a 0
Los siguientes comentarios brindan información adicional útil Mensaje:
JNZ PcComm_Err; si hay error de verificación
Regla 2
Los comentarios deben ser similares al código que describen y los comentarios sobre el código deben colocarse arriba o The la posición adyacente a la derecha (comentario para una sola declaración) no se puede colocar debajo. Si
se coloca arriba, debe estar separado del código que se encuentra arriba por una línea en blanco.
Regla 3
El encabezado de los archivos de encabezado y de los archivos fuente debe estar comentado. Los comentarios deben incluir: nombre del archivo, autor, propósito, función, registro de modificaciones, etc.
Regla 4
El encabezado de la función debe estar comentado, enumerando: el propósito y función de la función, parámetros de entrada, parámetros de salida, variables generales y registros involucrados, y otras funciones llamadas
Y módulos, registros de modificaciones, etc. Para algunas funciones complejas, es mejor proporcionar el uso típico en los comentarios.
Regla 5
Comente la función y la intención de segmentos de código importantes para proporcionar información útil y adicional. Y agregue una línea de comentarios al final del segmento de código para indicar el final del segmento de código.
Regla 6
Para todas las constantes, variables y declaraciones de estructuras de datos (incluidas matrices, estructuras, clases, enumeraciones, etc.), si sus nombres no se explican por sí solos, add Cada comentario debe
ser comentado para explicar su significado.
Regla 7
Al mantener el código, actualice los comentarios correspondientes y elimine los comentarios que ya no sean útiles. Mantenga la coherencia en el código y los comentarios para evitar malentendidos.
3． Naming
Regla 1
Abreviatura del identificador
Varias técnicas para formar abreviaturas:
1) Eliminar todos los elementos que no estén al principio de las letras fonéticas de la palabra. Por ejemplo, pantalla se escribe como scrn y primitiva se escribe como prmv.
2) Utiliza la primera letra o letras de cada palabra. Por ejemplo, Channel Activation se escribe como ChanActiv y ReleaseIndication se escribe como RelInd.
3) Utilice cada palabra con un significado típico en el nombre de la variable. Por ejemplo, Count of Failure se escribe como FailCnt.
4) Elimina sufijos de palabras inútiles como ing, ed, etc. Por ejemplo, la Solicitud de paginación se escribe como PagReq.
5) Utilizar abreviaturas estándar o habituales (incluidas las abreviaturas que aparecen en el documento del acuerdo).
Como BSIC (Código de identificación de estación base), MAP (Parte de aplicación móvil).
Pautas sobre abreviaturas:
1) Las abreviaturas deben ser coherentes. Por ejemplo, Channel no debe abreviarse como Chan a veces y C
h a veces. La longitud a veces se abrevia como Len y otras veces como len.
2) Agregue anotaciones al encabezado del código fuente para describir abreviaturas no universales relacionadas con el protocolo.
3) La longitud del identificador no debe exceder los 12 caracteres.
Regla 2
Convención de nomenclatura de variables: lt; prefijo gt; comentario
La nomenclatura de variables debe ser simple, intuitiva y no fácil de confundir.
El prefijo es opcional e indica el tipo de variable. Dado que la mayoría de las variables en ensamblado son variables de un solo byte, no es necesario prefijar las variables de un solo byte para los tipos de bit y doble byte.
p>Las variables se representan con byd minúsculas como prefijos.
El cuerpo principal es una opción obligatoria. Se pueden combinar varias palabras (o abreviaturas). La primera letra de cada palabra está en mayúscula y el resto en minúscula.
Regla 3
Denominación de constantes
Reglas de nomenclatura para constantes: todas las letras de la palabra deben estar en mayúscula y cada palabra debe estar separada por guiones bajos.
Regla 4
Nombre de las funciones
La primera letra de la palabra está en mayúscula y el resto en minúscula. El nombre de la función debe comenzar con un verbo, es decir, el nombre de la función debe ser similar a un predicado verbal o una oración imperativa.
Por ejemplo: Test_Protect, Check_EEPROM, Init_Para
4. Mantenibilidad
Regla 1
El código que está estrechamente relacionado con funciones y procedimientos es lo más cercano posible.
Regla 2
En principio, el número de líneas del programa fuente para cada función debe ser inferior a 200 líneas. Para la función de procesamiento de descarga de mensajes, las funciones completadas están unificadas, pero debido a la variedad de mensajes, puede exceder el límite de 200 líneas, lo que no constituye una violación de las regulaciones.
Regla 3
El nivel de anidamiento de declaraciones no excederá los 5 niveles. Demasiados niveles de anidamiento aumentan la complejidad del código y la dificultad de las pruebas, son propensos a errores y aumentan la dificultad del mantenimiento del código.
Regla 4
Evite que el mismo fragmento de código aparezca en varios lugares. Cuando es necesario reutilizar un fragmento de código en diferentes lugares, se deben utilizar llamadas a funciones o llamadas a macros, según el tamaño del segmento de código. De esta manera, las modificaciones al segmento de código se pueden completar en un solo lugar, mejorando la mantenibilidad del código.
Regla 5
Cada función completa una única función y no diseña funciones integrales y multipropósito. Una función que integra varias funciones puede dificultar su comprensión, prueba y mantenimiento.
Aclare la función, aumente la legibilidad del programa y facilite el mantenimiento y las pruebas.
Regla 6
En el documento de mantenimiento del proyecto de la función se deberá señalar la plataforma de hardware y la versión a la que es aplicable el software.
Recomendación 1
Utilice una función de inicialización especial para inicializar todas las variables públicas.
5. Corrección y eficiencia del programa
Regla 1
El uso de variables no inicializadas está estrictamente prohibido. Las referencias a variables no inicializadas pueden tener consecuencias impredecibles. En particular, las referencias a punteros no inicializados a menudo provocan fallos del sistema, por lo que se requiere atención especial.
Regla 2
Evita que las operaciones de memoria se salgan de los límites.
Nota: El funcionamiento de la memoria fuera de los límites es uno de los principales errores en los sistemas de software y las consecuencias suelen ser muy graves.
Regla 3
Preste atención al rango de valores válido de las variables para evitar que las expresiones se desborden o no se desborden.
Regla 4
Evita errores ortográficos confusos en instrucciones y operandos.
Regla 5
Evita declaraciones innecesarias en funciones para evitar código basura en el programa. El código reservado debe aparecer en forma de comentarios. El código basura en el programa no solo ocupa espacio adicional, sino que a menudo también afecta la función y el rendimiento del programa, lo que probablemente cause problemas innecesarios en las pruebas y el mantenimiento del programa.
Regla 6
Mejorar la eficiencia del espacio mejorando la división y organización de las estructuras de datos del sistema y optimizando los algoritmos del programa. Este enfoque es la solución fundamental para la eficiencia del espacio de software
.
Regla 7
Se minimiza la carga de trabajo dentro del bucle. Se debe considerar cuidadosamente si las declaraciones dentro del cuerpo del bucle se pueden colocar fuera del cuerpo del bucle para minimizar la carga de trabajo dentro del cuerpo del bucle, mejorando así la eficiencia del tiempo del programa
.
Regla 8
En bucles múltiples, coloque el bucle más ocupado en el nivel más interno.
Regla 9
Evite las sentencias de juicio contenidas en el cuerpo del bucle y mueva las sentencias de juicio que no estén relacionadas con la variable del bucle fuera del bucle. El objetivo es reducir el número de sentencias. Si las sentencias de juicio en el cuerpo del bucle se pueden mover fuera del bucle depende de las circunstancias específicas del programa. En términos generales, las sentencias de juicio que no tienen nada que ver con las variables del bucle se pueden mover fuera del bucle. , mientras que
No es posible.
Regla 10
Interrupción y recuperación
Las rutinas de interrupción deben ser lo más breves posible, marcadas en la interrupción y procesadas en el programa principal. Las excepciones incluyen segmentos de programas con alto rendimiento en tiempo real.
Todas las variables generales y registros involucrados deben guardarse durante la interrupción, como A, PSW, DPTR, etc.
Regla 11
Configuración de la pila
La pila es muy importante para el programa y la configuración de la pila debe ser razonable. Si la pila es demasiado pequeña, es fácil que se desborde durante las llamadas anidadas, lo que provocará fallos en el sistema; si la pila es demasiado grande, se desperdiciarán recursos de RAM; Para ahorrar recursos de la pila, es necesario no ahorrar demasiados recursos al interrumpir, y el número de niveles de anidamiento de interrupciones y de anidamiento de programas no debe ser demasiado, trate de no exceder los 5 niveles. Esto requiere una división razonable de los módulos funcionales.
Regla 12
Watchdog
El circuito de vigilancia se utiliza para restablecer automáticamente el microcontrolador cuando falla. El microcontrolador necesita enviar pulsos al perro guardián con regularidad, lo que comúnmente se conoce como "alimentar al perro". No alimente al perro con demasiada frecuencia, de lo contrario el perro no tendrá ningún efecto como perro guardián; no lo alimente demasiado lentamente, ya que esto fácilmente hará que el microcontrolador se reinicie. La correcta alimentación de los perros debe realizarse en el circuito principal. Lo mejor es instalar un sistema independiente para controlar el proceso. No se puede alimentar al perro en una interrupción programada porque a veces el microcontrolador puede morir en el circuito principal.
6． Interfaz
Regla 1
Elimine las variables públicas innecesarias y utilice las variables públicas lo menos posible durante la programación. Las variables públicas son una de las razones para aumentar el acoplamiento entre módulos, por lo que se deben reducir las variables públicas innecesarias para reducir el acoplamiento entre módulos. Se deben construir variables públicas que solo un módulo o función pueda modificar o crear, y otros módulos o funciones relacionadas solo puedan acceder a ellas para evitar que múltiples módulos o funciones diferentes modifiquen y creen la misma variable pública. *** El fenómeno de las variables.
Regla 2
Al pasar datos a variables públicas, evite los fenómenos fuera de límites. Al asignar valores a variables públicas, se deben realizar verificaciones de legalidad si es necesario para mejorar la confiabilidad y estabilidad del código.
Regla 3
Intente no diseñar funciones multiparamétricas, elimine los parámetros no utilizados de la interfaz, reduzca la complejidad de la interfaz y reduzca la complejidad de la interfaz entre funciones.
Regla 4
Maneja los códigos de retorno de las funciones que llamas cuidadosa y minuciosamente. Evite que los errores se pasen a flujos de procesamiento posteriores. Si intencionalmente no verifica su código de retorno, esto debe indicarse claramente.
Regla 5
Compruebe la validez de todos los parámetros de entrada de la función de interfaz.
Regla 6
Verifique todas las entradas no paramétricas de la función, como datos externos, variables públicas, etc.
7. Capacidad de prueba del código
Regla 1
Los módulos deben escribirse teniendo en cuenta consideraciones de prueba completas.
Regla 2
Las pruebas de código deben diseñarse en el código fuente.
Antes de escribir código, se deben diseñar de antemano los métodos y medios para la depuración y prueba del programa, y se deben diseñar varios interruptores de depuración y los códigos de prueba correspondientes. La depuración y prueba del programa es una etapa muy importante en el ciclo de vida del software. Se ha vuelto muy importante cómo probar el software de manera más completa y eficiente y descubrir los errores en el software tanto como sea posible. >
Preguntas clave. Por lo tanto, antes de escribir el código fuente, además de tener un plan de prueba relativamente completo, también se deben diseñar una serie de métodos de prueba de código para facilitar las pruebas unitarias, las pruebas de integración y la depuración conjunta del sistema.
Regla 3
En el mismo grupo de proyectos o grupo de productos, debe haber un conjunto unificado de interruptores de depuración y funciones correspondientes preparadas para las pruebas de integración y la depuración conjunta del sistema, y debe haber descripción detallada.
Esta regla es para grupos de proyectos o grupos de productos.
Regla 4
Dentro del mismo grupo de proyecto o grupo de producto, el formato de la cadena de información impresa durante la puesta en servicio debe ser coherente. La cadena de información debe contener al menos el nombre del módulo (o nombre del archivo fuente)
y el número de línea. El formato unificado de información de depuración facilita las pruebas de integración.
Regla 5
El código de depuración debe eliminarse del producto de software oficial (es decir, los interruptores de depuración relevantes deben estar desactivados).
Regla 6
Utilice el interruptor de depuración para cambiar entre la versión DEBUG y la versión oficial del software, en lugar de tener archivos fuente diferentes para la versión oficial y la versión DEBUG al mismo tiempo. al mismo tiempo para reducir el mantenimiento
p>Dificultad.
Regla 7
La configuración y cancelación de métodos de prueba relevantes en el sistema de software no afectará las funciones implementadas por el software. Es decir, el software con código de prueba y el software con código de prueba desactivado deben tener un comportamiento funcional coherente.
Regla 8
Los errores deben corregirse inmediatamente y registrarse si es necesario.
Regla 9
Los desarrolladores deben insistir en realizar pruebas exhaustivas (pruebas unitarias) del código y no confiar en otros o grupos de prueba para encontrar problemas.
Regla 10
El código limpio, organizado u optimizado debe ser revisado y probado.
Regla 11
Las actualizaciones de la versión del código deben someterse a pruebas estrictas.
8. Compilación de código
Regla 1
Active todos los interruptores de advertencia del compilador y compile el programa. Evite ocultar alertas potencialmente erróneas.
Regla 2
Algunas declaraciones generarán advertencias después de la compilación, pero si cree que es correcta, debe eliminar la información de advertencia de alguna manera. Sigue el estudio estandarizado y sistemático y en un futuro próximo también serás un maestro.