Interrupt-Synchronisation

[Kevin (Gast)]

Hallo zusammen,

angenommen man habe einen µC auf dem kein OS läuft. Es gibt ein 
Hauptprogramm welches Berechnungen vornimmt und in bestimmten Variablen 
abspeichert. Das Programm ist durch Interrupt unterbrechbar. Im 
Interrupt werden die Variablen gelesen. Auch der Interrupt kann 
Berechnungen vornehmen, die im Hauptprogramm gelesen werden. Weiterhin 
nehme man an es gibt keinerlei Synchronisation zwischen Hauptprogramm 
und Interrupt(Semaphore/Mutexe...) Was ist unter diesen Voraussetzungen 
das schlimmste was passieren kann?

Gruß
Kevin

[Patrick L. (Firma: S-C-I DATA GbR) (pali64)]

Dazu setzt man sogenannte Flags die anzeigen ob Berechnungen im Gange 
sind oder abgeschlossen sind.

Sonnst :
Kevin schrieb:
> Was ist unter diesen Voraussetzungen
> das schlimmste was passieren kann?

Absolutes Chaos und undefinierte Ergebnisse ....;-)

[Teo D. (teoderix)]

Patrick L. schrieb:
> undefinierte Ergebnisse ...

https://www.mikrocontroller.net/articles/Interrupt#Interruptfeste_Programmierung


Patrick L. schrieb:
> Dazu setzt man sogenannte Flags die anzeigen ob Berechnungen im Gange
> sind oder abgeschlossen sind.

Meist reicht es, die Unterbrechungen zu unterbinden.
Was in der ISR berechnet wird, braucht halt ein Volatile, um nicht 
versehentlich, veraltete Registerinhalte zu verarbeiten.

[Wilhelm M. (wimalopaan)]

Kevin schrieb:
> Hallo zusammen,
>
> angenommen man habe einen µC auf dem kein OS läuft. Es gibt ein
> Hauptprogramm welches Berechnungen vornimmt und in bestimmten Variablen
> abspeichert. Das Programm ist durch Interrupt unterbrechbar. Im
> Interrupt werden die Variablen gelesen. Auch der Interrupt kann
> Berechnungen vornehmen, die im Hauptprogramm gelesen werden. Weiterhin
> nehme man an es gibt keinerlei Synchronisation zwischen Hauptprogramm
> und Interrupt(Semaphore/Mutexe...) Was ist unter diesen Voraussetzungen
> das schlimmste was passieren kann?

Bei Assemblerprogrammierung einfach inkonsistente Daten.
Bei C/C++ bekommst Du UB noch dazu (was in diesem Fall aber mehr ein 
weiterer formaler Aspekt ist).

Da Du ja scheinbar schon etwas von der Thematik verstanden hast, ist mir 
der Hintergrund der Frage nicht ganz klar ...

[Kevin (Gast)]

Patrick L. schrieb:
> Absolutes Chaos und undefinierte Ergebnisse ....;-)

Chaos klingt gut. Was ist mit undefiniert gemeint? Was wenn nur jeweils 
lesend der Zugriff erfolgt? Also nicht auf die gelesene Variable 
zurückgeschrieben wird. Was wäre hier der Worst Case?

[Oliver S. (oliverso)]

Kevin schrieb:
> Was ist unter diesen Voraussetzungen
> das schlimmste was passieren kann?

Nichts. Außer, das Programm ist fehlerhaft, dann gibts Chaos. Das gilt 
aber für alle fehlerhaften Programme.

Du musst halt selber dafür sorgen, daß sich ISR und Hauptprogramm nicht 
gegenseitig verheddern. Die Stichworte dazu lauten volatile und atomic.

Oliver

[Kevin (Gast)]

Wilhelm M. schrieb:
> Da Du ja scheinbar schon etwas von der Thematik verstanden hast, ist mir
> der Hintergrund der Frage nicht ganz klar ...

Ich möchte verstehen unter welchen Bedingungen man eine Synchronisation 
braucht und wann nicht, ohne jetzt ins Detail zu gehen wie z.b. so eine 
Synchronisation aussehen muss.

[Wilhelm M. (wimalopaan)]

