Vraag:
Is vluchtig nodig wanneer variabele wordt benaderd vanuit> 1 ISR's, maar niet gedeeld buiten ISR's?
Joonas Pulakka
2014-06-02 15:35:23 UTC
view on stackexchange narkive permalink

Het is duidelijk gedocumenteerd dat wanneer globale gegevens worden gedeeld met een ISR en het hoofdprogramma, de gegevens vluchtig moeten worden verklaard om zichtbaarheid van het geheugen te garanderen (en dat is alleen voldoende voor 1-byte data; alles wat groter is heeft speciale regelingen nodig om ook atomiciteit te garanderen). Hier hebben we goede regels:

  • Variabelen die alleen buiten een ISR worden gebruikt, mogen niet vluchtig zijn.
  • Variabelen die alleen binnen een ISR worden gebruikt, mogen niet vluchtig.
  • Variabelen die zowel binnen als buiten een ISR worden gebruikt, moeten vluchtig zijn.

Maar is vluchtig nodig wanneer de variabele wordt benaderd vanuit> 1 ISR's, maar niet gedeeld buiten ISR's? Ik heb bijvoorbeeld een functie die de interne toestand handhaaft met een statische variabele: 

  void func () {statische vluchtige lange teller; // vluchtig of niet? // Doe dingen met teller enz.}

Die functie wordt op twee manieren aangeroepen: vanaf pin-interrupt en vanuit TimerOne-bibliotheek:

  1. attachInterrupt (0, func, CHANGE);
  2. Timer1.attachInterrupt (func);

Er zijn geen atomiciteitsproblemen, aangezien wanneer een ISR wordt ingevoerd, interrupts automatisch worden uitgeschakeld, maar deze vluchtige is meer een compilervraag: wat wordt in de cache opgeslagen en wat is niet.

Beter dan genezen, natuurlijk ...

Een antwoord:
JRobert
2014-06-02 17:14:30 UTC
view on stackexchange narkive permalink

vluchtig informeert alleen de codegenerator van de compiler dat de variabele kan worden gewijzigd door iets anders dan de code die wordt gegenereerd, dus om niet aan te nemen dat een kopie ervan correct blijft.

ISR-code moet worden geschreven / gegenereerd in de veronderstelling dat deze geen context heeft bij binnenkomst, en de CPU-context behouden rond zijn (ISR's) eigen werking. Dus, net als bij de ondeelbaarheid van niet-atomaire bewerkingen, hangt de vluchtigheid in dit geval * af van het al dan niet toestaan ​​van interrupts. Als niet-nesten is gegarandeerd, kan de gedeelde variabele tijdens zijn eigen uitvoering niet anders dan deze ISR veranderen. Als je ISR ooit gebruikt kan worden in een omgeving waar interrupts zich mogen nestelen, dan zal die beperking niet langer gelden.

* in dit geval :
Ik ben uitgaande van een door software onderhouden variabele hier. Als we het hebben over een variabele die kan worden bijgewerkt door een hardwaregebeurtenis, bijvoorbeeld een timerregister, zijn alle weddenschappen uitgeschakeld: de variabele is hoe dan ook vluchtig.

Dus, zolang ik Arduino's standaard "interrupts don't nest" -gedrag niet verander, hoeft de variabele niet `vluchtig` te zijn, aangezien deze niet wordt gewijzigd door iets anders dan de code die wordt gegenereerd; compiler kan "aannemen" dat de ISR lineair wordt uitgevoerd, en dat doet het, zolang de interrupts niet nestelen. Dat is logisch. Bedankt!


ⓘ
Deze Q&A is automatisch vertaald vanuit de Engelse taal.De originele inhoud is beschikbaar op stackexchange, waarvoor we bedanken voor de cc by-sa 3.0-licentie waaronder het wordt gedistribueerd.
Loading...