Versuch einer Millis Funktion für AVR

[Mirko (mirkomikro)]

Hallo,

ich versuche mich gerade daran, eine Art Millis Funktion, wie es auch 
bei Arduino gibt für meine Projekte umzusetzen.

Leider komme ich irgendwie nicht weiter, bzw. habe ich eine Blockade. 
Hat jemand für mich eventuell einen Tipp? Bin ich überhaupt auf dem 
richtigen Weg?


Über den CTC Timer1 wird jede Sekunde die globale Variable millis 
hochgezählt. Diese greife ich ab und vergleiche Sie mit dem gewünschten 
Intervall und möchte dann damit die LED blinken lassen.

#define CONFIG_OUTPUTS  { DDRB |= (1 << PB5); }      // Configure outputs (1)
#define LED_GN_TOGGLE  { PORTB ^= (1 << PB5); }            // PB5 - LED green toggle


volatile unsigned long millis = 0;

int main (void)
{
  CONFIG_OUTPUTS;              // Set LED as output
  
  TCCR1B |= (1 << WGM12);          // Configure timer 1 for CTC mode
  TIMSK1 |= (1 << OCIE1A);        // Enable CTC interrupt
  sei ();                  // Enable global interrupts
  OCR1A = 31249;              // Set CTC compare value to 1 Hz at 8 MHz AVR clock , with a prescaler of 256
  TCCR1B |= (1 << CS12);          // Start timer at F_CPU /256
  
  const unsigned long eventInterval = 1000;
  unsigned long previousTime = 0;
  
  while (1)
  {
      // Updates frequently
      unsigned long currentTime = millis;
      // This is the event
      if (currentTime - previousTime >= eventInterval) {
        // Event code
        LED_GN_TOGGLE;        
        // Update the timing for the next time around
        previousTime = currentTime;
      }
  }
}


ISR (TIMER1_COMPA_vect)
{
  millis++;
}

[Sebastian W. (wangnick)]

1. Warum wird millis nur jede Sekunde um 1 erhöht, und nicht jede 
Millisekunde?
2. Der Zugriff auf millis in main() ist nicht atomar. Auf einem AVR sind 
byteweise Zugriffe atomar, millis besteht aber aus 4 Bytes. Eine 
mögliche Abhilfe wäre, vor der Zuweisung an currentTime die Interrupts 
zu sperren, und sie nach der Zuweisung wieder freizugeben.

LG, Sebastian

[Arduino F. (Firma: Gast) (arduinof)]

Sebastian W. schrieb:
> Eine
> mögliche Abhilfe wäre, vor der Zuweisung an currentTime die Interrupts
> zu sperren, und sie nach der Zuweisung wieder freizugeben.

Oder die Atomic Makros verwenden, dann kann man auch auf das volatile 
verzichten.

[Veit D. (devil-elec)]

Hallo,

wenn der Timer auf 1Hz konfiguriert ist und man den Sekundenzähler im 
1000er Intervall abfragt, dann wartet man 1000 Sekunden. Konfiguriere 
den Timer auf 1000Hz, dann macht auch der Variablenname millis wieder 
Sinn. Nimm die Formel laut Manual für den CTC Mode, stelle nach TOP um 
und rechne es aus. Berechne es mit allen Prescalern und nimm am Ende 
einen womit ein Ganzzahl TOP Wert rauskommt.

[Werner P. (werner4096)]

Warum eigentlich so kompliziert mit currentTime und previousTime usw.

Warum nicht eine volatile uint8_t tick_sec variable?

  while (1)
  {
    if (tick_sec) {
      tick_sec = 0;
    }
  }

ISR (TIMER1_COMPA_vect)
{
  static int tick = 1000
  
  tick--;
  if (tick > 0) {
    tick--;
    if (tick == 0) {
      tick = 1000;
      tick_sec = 1;
    }
  }
}

[Arduino F. (Firma: Gast) (arduinof)]

Werner P. schrieb:
> tick_sec = 0;

Jedes dieser tick_sec macht deine ISR fetter.

