Uso de variables globales en sistemas embebidos

Empecé a escribir firmware para mi producto y soy un novato aquí. Revisé muchos artículos sobre no usar variables o funciones globales. ¿Existe algún límite para usar variables globales en un sistema de 8 bits o es un completo 'No-No'? ¿Cómo debo usar variables globales en mi sistema o debería evitarlas por completo?

Me gustaría recibir valiosos consejos de ustedes sobre este tema para hacer que mi firmware sea más compacto.

Puede utilizar las variables globales con éxito, siempre y cuando tenga en cuenta las pautas de @ Phil. Sin embargo, aquí hay algunas buenas maneras de evitar sus problemas sin hacer que el código compilado sea menos compacto.

1. Use variables estáticas locales para el estado persistente al que solo desea acceder dentro de una función.

   #include <stdint.h>
   void skipper()
   {
       static uint8_t skip_initial_cycles = 5;
       if (skip_initial_cycles > 0) {
           skip_initial_cycles -= 1;
           return;
       }
       /* ... */
   }

2. Use una estructura para mantener juntas las variables relacionadas, para que quede más claro dónde se deben usar y dónde no.

   struct machine_state {
        uint8_t level;
        uint8_t error_code;
   } machine_state;
   
   struct led_state {
       uint8_t red;
       uint8_t green;
       uint8_t blue;
   } led_state;
   
   void machine_change_state()
   {
       machine_state.level += 1;
       /* ... */
       /* We can easily remember not to use led_state in this function. */
   }
   
   void machine_set_io()
   {
       switch (machine_state.level) {
       case 1:
           PIN_MACHINE_IO_A = 1;
           /* ... */
       }
   }

3. Use variables estáticas globales para hacer que las variables sean visibles solo dentro del archivo C actual. Esto evita el acceso accidental por código en otros archivos debido a conflictos de nombres.

   /* time_machine.c */
   static uint8_t current_time;
   /* ... */
   
   /* delay.c */
   static uint8_t current_time; /* A completely separate variable for this C file only. */
   /* ... */

Como nota final, si está modificando una variable global dentro de una rutina de interrupción y la está leyendo en otro lugar:

• Marcar la variable volatile.
• Asegúrese de que sea atómico para la CPU (es decir, 8 bits para una CPU de 8 bits).

O

• Use un mecanismo de bloqueo para proteger el acceso a la variable.

Las razones por las que no querría usar variables globales en un sistema de 8 bits son las mismas que no desearía usar en ningún otro sistema: dificultan el razonamiento sobre el comportamiento del programa.

Solo los malos programadores se obsesionan con reglas como "no usar variables globales". Los buenos programadores entienden la razón detrás de las reglas, luego las tratan más como pautas.

¿Su programa es fácil de entender? ¿Es predecible su comportamiento? ¿Es fácil modificar partes de él sin romper otras partes? Si la respuesta a cada una de estas preguntas es sí , entonces está en camino a un buen programa.

No debe evitar por completo el uso de variables globales ("globales" para abreviar). Pero, debes usarlos juiciosamente. Los problemas prácticos con el uso excesivo de globals:

• Globales son visibles en toda la unidad de compilación. Cualquier código en la unidad de compilación puede modificar un global. Las consecuencias de una modificación pueden surgir en cualquier lugar donde se evalúe este global.
• Como resultado, los globales hacen que el código sea más difícil de leer y comprender. El programador siempre tiene que tener en cuenta todos los lugares donde se evalúa y asigna el global.
• El uso excesivo de globals hace que el código sea más propenso a defectos.

Es una buena práctica agregar un prefijo g_al nombre de las variables globales. Por ejemplo, g_iFlags. Cuando veas la variable con el prefijo en el código, inmediatamente reconocerás que es global.

La ventaja de las estructuras de datos globales en el trabajo integrado es que son estáticas. Si cada variable que necesita es global, nunca se quedará sin memoria accidentalmente cuando se ingresen las funciones y se haga espacio para ellas en la pila. Pero entonces, en ese punto, ¿por qué tener funciones? ¿Por qué no una gran función que maneja toda la lógica y los procesos, como un programa BÁSICO sin GOSUB permitido? Si lleva esta idea lo suficientemente lejos, tendrá un programa típico en lenguaje ensamblador de la década de 1970. Eficiente e imposible de mantener y solución de problemas.