Kevin schrieb:
> Wilhelm M. schrieb:
>> Da Du ja scheinbar schon etwas von der Thematik verstanden hast, ist mir
>> der Hintergrund der Frage nicht ganz klar ...
>
> Ich möchte verstehen unter welchen Bedingungen man eine Synchronisation
> braucht und wann nicht, ohne jetzt ins Detail zu gehen wie z.b. so eine
> Synchronisation aussehen muss.

Eine Synchronisation brauchst Du immer bei nebenläufigem Zugriff, wenn 
mindestens ein Schreiber dabei ist.
Je nach eingesetzter Sprache kann das dann unterschiedlich aussehen. Bei 
C/C++ wurde schon volatile als "Optimierungssperre" genannt. Das hat 
aber nichts mit Synchronisation zu tun. Weiterhin wird noch 
wechselseitiger Ausschluss benötigt. Das kannst Du durch atomics oder 
expliziter Syncho durch bspw. Mutexe erreichen.

[Kevin (Gast)]

Wilhelm M. schrieb:
> wechselseitiger Ausschluss

benötigt man bei mehr als einen Schreiber, richtig?

[Wilhelm M. (wimalopaan)]

Kevin schrieb:
> Wilhelm M. schrieb:
>> wechselseitiger Ausschluss
>
> benötigt man bei mehr als einen Schreiber, richtig?

Steht doch oben: mindestens einem Schreiber

[Teo D. (teoderix)]

Kevin schrieb:
> Ich möchte verstehen unter welchen Bedingungen man eine Synchronisation
> braucht und wann nicht,

Immer wenn auf die Daten, aus dem Hautprogramm und einer ISR zugegriffen 
wird.
Das mag sich in einigen (seltenen) Fällen, von ganz alleine ergeben, 
aber deine Aufmerksamkeit wird hier immer benötigt. Das ganze also mal 
in ruhe, im Kopf durchspielen.

[Monk (Gast)]

Kevin schrieb:
> Was ist unter diesen Voraussetzungen
> das schlimmste was passieren kann?

Dass du kaputte Zahlen verarbeitest.

Denn bei einem 32 Bit Integer würde ein (8 Bit) Mikrocontroller ganze 4 
Scheibzugriffe nacheinander im RAM machen. Wenn du dazwischen liest, 
bekommst du ein paar alte mit ein paar neuen Bits vermischt.

[Peter D. (peda)]

Der Interrupt kann über ein Flag signalisieren, daß neue Daten verfügbar 
sind. Das Main muß sie dann atomar lesen, damit sie konsistent bleiben.
Sinnvoll legt man dazu ein Struct an.

[der_eine (Gast)]

Servus,

kritisch sind stets Schreib- und Lesezugriffe, welche mehr als einen 
Assemblerbefehl benötigen.

Folgendes Szenario kann das vielleicht beschreiben:

Im Hauptprogramm wird eine 16-Bit Variable beschrieben (angenommen das 
teilt sich 2 Assemblerbefehle auf, High- und Low-Byte schreiben) und 
diese wird im Interrupt ausgelesen und "verarbeitet".

Es könnte folgendes passieren:
1. High-Byte wird geschrieben (Hauptprogramm)

2. Interrupt kommt
2.a. High-Byte (neu) wird im Interrupt gelesen
2.b. Low-Byte (alt) wird im Interrupt gelesen
2.c. Eine Mischung aus alt und neu wird verarbeitet - Möglicherweise 
Unfug
2.d. Interrupt beendet

3. Low-Byte wird geschrieben (Hauptprogramm)


Das gemeine ist, daß dieser Fehler wahrscheinlich nur ab und zu auftritt 
und dann auch nicht immer zu einem Fehler führt.

Die Lösung ist, sich das ganze sehr genau durchdenken. Allgemeine 
Lösungen wie "immer volatile davorschreiben" helfen da nur sehr bedingt. 
Es kommt immer auf den konkreten Fall und Architektur an.

Viel Erfolg

[Monk (Gast)]

In dem Zusammenhang haben wir das oben genannte Volatile. Es verhindert 
aber nicht Konflikte bei gleichzeitigen Zugriff auf Mehr-byte Variablen. 
Da geht es um was anderes:

