Estructura elegante para codificar sistemas embebidos en C

3

Algunas preguntas sobre el estilo de codificación eficiente utilizando C:

Estoy trabajando en controladores PIC de 8 bits usando C. Me gustaría saber algunas cosas sobre el estilo y la estructura de la codificación.

  1. He leído que mantener un archivo de encabezado es un buen estilo de programación. Pero para segmentar funciones con bastante facilidad para la depuración y el desarrollo futuro, ¿podemos conservar más de 2 archivos de encabezado? O, ¿es propenso al error? Confío en que la creación de archivos de encabezado y la declaración de prototipos de funciones eliminarán la declaración extern en cada uno de los archivos fuente relacionados al hacerlo. (es decir, eeprom.h, data.h)

  2. ¿Es una buena práctica mantener todas las variables en un archivo de encabezado separado? Además, ¿cómo maneja las variables que se necesitan en más de un archivo fuente?

pregunta Rookie91

2 respuestas

2

Respecto a la pregunta 2: Las variables no deben definirse en un archivo .h. El propósito de un archivo de encabezado es declarar las funciones "públicas" y la estructura de datos utilizada en un archivo C, para que otros archivos C sepan cómo llamarlos / usarlos. Por definición, un archivo de encabezado se incluirá varias veces en un proyecto completo. Es por eso que los archivos .h no deben contener ningún código, o este código se duplicará (en realidad, la mayoría de las veces esto causa un error de compilación). El único caso en el que una variable debe declararse en un archivo .h es una variable global compartida a través de varios archivos C, en ese caso la variable está definida en uno de los archivos C y se declaró como extern en el archivo .h.

Acerca de las variables globales: la razón real por la que las variables globales no son tan buenas es porque evita que el código que lo usa sea reentrante. Eso significa que el código no será compatible con recursividad ni con subprocesos múltiples. En un PIC de 8 bits con una pila ridículamente pequeña, ninguna de esas técnicas tiene sentido, por lo que las variables globales no son tan malas. Sin embargo, es una práctica común evitar las variables globales cuando puedes, el código es más fácil de leer / depurar / reutilizar de esa manera.

    
respondido por el martinm
1

El estilo de programación depende de la persona y de los estándares de codificación que esté siguiendo.

Prefiero los archivos de cabecera modulares. Cada módulo, digamos EEPROM, tendrá EEPROM.h, e incluso si el módulo EEPROM se extiende a través de los archivos, trato de usar un solo archivo de encabezado. Aunque se vuelve difícil pero lo intento. Además, solo las funciones public están declaradas en el archivo de encabezado, mientras que private solo estará en el archivo C. Esto ayuda en la modularidad del código.

No hay nada como tener varios archivos de encabezado que se convierten en propensos a errores. Pero sí, a veces resulta complicado rastrear una función si hay varios encabezados para un módulo.

Sobre tu segunda pregunta,

La buena práctica es que no debería tener variables globales :-) Intente mantener este recuento lo más mínimo posible. Y tener todas las variables en un archivo hace que sea arriesgado de tal manera que todas las variables sean accesibles para todos los archivos en su aplicación. Por lo tanto, Doing extern es mejor que mantener todo en un archivo de encabezado.

Si no tiene restricciones de memoria, haga las funciones Get Get () y Set (), es decir, haga que las funciones lean el valor de una variable y establezcan el Valor en esa variable. Por esto, no es necesario hacer que esas variables sean externas o se incluyan en el archivo de encabezado. También puedes hacerlos en línea para evitar saltar.

Lea este hilo sobre Global Variables.

    
respondido por el Swanand

Lea otras preguntas en las etiquetas