Por lo tanto, use juiciosamente, como las variables de estado (por ejemplo, si cada función necesita saber si el sistema está en estado de interpretación o ejecución) y otras estructuras de datos que deben ser vistas por muchas funciones y, como dice @PhilFrost, es el comportamiento de sus funciones predecibles? ¿Existe la posibilidad de llenar la pila con una cadena de entrada que nunca termina? Estos son asuntos para el diseño de algoritmos.

Tenga en cuenta que static tiene un significado diferente dentro y fuera de una función. /programming/5868947/difference-between-static-variable-inside-and-outside-of-a-function

/programming/5033627/static-variable-inside-of-a-function-in-c

Las variables globales solo deben usarse para un estado verdaderamente global. El uso de una variable global para representar algo como, por ejemplo, la latitud del límite norte del mapa solo funcionará si solo puede haber un "límite norte del mapa". Si en el futuro el código tuviera que funcionar con múltiples mapas que tienen diferentes límites norteños, el código que usa una variable global para el límite norte probablemente tendrá que ser modificado.

En las aplicaciones informáticas típicas, a menudo no hay una razón particular para suponer que nunca habrá más de una. Sin embargo, en los sistemas integrados, tales suposiciones son a menudo mucho más razonables. Si bien es posible que se requiera que un programa de computadora típico admita múltiples usuarios simultáneos, la interfaz de usuario de un sistema embebido típico estará diseñada para que la opere un solo usuario que interactúa con sus botones y pantalla. Como tal, en cualquier momento tendrá un solo estado de interfaz de usuario. Diseñar el sistema para que múltiples usuarios puedan interactuar con múltiples teclados y pantallas requeriría mucha más complejidad, y llevaría mucho más tiempo implementarlo, que diseñarlo para un solo usuario. Si nunca se solicita al sistema que admita múltiples usuarios, se desperdiciará cualquier esfuerzo adicional invertido para facilitar dicho uso. A menos que sea probable que se requiera soporte multiusuario, sería más prudente arriesgarse a tener que descartar el código utilizado para una interfaz de usuario único en caso de que se requiera soporte multiusuario, que gastar un tiempo extra agregando soporte al usuario que probablemente nunca sea necesario.

Un factor relacionado con los sistemas embebidos es que, en muchos casos (especialmente cuando se trata de interfaces de usuario), la única forma práctica de soportar tener más de uno de los elementos sería utilizar múltiples subprocesos. En ausencia de alguna otra necesidad de subprocesos múltiples, es probable que sea mejor usar un diseño simple de un solo subproceso que aumentar la complejidad del sistema con subprocesos múltiples que probablemente nunca sea realmente necesario. Si agregar más de uno requeriría un gran rediseño del sistema de todos modos, no importará si también requiere reelaborar el uso de algunas variables globales.

Mucha gente está confundida sobre este tema. La definición de una variable global es:

Algo que es accesible desde todas partes en su programa.

Esto no es lo mismo que las variables de alcance del archivo , que son declaradas por la palabra clave static. Esas no son variables globales, son variables privadas locales.

 int x; // global variable
 static int y; // file scope variable

 void some_func (void) {...} // added to demonstrate that the variables above are at file scope.

¿Deberías usar variables globales? Hay algunos casos en los que está bien:

• Las variables que son de solo lectura pueden ser globales. Publicación relacionada con información detallada sobre ese tema
• Los registros de hardware correspondientes a su mapa de registro MCU pueden ser globales.

En cualquier otro caso, no utilizará variables globales, nunca. Nunca hay una razón para hacerlo. En su lugar, use variables de alcance de archivo , lo cual está perfectamente bien.

Debe esforzarse por escribir módulos de código independientes y autónomos diseñados para realizar una tarea específica. Dentro de esos módulos, las variables de alcance del archivo interno deben residir como miembros de datos privados. Este método de diseño se conoce como orientación a objetos y es ampliamente reconocido como un buen diseño.