Werner P. schrieb:
> Warum eigentlich so kompliziert mit currentTime und previousTime usw.
Weil es funktioniert!
Weil es einfach ist.
Es kann Intervalle bis 49,x Tage.

Bei deinem Tick muss du dafür Sorge tragen, dass diese Ticks in jedem 
Programmteil ankommen.
Und Millis gibts überall.

Sicherlich gehen beide Wege.....
Also einen aussuchen und damit glücklich werden.

[Nemopuk (nemopuk)]

Mirko schrieb:
> Leider komme ich irgendwie nicht weiter

Funktioniert es nicht? Beschreibe das Problem!

Die millis Variable muss volatile sein, sonst neigt der Compiler dazu, 
ihren Wert in CPU Registern zu cachen und dann bekommt main() die 
Änderungen durch die ISR nicht mit.

Du solltest auch dafür sorgen, dass der Lesezugriff auf die Variable 
millis nicht durch die ISR gestört/unterbrochen wird, sonst liest main 
sporadisch Quatsch:

Beispiel:

- millis ist gerade 255
- main liest das erste Byte als 255
- isr erhöht auf 256
- main liest das zweite Byte als 1
- main liest das dritte Byte als 0
- main liest das vierte Byte als 0

Am Ende sieht main den Wert 511, richtig wäre aber 256.

[Harald K. (kirnbichler)]

Werner P. schrieb:

ISR (TIMER1_COMPA_vect)
{
  static int tick = 1000
 
  tick--;          // hier
  if (tick > 0) {
    tick--;        // hier nochmal
    if (tick == 0) {
      tick = 1000;
      tick_sec = 1;
    }
  }
}

Bei jedem Durchlauf der ISR wird "tick" zweimal dekrementiert? Wozu?

[Veit D. (devil-elec)]

Nemopuk schrieb:

> Die millis Variable muss volatile sein, sonst neigt der Compiler dazu,
> ihren Wert in CPU Registern zu cachen und dann bekommt main() die
> Änderungen durch die ISR nicht mit.
>
> Du solltest auch dafür sorgen, dass der Lesezugriff auf die Variable
> millis nicht durch die ISR gestört/unterbrochen wird, sonst liest main
> sporadisch Quatsch:

Auf volatile kann und sollte man hierfür verzichten.

a) Beitrag "Re: Versuch einer Millis Funktion für AVR"
b) Beitrag "Re: c volatile -> wann bracht mans wirklich?"

[Veit D. (devil-elec)]

Harald K. schrieb:
> Werner P. schrieb:
>
>

> ISR (TIMER1_COMPA_vect)
> {
>   static int tick = 1000
> 
>   tick--;          // hier
>   if (tick > 0) {
>     tick--;        // hier nochmal
>     if (tick == 0) {
>       tick = 1000;
>       tick_sec = 1;
>     }
>   }
> }
>

>
> Bei jedem Durchlauf der ISR wird "tick" zweimal dekrementiert? Wozu?

Hallo,

wäre immer noch zu viel. Kann man kürzen auf ...

ISR (TIMER1_COMPA_vect)
{
  static int tick {1000};
 
  tick--;         
  if (tick < 1) {
    tick = 1000;
    tickSec = true;
  }
}

oder

ISR (TIMER1_COMPA_vect)
{
  static unsigned int tick {0};
 
  tick++;         
  if (tick > 999) {
    tick = 0;
    tickSec = true;
  }
}

Wäre mir jedoch der falsche Ansatz, wenn man einen ms Zähler haben 
möchte. Die ISR soll einfach nur eine ms Variable hochzählen. Mehr muss 
und sollte sie nicht machen. Mittels millis baut man sich dann 
verschiedene unabhängige Timer. Das hat m.E. nichts in der ISR zu 
suchen.

[Oliver S. (oliverso)]

Veit D. schrieb:
> Auf volatile kann und sollte man hierfür verzichten.

Kann und sollte man nicht.

Der verlinkte Beitrag b) ist zwar nicht verkehrt, aber wie alles von 
Wilhelm ist das halt nur und ausschließlich auf aktuellstes C++ 
zutreffend.

Hier gehts um C.

