Uso de variáveis ​​globais em sistemas embarcados

Comecei a escrever o firmware do meu produto e sou um novato aqui. Eu passei por muitos artigos sobre não usar variáveis ​​ou funções globais. Existe algum limite para o uso de variáveis ​​globais em um sistema de 8 bits ou é um 'Não-Não' completo. Como devo usar variáveis ​​globais no meu sistema ou devo evitá-las completamente?

Gostaria de receber conselhos valiosos de vocês sobre este tópico para tornar meu firmware mais compacto.

Você pode usar variáveis ​​globais com êxito, desde que tenha em mente as diretrizes do @ Phil. No entanto, aqui estão algumas maneiras legais de evitar seus problemas sem tornar o código compilado menos compacto.

1. Use variáveis ​​estáticas locais para o estado persistente que você deseja acessar apenas dentro de uma função.

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

2. Use uma estrutura para manter as variáveis ​​relacionadas juntas, para tornar mais claro onde elas devem ser usadas e onde não.

   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 variáveis ​​estáticas globais para tornar as variáveis ​​visíveis apenas no arquivo C atual. Isso evita o acesso acidental por código em outros arquivos devido a conflitos de nomes.

   /* 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, se você estiver modificando uma variável global dentro de uma rotina de interrupção e lendo-a em outro lugar:

• Marque a variável volatile.
• Verifique se ele é atômico para a CPU (ou seja, 8 bits para uma CPU de 8 bits).

OU

• Use um mecanismo de bloqueio para proteger o acesso à variável.

As razões pelas quais você não gostaria de usar variáveis ​​globais em um sistema de 8 bits são as mesmas que você não gostaria de usá-las em qualquer outro sistema: elas dificultam o raciocínio sobre o comportamento do programa.

Somente programadores ruins ficam presos a regras como "não usam variáveis ​​globais". Bons programadores entendem o motivo por trás das regras e tratam as regras mais como diretrizes.

Seu programa é fácil de entender? Seu comportamento é previsível? É fácil modificar partes sem quebrar outras? Se a resposta para cada uma dessas perguntas for afirmativa , você está no caminho de um bom programa.

Você não deve evitar completamente o uso de variáveis ​​globais ("globais" para abreviar). Mas você deve usá-los criteriosamente. Os problemas práticos com o uso excessivo de globais:

• Globais são visíveis em toda a unidade de compilação. Qualquer código na unidade de compilação pode modificar um global. As consequências de uma modificação podem surgir em qualquer lugar em que essa global for avaliada.
• Como resultado, os globais tornam o código mais difícil de ler e entender. O programador sempre deve ter em mente todos os lugares onde o global é avaliado e atribuído.
• O uso excessivo de globais torna o código mais propenso a defeitos.

É uma boa prática adicionar um prefixo g_ao nome das variáveis ​​globais. Por exemplo g_iFlags,. Quando você vê a variável com o prefixo no código, reconhece imediatamente que é global.

A vantagem das estruturas de dados globais no trabalho incorporado é que elas são estáticas. Se todas as variáveis ​​necessárias forem globais, você nunca ficará sem memória acidentalmente quando as funções forem inseridas e houver espaço para elas na pilha. Mas então, nesse ponto, por que ter funções? Por que não uma grande função que lida com toda a lógica e processos - como um programa BASIC sem GOSUB permitido. Se você levar essa idéia longe o suficiente, terá um programa típico de linguagem assembly a partir dos anos 70. Eficiente e impossível de manter e solucionar problemas.

Portanto, use globais criteriosamente, como variáveis ​​de estado (por exemplo, se todas as funções precisarem saber se o sistema está em estado de interpretação ou execução) e outras estruturas de dados que precisam ser vistas por muitas funções e, como @PhilFrost diz, é o comportamento de suas funções previsíveis? Existe a possibilidade de preencher a pilha com uma string de entrada que nunca termina? Estes são assuntos para o design de algoritmos.

Observe que estática tem um significado diferente dentro e fora de uma função. /programming/5868947/difference-between-static-variable-inside-and-outside-of-a-function

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

Variáveis ​​globais devem ser usadas apenas para um estado verdadeiramente global. O uso de uma variável global para representar algo como, por exemplo, a latitude do limite norte do mapa só funcionará se houver um único "limite norte do mapa". Se, no futuro, o código precisar trabalhar com vários mapas com limites diferentes do norte, provavelmente será necessário reformular o código que usa uma variável global para o limite norte.

Em aplicativos típicos de computador, muitas vezes não há razão específica para supor que nunca haverá mais do que uma coisa. Em sistemas embarcados, no entanto, essas premissas geralmente são muito mais razoáveis. Embora seja possível que um programa de computador típico possa ser chamado para oferecer suporte a vários usuários simultâneos, a interface do usuário de um sistema embarcado típico será projetada para operação por um único usuário interagindo com seus botões e tela. Como tal, a qualquer momento, ele terá um único estado de interface do usuário. Projetar o sistema para que vários usuários possam interagir com vários teclados e monitores exigiria muito mais complexidade e levaria muito mais tempo para implementar do que projetá-lo para um único usuário. Se o sistema nunca for chamado a oferecer suporte a vários usuários, qualquer esforço extra investido para facilitar esse uso será desperdiçado. A menos que seja provável que o suporte a vários usuários seja necessário, provavelmente seria mais prudente arriscar descartar o código usado para uma interface de usuário único, caso o suporte a múltiplos usuários seja necessário, do que gastar mais tempo adicionando suporte ao usuário que provavelmente nunca será necessário.

Um fator relacionado aos sistemas incorporados é que, em muitos casos (especialmente envolvendo interfaces com o usuário), a única maneira prática de oferecer suporte a mais de uma coisa seria usar vários encadeamentos. Na ausência de outra necessidade de multiencadeamento, provavelmente é melhor usar um design simples de thread único do que aumentar a complexidade do sistema com multiencadeamento que provavelmente nunca será realmente necessário. Se a adição de mais de uma coisa exigiria uma enorme reformulação do sistema, não importará se também é necessário reformular o uso de algumas variáveis ​​globais.

Muitas pessoas estão confusas sobre esse assunto. A definição de uma variável global é:

Algo acessível de qualquer lugar do seu programa.

Isso não é o mesmo que variáveis ​​de escopo de arquivo , que são declaradas pela palavra-chave static. Essas não são variáveis ​​globais, são variáveis ​​privadas locais.

 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.

Você deve usar variáveis ​​globais? Existem alguns casos em que é bom:

• Variáveis ​​que são somente leitura podem ser globais. Post relacionado com informações detalhadas sobre esse tópico
• Os registros de hardware correspondentes ao seu mapa de registros do MCU podem ser globais.

Em todos os outros casos, você nunca deve usar variáveis ​​globais. Nunca há uma razão para fazê-lo. Em vez disso, use variáveis ​​de escopo de arquivo , o que é perfeitamente adequado.

Você deve se esforçar para escrever módulos de código autônomos e independentes projetados para executar uma tarefa específica. Dentro desses módulos, as variáveis ​​internas do escopo do arquivo devem residir como membros de dados privados. Esse método de design é conhecido como orientação a objetos e amplamente reconhecido como bom design.