U kunt met succes globale variabelen gebruiken, zolang u de richtlijnen van @ Phil in gedachten houdt. Hier zijn echter enkele handige manieren om hun problemen te vermijden zonder de gecompileerde code minder compact te maken.

1. Gebruik lokale statische variabelen voor persistente toestand waartoe u alleen toegang wilt hebben binnen één functie.

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

2. Gebruik een structuur om gerelateerde variabelen bij elkaar te houden, om het duidelijker te maken waar ze moeten worden gebruikt en waar niet.

     struct machine_state {uint8_t niveau; uint8_t error_code;} machine_state; struct led_state {uint8_t rood; uint8_t groen; uint8_t blauw;} led_state; void machine_change_state () {machine_state.level + = 1; / * ... * / / * We kunnen gemakkelijk onthouden om led_state niet te gebruiken in deze functie. * /} void machine_set_io () {switch (machine_state.level) {geval 1: PIN_MACHINE_IO_A = 1; / * ... * /}}  

3. Gebruik globale statische variabelen om de variabelen alleen zichtbaar te maken in het huidige C-bestand. Dit voorkomt onbedoelde toegang door code in andere bestanden als gevolg van naamconflicten.

     / * time_machine.c * / static uint8_t current_time; / * ... * // * delay.c * / static uint8_t current_time; / * Een volledig aparte variabele alleen voor dit C-bestand. * // * ... * /  

Als laatste opmerking, als u een globale variabele wijzigt binnen een interruptroutine en deze ergens anders leest:

• Markeer de variabele vluchtig.
• Zorg ervoor dat deze atomisch is voor de CPU (dwz 8-bits voor een 8-bits CPU).

OF

• Gebruik een vergrendelingsmechanisme om de toegang tot de variabele te beschermen.

De redenen waarom je geen globale variabelen zou willen gebruiken in een 8-bits systeem zijn dezelfde als die je ze niet in een ander systeem zou willen gebruiken: ze maken het moeilijk om te redeneren over het gedrag van het programma.

Alleen slechte programmeurs houden vast aan regels als "gebruik geen globale variabelen". Goede programmeurs begrijpen de reden achter de regels en behandelen de regels meer als richtlijnen.

Is uw programma gemakkelijk te begrijpen? Is zijn gedrag voorspelbaar? Is het gemakkelijk om onderdelen ervan aan te passen zonder andere onderdelen te breken? Als het antwoord op elk van deze vragen ja is, dan ben je op weg naar een goed programma.

U moet het gebruik van globale variabelen (afgekort "globals") niet volledig vermijden. Maar u moet ze oordeelkundig gebruiken. De praktische problemen met overmatig gebruik van globals:

• Globals zijn zichtbaar in de hele compilatie-unit. Elke code in de compilatie-eenheid kan een global. De gevolgen van een wijziging kunnen overal aan de oppervlakte komen waar deze globale evaluatie wordt geëvalueerd.
• Als resultaat maken globale termen de code moeilijker te lezen en te begrijpen. De programmeur moet altijd alle plaatsen in gedachten houden waar de globale waarde wordt geëvalueerd en toegewezen.
• Overmatig gebruik van globale waarden maakt de code vatbaarder voor defecten.

Het is een goede gewoonte om een ​​voorvoegsel g_ toe te voegen aan de naam van globale variabelen. Bijvoorbeeld g_iFlags . Als je de variabele met het voorvoegsel in de code ziet, herken je meteen dat het een globaal is.

Het voordeel van globale datastructuren in embedded werk is dat ze statisch zijn. Als elke variabele die je nodig hebt globaal is, zul je nooit per ongeluk te weinig geheugen hebben als functies worden ingevoerd en er ruimte voor wordt gemaakt op de stapel. Maar waarom hebben dan op dat punt functies? Waarom niet één grote functie die alle logica en processen afhandelt - zoals een BASIC-programma zonder dat GOSUB is toegestaan. Als je dit idee ver genoeg doorvoert, heb je een typisch assembleertaalprogramma uit de jaren 70. Efficiënt en onmogelijk te onderhouden en probleemoplossing.

Gebruik globale termen dus oordeelkundig, zoals toestandsvariabelen (bijvoorbeeld als elke functie moet weten of het systeem zich in de status interpreteren of uitvoeren bevindt) en andere gegevensstructuren die door veel functies moeten worden gezien en als @ PhilFrost zegt, is het gedrag van uw functies voorspelbaar? Is er een mogelijkheid om de stapel te vullen met een invoertekenreeks die nooit eindigt? Dit zijn zaken voor het ontwerp van algoritmen.