Oliver

[Johann L. (gjlayde)]

Veit D. schrieb:
> Auf volatile kann und sollte man hierfür verzichten.
>
> b) Beitrag "Re: c volatile -> wann bracht mans wirklich?"

Da wird nur seitenweise doziert ohne zu zeigen wie es gehen könnte.

Mit avr-gcc gibe es weder _Atomic noch std::atomic. (Und auch keine 
libatomic, und wenn würde die keiner verwenden weil extrem 
resourcenfressend.)

Posix Threads gibt es auch nicht.

Und was soll "explizites Abschalten der Nebenläufigkeit" im hiesigen 
Kontext anderes sein als das, was avr/atomic.h macht?

Also mal Butter bei die Fische und nach konkrete Codebeispiele.

[Arduino F. (Firma: Gast) (arduinof)]

Nemopuk schrieb:
> Die millis Variable muss volatile sein,

Direkt über deinem Posting findest du ein funktionierendes Beispiel ohne 
volatile.
Beitrag "Re: Versuch einer Millis Funktion für AVR"

Johann L. schrieb:
> Also mal Butter bei die Fische und nach konkrete Codebeispiele.
Wenige Postings über deinem!

[Harald K. (kirnbichler)]

Arduino F. schrieb:
> Direkt über deinem Posting findest du ein funktionierendes Beispiel ohne
> volatile.

Vor allem: Volatile würde hier auch nicht helfen.

[Johann L. (gjlayde)]

Arduino F. schrieb:
> Direkt über deinem Posting findest du [...]

> Wenige Postings über deinem!

Geht's noch etwas ungenauer?

[Arduino F. (Firma: Gast) (arduinof)]

Oliver S. schrieb:
> Veit D. schrieb:
>> Auf volatile kann und sollte man hierfür verzichten.
>
> Kann und sollte man nicht.

Volatile macht Sinn, und findet seinen Zweck wenn es sich um Hardware 
Register handelt, welche sich Außerhalb des Programms ändern können.

Bei Werten aus einer ISR  und ihrer späteren Verarbeitung ist das nicht 
der Fall.
Interrupts abschalten und Memory Barrier setzen, beides macht das Atomic 
Block Makro.
Natürlich sowohl in C als auch C++.
Zumindest für AVR.

[Arduino F. (Firma: Gast) (arduinof)]

Johann L. schrieb:
> Geht's noch etwas ungenauer?
Auf den Link klicken kannst du nicht?

[Veit D. (devil-elec)]

Johann L. schrieb:
> Veit D. schrieb:
>> Auf volatile kann und sollte man hierfür verzichten.
>>
>> b) Beitrag "Re: c volatile -> wann bracht mans wirklich?"
>
> Da wird nur seitenweise doziert ohne zu zeigen wie es gehen könnte.
>
> Mit avr-gcc gibe es weder _Atomic noch std::atomic. (Und auch keine
> libatomic, und wenn würde die keiner verwenden weil extrem
> resourcenfressend.)

Womit ist sie Resourcenfressend auffällig?

> Und was soll "explizites Abschalten der Nebenläufigkeit" im hiesigen
> Kontext anderes sein als das, was avr/atomic.h macht?
>
> Also mal Butter bei die Fische und nach konkrete Codebeispiele.

Man muss ja nicht die std::atomic verwenden. Wie es ohne funktioniert 
hat Arduino F. schon gezeigt. Wenn man allerdings std::atomic verwendet, 
nimmt man einen atomic Datentyp und der ATOMIC BLOCK ist auch 
Geschichte.

[Werner P. (werner4096)]

Harald K. schrieb:
> Werner P. schrieb:
>
>

> ISR (TIMER1_COMPA_vect)
> {
>   static int tick = 1000
> 
>   tick--;          // hier
>   if (tick > 0) {
>     tick--;        // hier nochmal
>     if (tick == 0) {
>       tick = 1000;
>       tick_sec = 1;
>     }
>   }
> }
>

>
> Bei jedem Durchlauf der ISR wird "tick" zweimal dekrementiert? Wozu?