Man (auch der C Compiler) benutzt CPU Register so oft wie möglich, um 
langsamere RAM-Zugriffe zu vermeiden. Beispiel:

int zaehler;

void machwas_hundert_mal() 
{
    for (i:=0; i<100; i++)
    {
       mach_was();
       zaehler=zaehler+1;
    }
}

Hier wird die Variable "zaehler" im RAM nicht hundert mal geändert, 
sondern nur einmal nach dem Ende der Schleife. Sie wird auch nicht 
hundert mal gelesen.

Wenn du jetzt den "zaehler" in einem anderen Thread (Interrupt) ausliest 
während die for-Schleife läuft, bekommst du einen veralteten Wert. Wenn 
du den Zähler im anderen Thread änderst, geht diese Änderung am Ende der 
for-Schleife verloren, sie wird einfach überschrieben!

Volatile verhindert das.

volatile int zaehler;

Nun wird die Variable innerhalb der for-Schleife tatsächlich immer 
wieder aus dem RAM gelesen, erhöht und wieder zurück ins RAM 
geschrieben. Die Schleife läuft nun deutlich langsamer.

Dein "Problem" aus der Eingangsfrage ist übrigens weder Mikrocontroller 
spezifisch noch hängt es von der Programmiersprache ab. Jedes PC 
Programm ist ebenso betroffen.

[Kevin (Gast)]

Steve schrieb:
> Kevin schrieb:
>> Was ist unter diesen Voraussetzungen
>> das schlimmste was passieren kann?
>
> Dass du kaputte Zahlen verarbeitest.
>
> Denn bei einem 32 Bit Integer würde ein (8 Bit) Mikrocontroller ganze 4
> Scheibzugriffe nacheinander im RAM machen. Wenn du dazwischen liest,
> bekommst du ein paar alte mit ein paar neuen Bits vermischt.

Das ist interessant. Daran hatte ich nicht gedacht. Kann man annehmen, 
das auf einem 32Bit Controller der Schreibzugriff auf eine (8/16/32 Bit) 
Variablen immer atomar erfolgt. Oder kann der Interrupt auch genau im 
Schreiben erfolgen?

[Kevin (Gast)]

der_eine schrieb:
> kritisch sind stets Schreib- und Lesezugriffe, welche mehr als einen
> Assemblerbefehl benötigen.

Danke, beantwortet meine Frage siehe oben, schon ziemlich gut.

[Peter D. (peda)]

Benutzt man das ATOMIC_BLOCK Macro wird der Zugriff auch nicht 
wegoptimiert, d.h. volatile mit seinen Nachteilen ist unnötig.

[Monk (Gast)]

Kevin schrieb:
> Kann man annehmen, das auf einem 32Bit Controller der Schreibzugriff
> auf eine (8/16/32 Bit) Variablen immer atomar erfolgt.

Meistens, aber nicht immer. Denn die meisten 32 Bit CPUs können auch in 
kleineren Einheiten auf das RAM zugreifen. Ich bin nicht sicher, ob man 
sich darauf verlassen kann, dass 32 Bit Variablen immer am Stück gelesen 
und geschrieben werden. Hängt sicher auch vom Compiler und dessen 
Optionen ab, nicht nur von der CPU.

[Wilhelm M. (wimalopaan)]

Peter D. schrieb:
> Benutzt man das ATOMIC_BLOCK Macro wird der Zugriff auch nicht
> wegoptimiert, d.h. volatile mit seinen Nachteilen ist unnötig.

Schaltet nur die Interrupts bei AVR ab. Trotzdem brauchst Du volatile.

[Εrnst B. (ernst)]

Wilhelm M. schrieb:
> Schaltet nur die Interrupts bei AVR ab.

nicht nur. ATOMIC_BLOCK enthält auch ein
 _asm_ volatile ("" ::: "memory");

also eine memory barrier. d.H. alle Variablen, die im ATOMIC_BLOCK 
geändert werden, sind vor dem Re-Aktivieren der ISRs auch wirklich 
geschrieben.

[(prx) A. K. (prx)]

