STM32 atomare Operation

[Bert S. (kautschuck)]

Hi,

Ich habe ein Interrupt basiertes Programm und möchte nicht, dass mir ein 
Interrupt dazwischenfunkt, wenn eine Variable beschrieben wird. Was 
genau ist die minimale atomare Funktion, wo ein Interrupt nicht 
unterbrechen kann? Das schreiben einer Variable gehört wahrscheinlich 
dazu, oder?

[Ingo Less (Gast)]

Wenn du ganz sicher gehen willst, "klammerst" du deine Operation in 
einen atomaren Block:

__disable_orq();
//some code
__enable_irq();

[MaWin (Gast)]

Bert S. schrieb:
> Was genau ist die minimale atomare Funktion, wo ein Interrupt nicht
> unterbrechen kann?

Das ist im C-Standard leider nicht beschrieben und hängt von deinem 
Compiler ab.
(Es gibt erst neuerdings Bestrebungen sowas in C und C++ einzubringen.)

[Phantomix X. (phantomix)]

Ich würd mal sagen dass du dich da auf Assembler-Ebene bewegst und 
empfehle dir mal nach dem passenden Instruction Set für deinen Cortex M 
zu suchen.

Ansonsten gibt es aber auch noch die Möglichkeit, dazwischenfunkende 
Interrupts kurz zu deaktivieren, oder aber kritischen Code in einem 
hochpriorisierten Interrupt auszuführen sodass der niederpriore nicht 
dazwischenfunken kann (dann hast du jedoch, je nach Aufgabe, das Problem 
entweder gelöst oder einfach nur umgedreht)

[Rolf M. (rmagnus)]

MaWin schrieb:
> (Es gibt erst neuerdings Bestrebungen sowas in C und C++ einzubringen.)

Naja… in C ist es bereits seit 10 Jahren drin, in C++ auch schon seit 
ein paar Jahren. Das ist dann doch etwas mehr als "neuerdings 
Bestrebungen, sowas einzubringen".

Bert S. schrieb:
> Was genau ist die minimale atomare Funktion, wo ein Interrupt nicht
> unterbrechen kann? Das schreiben einer Variable gehört wahrscheinlich
> dazu, oder?

Nicht unbedingt.
Im Falle von gcc kannst du das hier dir mal anschauen:
https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html

In Standard C gibt es zu atomaren Operationen folgendes:
https://en.cppreference.com/w/c/atomic

In Standard C++ gibt es noch folgendes:
https://en.cppreference.com/w/cpp/atomic/atomic

Inwieweit das für STM32 verfügbar ist, weiß ich aber nicht.

[Klaus W. (mfgkw)]

Nicht unterbrechbar sind:
- Lesen eines 32-Bit-Werts (zumindest wenn aligned; wenn nicht bin ich 
mir nicht sicher)
- Ebenso das Schreiben von 32 Bit
- Lesen oder Setzen eines Bits über bit banding

Gefährdet ist demnach bspw. in C: i++ (da Lesen von Speicher in 
Register, ändern, zurückschreiben).
Die Operation wäre ok, wenn man i in ein Register zwingt (register 
uint32_t i __asm("r0");).

[Homer J. Simpson (Gast)]

> atomare Operation

Es heisst nukular!

[Uwe B. (Firma: TU Darmstadt) (uwebonnes)]

Was ist mir den ldrex und strex Befehlen?

[MaWin (Gast)]

Rolf M. schrieb:
> Naja… in C ist es bereits seit 10 Jahren drin, in C++ auch schon seit
> ein paar Jahren. Das ist dann doch etwas mehr als "neuerdings
> Bestrebungen, sowas einzubringen".

10 Jahre sind "neuerdings", bei so etwas wie Programmiersprachen.
Denn die Neuerungen müssen 1) in den Compilern ankommen, die von den 
Leuten genutzt werden und 2) die Neuerungen müssen von den Leuten 
genutzt und verstanden werden. Was idR erst nach Schritt 1 passiert.
In einer Welt, wo regelmäßig 10/20 Jahre alte Compiler verwendet werden 
(ich sage nur: "der ist aber zertigiziert! Da können wir nicht von 
weg!") und alte Standards zum Einsatz kommen (C89, um die Kompatibilität 
mit allem möglichen Scheiß zu bewahren), dauert so etwas halt lange.

[Dymo Fond (Gast)]

MaWin schrieb:
> 10 Jahre sind "neuerdings", bei so etwas wie Programmiersprachen.
> Denn die Neuerungen müssen 1) in den Compilern ankommen,

Es gibt noch einen Zwischenschritt. Es nützt wenig wenn das Front-End 
des Compilers (Parser) die neuen Funktionen versteht, aber wenn im 
Backend (Codegenerator) dafür kein Code generiert wird oder die 
Bibliotheksfunktionen nicht oder als leere Funktionen implementiert 
sind.

Leider ist das besonders bei retargetable Compilern immer mal wieder der 
Fall, wenn schnell eine Anpassung einer neuen Version an einen 
Mikrocontroller vorgenommen wird.

> (ich sage nur: "der ist aber zertigiziert! Da können wir nicht von
> weg!")

Was eine gute Sache ist wenn du schon mal mit einer nicht 
implementierten Funktion auf die Nase gefallen bist.

[Rolf M. (rmagnus)]

MaWin schrieb:
> Rolf M. schrieb:
>> Naja… in C ist es bereits seit 10 Jahren drin, in C++ auch schon seit
>> ein paar Jahren. Das ist dann doch etwas mehr als "neuerdings
>> Bestrebungen, sowas einzubringen".
>
> 10 Jahre sind "neuerdings", bei so etwas wie Programmiersprachen.

Aber es ist eben schon lange keine Bestrebung mehr, es einzubringen, 
sondern es ist drin. Dass es teils lange dauern kann, bis das auch in 
einer signifikanten Zahl der Compiler  angekommen ist und in manchen nie 
ankommen wird (wie ist eigentlich inzwischen der Stand von C99 in Visual 
Studio?), ist schon klar.

Dymo Fond schrieb:
>> (ich sage nur: "der ist aber zertigiziert! Da können wir nicht von
>> weg!")
>
> Was eine gute Sache ist wenn du schon mal mit einer nicht
> implementierten Funktion auf die Nase gefallen bist.

Ja. Schade nur, dass man sich im Gegenzug dann mit Compilern auf dem 
Niveau von "vor dem Krieg" rumschlagen muss.