Merk op dat statisch een verschillende betekenis heeft binnen en buiten een functie. https://stackoverflow.com/questions/5868947/difference-between-static-variable-inside-and-outside-of-a-function

https: //stackoverflow.com/questions/5033627/static-variable-inside-of-a-function-in-c

Globale variabelen mogen alleen worden gebruikt voor echt globale toestanden. Een globale variabele gebruiken om zoiets als bijv. de breedtegraad van de noordgrens van de kaart werkt alleen als er maar één "noordgrens van de kaart" kan zijn. Als de code in de toekomst wellicht moet werken met meerdere kaarten die verschillende noordelijke grenzen hebben, zal code die een globale variabele voor de noordelijke grens gebruikt waarschijnlijk moeten worden herwerkt.

In typische computertoepassingen is er vaak geen een bijzondere reden om aan te nemen dat er nooit meer dan één van iets zal zijn. In embedded systemen zijn dergelijke aannames echter vaak veel redelijker. Hoewel het mogelijk is dat een typisch computerprogramma wordt gebruikt om meerdere gelijktijdige gebruikers te ondersteunen, zal de gebruikersinterface van een typisch ingebed systeem zijn ontworpen voor bediening door een enkele gebruiker die interactie heeft met zijn knoppen en display. Als zodanig zal het op elk moment in de tijd een enkele gebruikersinterface hebben. Het ontwerp van het systeem zodat meerdere gebruikers kunnen communiceren met meerdere toetsenborden en beeldschermen zou veel complexiteit vergen en veel meer tijd in beslag nemen om te implementeren dan het ontwerpen voor één gebruiker. Als er nooit een beroep wordt gedaan op het systeem om meerdere gebruikers te ondersteunen, is elke extra inspanning die wordt geïnvesteerd om dergelijk gebruik mogelijk te maken, verspild. Tenzij het waarschijnlijk is dat ondersteuning voor meerdere gebruikers vereist is, is het waarschijnlijk verstandiger om het risico te lopen dat u de code die wordt gebruikt voor een interface voor één gebruiker moet weggooien in het geval dat ondersteuning voor meerdere gebruikers nodig is, dan extra tijd te besteden aan het toevoegen van meerdere gebruikers. gebruikersondersteuning die waarschijnlijk nooit nodig zal zijn.

Een gerelateerde factor met embedded systemen is dat in veel gevallen (vooral met betrekking tot gebruikersinterfaces) de enige praktische manier om het hebben van meer dan één van iets te ondersteunen, is door meerdere threads te gebruiken. Bij afwezigheid van een andere behoefte aan multi-threading, is het waarschijnlijk beter om een ​​eenvoudig ontwerp met één thread te gebruiken dan de systeemcomplexiteit te vergroten met multi-threading dat waarschijnlijk nooit echt nodig zal zijn. Als het toevoegen van meer dan één van iets sowieso een enorm herontwerp van het systeem zou vereisen, maakt het niet uit of het ook het gebruik van enkele globale variabelen moet herwerken.

Veel mensen zijn in de war over dit onderwerp. De definitie van een globale variabele is:

Iets dat overal in uw programma toegankelijk is.

Dit is niet hetzelfde als file scope variabelen, die worden gedeclareerd door het trefwoord statisch . Dat zijn geen globale variabelen, het zijn lokale privévariabelen.

  int x; // globale variabele statische int y; // file scope variabele void some_func (void) {...} // toegevoegd om aan te tonen dat de bovenstaande variabelen een file scope hebben.  

Moet je globale variabelen gebruiken? Er zijn een paar gevallen waarin het prima is:

• Variabelen die alleen-lezen zijn, kunnen globaal zijn. Gerelateerd bericht met gedetailleerde informatie over dat onderwerp
• Hardwareregisters die overeenkomen met uw MCU-registerkaart, kunnen globaal zijn.

In elke In andere gevallen zult u nooit globale variabelen gebruiken. Er is nooit een reden om dit te doen. Gebruik in plaats daarvan bestandsbereikvariabelen , wat prima is.

Je moet ernaar streven om onafhankelijke, autonome codemodules te schrijven die zijn ontworpen om een ​​specifieke taak uit te voeren. Binnen die modules moeten variabelen voor het interne bestandsbereik zich bevinden als leden van privégegevens. Deze ontwerpmethode staat bekend als object-oriëntatie en wordt algemeen erkend als goed ontwerp.