Steve schrieb:
> Kevin schrieb:
>> Kann man annehmen, das auf einem 32Bit Controller der Schreibzugriff
>> auf eine (8/16/32 Bit) Variablen immer atomar erfolgt.
>
> Meistens, aber nicht immer. Denn die meisten 32 Bit CPUs können auch in
> kleineren Einheiten auf das RAM zugreifen. Ich bin nicht sicher, ob man
> sich darauf verlassen kann, dass 32 Bit Variablen immer am Stück gelesen
> und geschrieben werden. Hängt sicher auch vom Compiler und dessen
> Optionen ab, nicht nur von der CPU.

Probleme kann es bei Misaligmment geben, in gepackten Strukturen und in 
Bitfeldern.

[Kevin (Gast)]

Danke schonmal an alle.

Ich habe mal nachgelesen.FreeRtos z.b., nutzt zur Synchronisation 
zwischen 2 Tasks Mutexe, jedoch zwischen Task und Interrupt Semaphore. 
Vielleicht kann man sich da was abgucken, wenn es nicht zu komplex 
implementiert ist.

[Kevin (Gast)]

(prx) A. K. schrieb:
> Probleme kann es bei Misaligmment geben, in gepackten Strukturen und in
> Bitfeldern.

Was meinst du mit Misalignment?

[Teo D. (teoderix)]

Oje, nu kloppen sich die Spezis die Köppe ein. Dabei will der TO doch 
nur Fahrradfahren lernen und nicht gleich mit nem Euro-Fighter, auf 
seine Spatzen losgehen....

[(prx) A. K. (prx)]

Kevin schrieb:
> (prx) A. K. schrieb:
>> Probleme kann es bei Misaligmment geben, in gepackten Strukturen und in
>> Bitfeldern.
>
> Was meinst du mit Misalignment?

Wenn die 4 Bytes nicht an einer Adresse %4==0 liegen, die Maschine einen 
solchen Zugriff nicht zulässt und der Compiler deshalb daraus mehrere 
Zugriffe machen muss.

[Wilhelm M. (wimalopaan)]

Kevin schrieb:
> Danke schonmal an alle.
>
> Ich habe mal nachgelesen.FreeRtos z.b., nutzt zur Synchronisation
> zwischen 2 Tasks Mutexe, jedoch zwischen Task und Interrupt Semaphore.
> Vielleicht kann man sich da was abgucken, wenn es nicht zu komplex
> implementiert ist.

Jetzt doch mit OS?

Wenn Du nicht in Assembler programmierst (also etwa C/C++), dann weißt 
Du nicht, wie ein Objektzugriff gemacht wird. Du musst also vom 
Schlimmsten ausgehen, und das ist dann eine RMW-Folge. Also etwas 
nicht-atomares.

Daher hast Du zwei Aufgaben:

1) Du musst Atomarität herstellen durch
1a) atomics (s.a. C/C++-Bibliothek), oder
1b) explizite kritische Bereiche mit wechselseitigem Ausschluss

und

2) Du musst den Compiler für die gemeinsam genutzten Datenstrukten am 
Optimieren hindern. Das macht man bei C/C++ durch volatile-Deklaration.

Bei den kritichen Bereichen musst Du noch zwischen bedingten und 
unbedingten KB unterscheiden. Für bedingte KB brauchst Du dann noch 
Bedingungsvariablen (ich meiner hier das Konzept, keine einfachen Flags 
oder so).

[(prx) A. K. (prx)]

Teo D. schrieb:
> Oje, nu kloppen sich die Spezis die Köppe ein. Dabei will der TO doch
> nur Fahrradfahren lernen und nicht gleich mit nem Euro-Fighter, auf
> seine Spatzen losgehen....

Seine Fragen sind qualifiziert genug um ihn nicht als Spielkind zu 
behandeln.

[Kevin (Gast)]

Wilhelm M. schrieb:
> Jetzt doch mit OS?

Jetzt doch mit OS?
Nein,  FreeRtos war in meiner Internetsuche nur recht weit oben ;-). Und 
es ist recht interessant implementiert.

Wilhelm M. schrieb:
> Bei den kritichen Bereichen musst Du noch zwischen bedingten und
> unbedingten KB unterscheiden.

Was ist KB?