ah. grober Fehler beim schnellen Tippen! tick++ vor "if" gehört 
natürlich weg.

Danke für die Info

[Johann L. (gjlayde)]

Veit D. schrieb:
> Man muss ja nicht die std::atomic verwenden.

Kann man ja garnicht, weil die im AVR GCC nicht implementiert sind.

Oder hast du eine eigene Toolchain?

Ist dann so, als würdest du ein Auto in die Werkstatt bringen zum 
reparieren und der Mechaniker so:

"Also mein Auto funktioniert."

Arduino F. schrieb:
> Johann L. schrieb:
>> Geht's noch etwas ungenauer?
> Auf den Link klicken kannst du nicht?

Du hattest keinen Code verlinkt.

Wenn du Code referenzierst, dann verlinke ihn einfach.

[Arduino F. (Firma: Gast) (arduinof)]

Johann L. schrieb:
> Du hattest keinen Code verlinkt.
>
> Wenn du Code referenzierst, dann verlinke ihn einfach.

Ich habe einen Link auf einen Beitrag gesetzt, welcher den Code 
beinhaltet!
Schade, dass dich das so hoffnungslos überfordert.

[Arduino F. (Firma: Gast) (arduinof)]

Johann L. schrieb:
> Oder hast du eine eigene Toolchain?

Ja, haben wir!
AVR Gcc 12.2 mit der libstdc++

Diese libstdc++ ist (noch) nicht vollständig.
Die meisten grundlegenden Dinge sind allerdings da.