[Wilhelm M. (wimalopaan)]

Εrnst B. schrieb:
> Wilhelm M. schrieb:
>> Schaltet nur die Interrupts bei AVR ab.
>
> nicht nur. ATOMIC_BLOCK enthält auch ein
>  _asm_ volatile ("" ::: "memory");
>
> also eine memory barrier. d.H. alle Variablen, die im ATOMIC_BLOCK
> geändert werden, sind vor dem Re-Aktivieren der ISRs auch wirklich
> geschrieben.

Nö.

static __inline__ uint8_t __iCliRetVal(void)
{
    cli();
    return 1;
}

#define ATOMIC_BLOCK(type) for ( type, __ToDo = __iCliRetVal(); \
                         __ToDo ; __ToDo = 0 )

[Wilhelm M. (wimalopaan)]

Kevin schrieb:
> Wilhelm M. schrieb:
>> Jetzt doch mit OS?
>
> Jetzt doch mit OS?
> Nein,  FreeRtos war in meiner Internetsuche nur recht weit oben ;-). Und
> es ist recht interessant implementiert.
>
> Wilhelm M. schrieb:
>> Bei den kritichen Bereichen musst Du noch zwischen bedingten und
>> unbedingten KB unterscheiden.
>
> Was ist KB?

Kritischer Bereich: ein Code-Abschnitt, in dem wechselseitiger 
Ausschluss herrschen soll

[Εrnst B. (ernst)]

Wilhelm M. schrieb:
> Nö.

Nö.

static __inline__ void __iSeiParam(const uint8_t *__s)
{
  __asm__ __volatile__ ("sei" ::: "memory");
  __asm__ volatile ("" ::: "memory");
  (void)__s;
}

der Trick liegt im "type", da wird für die sreg-zwischenspeichervariable 
ein

  __attribute__((__cleanup__(__iSeiParam)))

gesetzt.

[Kevin (Gast)]

(prx) A. K. schrieb:
> Wenn die 4 Bytes nicht an einer Adresse %4==0 liegen, die Maschine einen
> solchen Zugriff nicht zulässt und der Compiler deshalb daraus mehrere
> Zugriffe machen muss.

Danke. Misalignment war mir schon klar, jetzt habe ich auch die 
Verbindung warum es in meinem betrachteten Fall zum Problem werden kann.

[Wilhelm M. (wimalopaan)]

Εrnst B. schrieb:

>
> der Trick liegt im "type", da wird für die sreg-zwischenspeichervariable
> ein
>

>   __attribute__((__cleanup__(__iSeiParam)))
>

> gesetzt.

Ja, aber nur dafür.

[Εrnst B. (ernst)]

Wilhelm M. schrieb:
> Ja, aber nur dafür.

Das ist eine "destruktor"-Funktion, die immer ausgeführt wird, wenn die 
Variable den scope verlässt.

Hat den Sinn, dass auch bei einem

ATOMIC_BLOCK(ATOMIC_FORCEON) {
  ...
  if(x) return; // oder break
  ...
}

das "return" ein "sei" auslöst. Sonst wären vorzeitigen Verlassen des 
Blocks die Interrupts immer noch gesperrt.

Die darin deklarierte barrier gilt für den gesamten RAM, nicht nur die 
eine Variable.

das cli beim Betreten hat keine solche optimization barrier.

d.H. der Compiler könnte zwar Berechnungen vor dem Atomic-Block in 
diesen hineinziehen, aber nichts aus dem Block herausnehmen.

Nach Verlassen des Atomic Blocks ist jedenfalls sichergestellt, dass 
alle Variablen sauber in den RAM zurückgespeichert wurden.

[Wilhelm M. (wimalopaan)]

Εrnst B. schrieb:
> Nach Verlassen des Atomic Blocks ist jedenfalls sichergestellt, dass
> alle Variablen sauber in den RAM zurückgespeichert wurden.

Nö.

#include <stdint.h>
#include <util/atomic.h>
    
static /*volatile */ uint8_t x;

int main() {
    ATOMIC_BLOCK(ATOMIC_RESTORESTATE) {
        x = 0;
    }
}

ergibt