std::atomic ist da, aber funktioniert noch nicht, weil der Code für z.B. 
__atomic_fetch_add_8 und `__atomic_load_8 noch fehlt.

[Johann L. (gjlayde)]

Arduino F. schrieb:
> Johann L. schrieb:
>> Oder hast du eine eigene Toolchain?
>
> Ja, haben wir!
> AVR Gcc 12.2 mit der libstdc++

Hilft dem TO bestimmt weiter.

[Sebastian W. (wangnick)]

War ja klar, dass die volatile-atomic-memorybarrier-Debatte hier wieder 
fröhliche Urständ feiern würde …

LG, Sebastian

[Arduino F. (Firma: Gast) (arduinof)]

Johann L. schrieb:
> Hilft dem TO bestimmt weiter.

Du hast danach gefragt und eine Antwort bekommen!
Also beschwere dich nicht.
Oder hast du heute deinen irrationalen Tag?

Der TO hat dagegen ein Beispiel mit ATOMIC_BLOCK bekommen.
Das kann ihm helfen.

[Veit D. (devil-elec)]

Hallo Johann,

ganz ehrlich. Manchmal ist es mit dir wie im Kindergarten.
Du hattest nach einer Toolchain gefragt mit libstdc++.
Ja gibt es. https://github.com/modm-io/avr-libstdcpp
std::atomic ist wie schon geschrieben wurde noch nicht verwendbar.
Es war nur eine Nebenbemerkung von mir, bezüglich Wilhelms volatile 
Erklärung und deinem Kommentar dazu. Tut nichts zu eigentlichen Sache, 
außer volatile natürlich. Es ist allen klar, dass sie dem TO nicht 
hilft.
Sie muss ihm auch nicht helfen, weil der TO sie hier für seinen Code 
nicht benötigt. Hast du selbst schon klargestellt. ATOMICBLOCK und gut 
ist.
Um mehr geht es doch hier gar nicht.

Um des Friedens Willen extra für Johann ganz privat der Link. ;-)
Beitrag "Re: Versuch einer Millis Funktion für AVR"

[Johann L. (gjlayde)]

Veit D. schrieb:
> https://github.com/modm-io/avr-libstdcpp

So wie ich die dortigen Maintainer verstehe, ist dieses Projekt auf 
modm-io designed.  Mann kann sich damit also nicht einfach eine avr-g++ 
Toolchain basteln.  Siehe auch dortige Bugreports.

Dass der Code nicht zu GCC beigetragen wurde lässt auch tief blicken 
(Wakely ist ja GCC Maintainer).

[Arduino F. (Firma: Gast) (arduinof)]

Johann L. schrieb:
> Mann kann sich damit also nicht einfach eine avr-g++
> Toolchain basteln.

Wie schon gesagt, das meiste funktioniert.

[Johann L. (gjlayde)]

Arduino F. schrieb:
> Johann L. schrieb:
>> Mann kann sich damit also nicht einfach eine avr-g++
>> Toolchain basteln.
>
> Wie schon gesagt, das meiste funktioniert.

Es geht nicht um den Funktionsumfang, sondern das Zeugt überhaupt 
nutzbar zu machen.

[Axel S. (a-za-z0-9)]

Arduino F. schrieb:
> Oliver S. schrieb:
>> Veit D. schrieb:
>>> Auf volatile kann und sollte man hierfür verzichten.
>>
>> Kann und sollte man nicht.
>
> Volatile macht Sinn, und findet seinen Zweck wenn es sich um Hardware
> Register handelt, welche sich Außerhalb des Programms ändern können.
>
> Bei Werten aus einer ISR  und ihrer späteren Verarbeitung ist das nicht
> der Fall.

Doch natürlich. Eine Variable, die in einer ISR verändert wird, ist für 
den Compiler genauso wenig verhersehbar. Weder weiß der Compiler, ob der 
Interrupt für die ISR überhaupt enabled ist, noch ob die (Hardware!) 
Bedingung für das Auslösen des Interrupt gegeben ist. Für den Compiler 
ist das eine Variable, die er nicht in einem Register cachen darf, 
sondern immer direkt lesen oder schreiben muß.

> Interrupts abschalten und Memory Barrier setzen, beides macht das Atomic
> Block Makro.
> Natürlich sowohl in C als auch C++.
> Zumindest für AVR.

Die Dokumentation auf 
https://www.nongnu.org/avr-libc/user-manual/group__util__atomic.html 
gibt das nicht her. Sie sagt lediglich aus, daß der Code innerhalb des 
ATOMIC_BLOCK nicht unterbrochen werden kann. Von Memory Barrier steht da 
nix und abgesehen davon würde sie auch nicht helfen. Ja mehr noch: das 
Beispiel da geht genau auf den vorliegenden Fall ein. Und die Variable 
ist selbstverständlich volatile definiert. Man braucht beides: das 
volatile, damit der Compiler keine veraltete Kopie der Variable benutzt 
und den ATOMIC_BLOCK, damit der Compiler Code generiert, der innerhalb 
des Schreib- oder Lesezugriffs nicht unterbrochen wird.

[Johann L. (gjlayde)]

Axel S. schrieb:
> Arduino F. schrieb:
>> Interrupts abschalten und Memory Barrier setzen, beides macht
>> das Atomic Block Makro.  Natürlich sowohl in C als auch C++.
>> Zumindest für AVR.
>
> Die Dokumentation auf
> https://www.nongnu.org/avr-libc/user-manual/group__util__atomic.html
> gibt das nicht her. Sie sagt lediglich aus, daß der Code innerhalb des
> ATOMIC_BLOCK nicht unterbrochen werden kann. Von Memory Barrier steht da
> nix und abgesehen davon würde sie auch nicht helfen.

Naja eine Memory Barrier würde den kompletten Speicher invalidieren. 
Das machen zum Beispiel auch cli() und sei(), zumindest in neueren 
Versionen der AVR-LibC.  Aber gerade bei den AVR Tools sind gerne mal 
noch antike Versionen im Einsatz...

Bei ATOMIC_BLOCK fehlen teilweise Memory Barriers.  Beispiel:

static __ATTR_ALWAYS_INLINE__ void __iRestore(const  uint8_t *__s)
{
    SREG = *__s;
}

Das ist eine volatile Barrier, aber keine Memory Barrier.

[Veit D. (devil-elec)]

Johann L. schrieb:
> Veit D. schrieb:
>> https://github.com/modm-io/avr-libstdcpp
>
> So wie ich die dortigen Maintainer verstehe, ist dieses Projekt auf
> modm-io designed.  Mann kann sich damit also nicht einfach eine avr-g++
> Toolchain basteln.  Siehe auch dortige Bugreports.

Man kann sie inkludieren und verwenden.

[Johann L. (gjlayde)]

Veit D. schrieb:
> Johann L. schrieb:
>> Veit D. schrieb:
>>> https://github.com/modm-io/avr-libstdcpp
>>
>> So wie ich die dortigen Maintainer verstehe, ist dieses Projekt auf
>> modm-io designed.  Mann kann sich damit also nicht einfach eine avr-g++
>> Toolchain basteln.  Siehe auch dortige Bugreports.
>
> Man kann sie inkludieren und verwenden.

Um das in GCC zu integrieren ist es unbrauchbar.

[Veit D. (devil-elec)]

Axel S. schrieb:

> Doch natürlich.
> ...

Genauso hatte ich das bis vor einer Weile auch verteidigt. Bis mir die 
Welt hier im Forum es komplett anders erklärt hat, mit Hunderten 
Antworten und Threads. Ich kann es nicht mehr zählen. Es gab in all den 
anderen Threads zum Thema keinen Widerspruch. Und jetzt beginnt genau 
dieses Spiel von vorn. Muss man sich nicht wundern, wenn die Leute 
pauschal volatile und ATOMIC BLOCK verwenden. Einfach weil sie wissen 
das es damit funktioniert und damit sicher sind.

[Nemopuk (nemopuk)]

Es gibt dazu einen Artikel von Microchip.
https://developerhelp.microchip.com/xwiki/bin/view/products/mcu-mpu/8-bit-avr/peripherals/interrupts/special-considerations/

Muss man einfach nur lesen und verstehen.

Veit D. schrieb:
> Es gab in all den anderen Threads zum Thema keinen Widerspruch.
> Und jetzt beginnt genau dieses Spiel von vorn.

Mich nervt es auch. Das ist wie die Diskussion, ob ein Glas halb voll 
oder halb leer ist. Es geht den Diskutanten nur um Klugscheißerei.

[Veit D. (devil-elec)]

Johann L. schrieb:
> Veit D. schrieb:
>> Johann L. schrieb:
>>> Veit D. schrieb:
>>>> https://github.com/modm-io/avr-libstdcpp
>>>
>>> So wie ich die dortigen Maintainer verstehe, ist dieses Projekt auf
>>> modm-io designed.  Mann kann sich damit also nicht einfach eine avr-g++
>>> Toolchain basteln.  Siehe auch dortige Bugreports.
>>
>> Man kann sie inkludieren und verwenden.
>
> Um das in GCC zu integrieren ist es unbrauchbar.

Du sollst dir damit nicht eine Toolchain kompilieren. Du sollst sie 
inkludieren mit include <>. Siehe Abschnitt "Using the library with 
MICROCHIP's ATMEL Studio". Die Beschreibung ist gültig bis avr-gcc 14.x.

[Veit D. (devil-elec)]

Nemopuk schrieb:
> Es gibt dazu einen Artikel von Microchip.
> 
https://developerhelp.microchip.com/xwiki/bin/view/products/mcu-mpu/8-bit-avr/peripherals/interrupts/special-considerations/
>
> Muss man einfach nur lesen und verstehen.
>
> Veit D. schrieb:
>> Es gab in all den anderen Threads zum Thema keinen Widerspruch.
>> Und jetzt beginnt genau dieses Spiel von vorn.
>
> Mich nervt es auch. Das ist wie die Diskussion, ob ein Glas halb voll
> oder halb leer ist. Es geht den Diskutanten nur um Klugscheißerei.

Ich lehne mich jetzt auch nicht weiter aus dem Fenster. Wie verlinkt von 
dir ist das der gemeinsame Nenner der immer und jederzeit funktioniert. 
Unabhängig von irgendwas. Alles andere ist mir jetzt egal. Die 
Zusammenhänge sind nicht einfach.

[Ben S. (bensch123)]

Ich habe mir in C++ einen plattformunabhängigen Timer gebaut, welcher 
(theoretisch) in Mikrosekunden zählen kann und nach ca. 600.000 Jahren 
(64bit in Mikrosekunden) überläuft.

Also das geht alles schon.

[Arduino F. (Firma: Gast) (arduinof)]

Ben S. schrieb:
> Ich

Schön, dass du das gemacht hast.
Bestimmt ab und zu nützlich.

Nur schade, dass außer Werbung dafür, hier nix davon zu sehen ist.

[Norbert (der_norbert)]

Ben S. schrieb:
> Ich habe mir in C++ einen plattformunabhängigen Timer gebaut, welcher
> (theoretisch) in Mikrosekunden zählen kann und nach ca. 600.000 Jahren
> (64bit in Mikrosekunden) überläuft.

Die Frage ist: Was passiert danach?
Hast du das korrekte Überlaufverhalten in Echtzeit überprüft?
Nicht dass man sich da später ein Problem einfängt. 😎

[Frank M. (ukw) (Moderator)]

Ben S. schrieb:
> 64bit in Mikrosekunden

64 Bit in Mikrosekunden... auf einem AVR? Oder bin ich hier im falschen 
Thread?

[Axel S. (a-za-z0-9)]

Veit D. schrieb:
> Axel S. schrieb:
>
>> Doch natürlich.
>> ...
>
> Genauso hatte ich das bis vor einer Weile auch verteidigt. Bis mir die
> Welt hier im Forum es komplett anders erklärt hat, mit Hunderten
> Antworten und Threads.

Das ist an mir vorbeigegangen. Ist wohl auch besser so.

Jetzt lese ich allerdings gerade, daß die AVR-libc auch ein Makro 
_MemoryBarrier() im Angebot hat 
(https://www.nongnu.org/avr-libc/user-manual/group__avr__cpufunc.html)

Und der Text dazu liest sich, als würde das den Compiler dazu zwingen, 
Variablen-Zugriffe temporär(?) so durchzuführen als wäre die Variable 
volatile deklariert:

"instructs the compiler to not cache any memory data in registers beyond 
the barrier. This can sometimes be more effective than ... volatile"

Mit dieser Dokumentation bin ich aus mehreren Gründen nicht glücklich. 
"beyond the barrier" ... und wo endet diese Barriere? Sollte das nicht 
eher lauten "to invalidate any register caches established before the 
barrier"? Und davon mal abgesehen, ich will gar nicht alle Variablen, 
die in irgendwelchen Registern gecached sind verwerfen, sondern nur die 
eine, die sich asynchron ändern kann.

Deswegen halte ich immer noch volatile für die bessere Lösung. Zumal das 
auch außerhalb eines ATOMIC_BLOCK funktioniert. Man stelle sich mal vor, 
der Nutzer hat Interrupts abgeschaltet und glaubt nun er bräuchte keinen 
ATOMIC_BLOCK mehr, um auf die Variable zuzugreifen (ist ja auch so). 
Dummerweise implementiert ATOMIC_BLOCK aber auch das volatile und das 
fehlt jetzt. Nein, das führt in Teufels Küche. Die Dinge sollten nur das 
machen, was im Namen drinsteht. Und das Makro _MemoryBarrier() sollte 
eher _DropCachedVariables() heißen. Sofern es das tut, was ich vermute.

[Arduino F. (Firma: Gast) (arduinof)]

Axel S. schrieb:
> Dummerweise implementiert ATOMIC_BLOCK aber auch das volatile
Das tut es nicht!

[Veit D. (devil-elec)]

Hallo,

es werden nicht alle Variablen die in irgendwelchen Registern stehen 
verworfen. Die Funktion dient primär ccp_write_io() und behandelt nur 
das angegebene Register + Wert. Wurde spätestens mit den neuen AVR 
Controllern notwendig. Ich habe es jedenfalls vorher nicht benötigt. 
ccp_write_io() meine ich.

> Dummerweise implementiert ATOMIC_BLOCK aber auch das volatile ...
?

Habe ich einen Test gemacht. :-)

#include "util/atomic.h"

unsigned long nonVolatileCounter; 
volatile unsigned long isVolatileCounter; 

void testeVolatilitaet()
{
  for (unsigned long i = 0; i < 1000; i++) {
    ATOMIC_BLOCK(ATOMIC_RESTORESTATE) {
      ++nonVolatileCounter; 
      ++isVolatileCounter;
    }  
  }
}

void setup()
{
  TCCR1B = 0;
  TCCR1A = 0;
  TCCR1B |= (1 << WGM12);        
  TIMSK1 |= (1 << OCIE1A);       
  OCR1A = 9;                  
  TCCR1B |= (1 << CS00);         
  
  Serial.begin(250000);
  Serial.println("\nStart\n");

  for (unsigned long i = 0; i < 1000; i++) {
    testeVolatilitaet();    
  }

  TCCR1B = 0;
  Serial.print("nonVolatile "); Serial.println(nonVolatileCounter);
  Serial.print(" isVolatile "); Serial.println(isVolatileCounter);
}

void loop() {

}

ISR (TIMER1_COMPA_vect)
{
  ++nonVolatileCounter; 
  ++isVolatileCounter;
}

Bringt wiederholbar exakt das gleiche Ergebnis.
nonVolatile 8007547
 isVolatile 8007547
Dauert in der Einstellung 40s.

[Johann L. (gjlayde)]

Axel S. schrieb:
> Jetzt lese ich allerdings gerade, daß die AVR-libc auch ein Makro
> _MemoryBarrier() im Angebot hat
> (https://www.nongnu.org/avr-libc/user-manual/group__avr__cpufunc.html)
>
> Und der Text dazu liest sich, als würde das den Compiler dazu zwingen,
> Variablen-Zugriffe temporär(?) so durchzuführen als wäre die Variable
> volatile deklariert:
>
> "instructs the compiler to not cache any memory data in registers beyond
> the barrier. This can sometimes be more effective than ... volatile"
>
> Mit dieser Dokumentation bin ich aus mehreren Gründen nicht glücklich.
> "beyond the barrier" ... und wo endet diese Barriere?

Ich verstehe die Frage nicht.

Bei

int x, y;

int add_x (int i)
{
    y = x;
    ...Barrier
    return x + i;
}

muss x eben 2 mal gelesen werden: Einmal vor der Barriere, und einmal 
danach.  Weil die Barriere ein "Memory Clobber" macht muss der Wert von 
x neu gelesen werden.

> Sollte das nicht eher lauten
> "to invalidate any register caches established before the barrier"?

Nein.  Registerinhalte überleben ja, etwa der Wert von i unabhängig 
davon, ob i in einem Register lebt oder im Speicher (Frame).

> Und davon mal abgesehen, ich will gar nicht alle Variablen,

Dann brauchst du also echte _Atomic oder Äquivalente, oder anstelle von 
sei(), cli(), ATOMIC_BLOCK, die komplette Memory Barriers 
implementieren, eben was eigenes.  Zum Beispiel:

__asm ("" : "+m" (x));

Arduino F. schrieb:
> Axel S. schrieb:
>> Dummerweise implementiert ATOMIC_BLOCK aber auch das volatile
> Das tut es nicht!

Es implementiert immerhin eine volatile Barrier :-)

[Johann L. (gjlayde)]

Veit D. schrieb:
> Habe ich einen Test gemacht. :-)

Komplett belanglos.  Dass der Code macht, was du erwartest, ist 
notwendig dafür, dass der Code korrekt ist, aber nicht hinreichend.

https://de.wikipedia.org/wiki/Notwendige_und_hinreichende_Bedingung

[Arduino F. (Firma: Gast) (arduinof)]

Johann L. schrieb:
> Es implementiert immerhin eine volatile Barrier :-)

Wenn du das volatile im Inlineassembler meinst, das hat eine andere 
Bedeutung/Zweck als das C volatile.

[Johann L. (gjlayde)]

Arduino F. schrieb:
> Johann L. schrieb:
>> Es implementiert immerhin eine volatile Barrier :-)
>
> Wenn du das volatile im Inlineassembler meinst, das hat eine andere
> Bedeutung/Zweck als das C volatile.

Hat auch keiner behauptet.