main:
in r24,__SREG__  ;  _1, MEM[(volatile uint8_t *)63B]
cli
out __SREG__,r24         ;  MEM[(volatile uint8_t *)63B], _1
ldi r24,0                ;
ldi r25,0                ;
ret

[Εrnst B. (ernst)]

Wilhelm M. schrieb:
> Nö.

Warum Nö? Dein Beispiel bestätigt doch 1:1 was ich geschrieben habe.
Nur dass der Compiler "x" eben ganz wegoptimiert hat. Darf er, wird ja 
nie wieder gelesen.

Pack in dein Beispiel ans Ende noch ein "return x", dann siehst du 
exakt, dass es zuerst in den RAM geschrieben wird, und für's return auch 
wieder aus dem RAM gelesen wird.

main:
        in r24,__SREG__
        cli
        sts x,__zero_reg__
        out __SREG__,r24
        lds r24,x
        ldi r25,0
ret

Selben Effekt hast du auch, wenn "x" nicht static ist.

[Wilhelm M. (wimalopaan)]

Εrnst B. schrieb:
> Warum Nö? Dein Beispiel bestätigt doch 1:1 was ich geschrieben habe.
> Nur dass der Compiler "x" eben ganz wegoptimiert hat. Darf er, wird ja
> nie wieder gelesen.

Du sagst, dass im ATOMIC_BLOCK alle(!) dort zugegriffenen Variablen 
automatich volatile wären. Wie Du siehst, stimmt diese Aussage nicht!

Wenn es volatile wäre, dürfte er den Zugriff auf x nicht wegoptimieren. 
Du kannst Dich davon leicht überzeugen, indem Du in meinem Beispiel 
einfach mal die volatile Deklaration einkommentierst.

[Εrnst B. (ernst)]

Wilhelm M. schrieb:
> Du sagst, dass im ATOMIC_BLOCK alle(!) dort zugegriffenen Variablen
> automatich volatile wären. Wie Du siehst, stimmt diese Aussage nicht!

Das habe ich NIE behauptet. Es geht ja gerade darum, dass die 
Variablen NICHT Volatile werden müssen, weil der Atomic-Block das 
Rückschreiben erzwingt. Damit ist das übliche Problem von "Variable wird 
in ISR und main verwendet" in den üblichen Fällen erschlagen, OHNE 
dass man sich die anderen Nachteile von volatile einfängt.

[Wilhelm M. (wimalopaan)]

Εrnst B. schrieb:
> Wilhelm M. schrieb:
>> Du sagst, dass im ATOMIC_BLOCK alle(!) dort zugegriffenen Variablen
>> automatich volatile wären. Wie Du siehst, stimmt diese Aussage nicht!
>
> Das habe ich NIE behauptet. Es geht ja gerade darum, dass die
> Variablen NICHT Volatile werden müssen, weil der Atomic-Block das
> Rückschreiben erzwingt. Damit ist das übliche Problem von "Variable wird
> in ISR und main verwendet" in den üblichen Fällen erschlagen, *OHNE*
> dass man sich die anderen Nachteile von volatile einfängt.

Schau Dir folgendes an

#include <stdint.h>
#include <util/atomic.h>
    
static /*volatile */ uint8_t x;

ISR( TIMER2_OVF_vect ) {
    uint8_t y = x;
}

int main() {
    ATOMIC_BLOCK(ATOMIC_RESTORESTATE) {
        x = 0;
    }
}

Ergibt:

__RAMPZ__ = 0x3b
__CCP__ = 0x34
.text
.type   TIMER2_OVF_vect, @function
TIMER2_OVF_vect:
__gcc_isr 1      ;
__gcc_isr 2      ;
reti
__gcc_isr 0,r0
.size   TIMER2_OVF_vect, .-TIMER2_OVF_vect
.section        .text.startup,"ax",@progbits
.type   main, @function
main:
in r24,__SREG__  ;  _1, MEM[(volatile uint8_t *)63B]
cli
out __SREG__,r24         ;  MEM[(volatile uint8_t *)63B], _1
.L3:
rjmp .L3                 ;
.size   main, .-main

Atomarität und Optimierungssperre (ggf. durch volatile) sind zwei 
unterschiedliche Dinge.

[Peter D. (peda)]

Wilhelm M. schrieb:
> Wenn es volatile wäre, dürfte er den Zugriff auf x nicht wegoptimieren.

Dein Beispiel ist allerdings sehr speziell, da es keine Loop enthält. 
Typisch wird bei MC-Anwendungen das Main nie verlassen. Ich wüßte 
jedenfalls nicht, wie dann eine sinnvolle Anwendung zustande kommen 
soll.
Außerdem sagst Du mit dem static, daß die Variable nirgends anders 
zugegriffen werden kann.

Mach ne Loop ins Main, nimm das static weg, dann erfolgt auch die 
Zuweisung.

[Εrnst B. (ernst)]

Wilhelm M. schrieb:
> Schau Dir folgendes an

Wieder ein Beispiel, was meine Aussagen belegt bzw. zumindest nicht 
widerlegt.
In dem ASM-Code, den du zeigt, findet keinerlei nicht-synchronisierter 
Zugriff auf "uint8_t x" statt. Exakt das, was der Atomic_block erreichen 
soll.
QED.

[Teo D. (teoderix)]

Teo D. schrieb:
> Oje, nu kloppen sich die Spezis die Köppe ein.

:DDD

[Peter D. (peda)]

Man kann aber auch im Main auf volatile casten. Dann wird im Main der 
Zugriff erzwungen und im Interrupt kann die Variable weiterhin optimiert 
werden.

#define IVAR(x)         (*(volatile typeof(x)*)&(x))

[Gerald K. (geku)]

Ich würde in der Interruptroutine keine Berechnungen oder andere 
komplexe Aufgaben durchführen. Die Interruptfunktionen nur füe 
IO-Operationen verwenden. Z.B. Wert von einem Port abholen und in ein 
FIFO schreiben und dem Hintergrund mittels Flag signalisieren das etwas 
im FIFO abholbar ist. Interrupt nur verwenden wenn die Gefahr besteht 
etwas im Hintergrund zu verpassen.

Ist der Hintergrund fertig, dann kann er zum Energiesparen, den 
Sleepmodus aktivieren. Dieser kann in einer Interruptroutine wieder 
deaktiviert werden.

Kurz eine Bemerkung zum FIFO:

Die Interruptroutine hat alleinigen Zugriff zum Schreibzeiger, der 
Hintergrund alleinigen Zugriff zum Lesezeiger. So kommen sich Interrupt 
und Hintergrund nicht in die Quere.

[Peter D. (peda)]

Gerald K. schrieb:
> Die Interruptroutine hat alleinigen Zugriff zum Schreibzeiger, der
> Hintergrund alleinigen Zugriff zum Lesezeiger.

Beim Sende-FIFO dann umgekehrt.

[c-hater (Gast)]

Kevin schrieb:

> Kann man annehmen,
> das auf einem 32Bit Controller der Schreibzugriff auf eine (8/16/32 Bit)
> Variablen immer atomar erfolgt.

Nein, das kann man nicht.

Es ist zwar der Regelfall, aber, wie bei jeder Regel: es gibt auch viele 
Ausnahmen. Diese Ausnahmen sind sehr architekturspezifisch. Wobei hier 
"Architektur" mehr umfasst, als das, was man üblicherweise darunter 
versteht. Neben der CPU/MCU selber nämlich auch noch die konkrete 
Schaltung, in der sie steckt.

[(prx) A. K. (prx)]

c-hater schrieb:
> Neben der CPU/MCU selber nämlich auch noch die konkrete Schaltung, in
> der sie steckt.

Wobei eine Aufteilung auf mehrere Zugriffe im Businterface für 
Interrupts innerhalb eines Cores atomar bleibt.

[c-hater (Gast)]

(prx) A. K. schrieb:

> Wobei eine Aufteilung auf mehrere Zugriffe im Businterface für
> Interrupts innerhalb eines Cores atomar bleibt.

Das kannst du für jede Architektur garantieren?

[(prx) A. K. (prx)]

c-hater schrieb:
> Das kannst du für jede Architektur garantieren?

Bei Mikrocontrollern mit einem Core bin ich mir da ziemlicher sicher.