atomic-lib für stm32

[Leo B. (luigi)]

Hey Leute,

wollte mal fragen, ob jemand eine atomic-lib, wie es sie für den AVR-GCC 
gibt 
(http://www.nongnu.org/avr-libc/user-manual/group__util__atomic.html), 
auch für die STM32 kennt. Compiler soll auch hier der GCC sein falls das 
wichtig ist.

Ich konnte leider nichts passendes im Internet finden, was mich 
allerdings schon ein wenig wundert. Als ob beim STM32 keiner mehr 
atomare Operationen durchführen möchte...

Vielen Dank
Gruß Leo

[Reiner S. (Gast)]

Da der AVR nur 8 Bit hat und ein int 16 Bit sind Operationen wie int i++ 
nicht atomar da sie 2 Speicher Zugriffe erfordern.

Der STM32 (ARM) ist ein 32 Bitter und ein int hat 32 Bit und somit ist 
int i++ atomar.

Außerdem hat der ARM einen Befehlssatz der modify Operationen auf 
Assembler Ebene atomar ausführt.
Mit dem STM32F10x_StdPeriph_Driver werden auch I/O Zugriffe atomar.

[Dr. Sommer (Gast)]

Reiner S. schrieb:
> Der STM32 (ARM) ist ein 32 Bitter und ein int hat 32 Bit und somit ist
> int i++ atomar.
Diese Folgerung stimmt nicht notwendigerweise, ist aber im Falle des ARM 
korrekt. Was allerdings nicht korrekt ist, ist die Annahme dass 
"Variable lesen => Variable inkrementieren => Variable zurückspeichern" 
atomar ist! Dazu braucht man schon Locks. Das geht aber auf 
Multithreading-freundlichen CPU's wie eben dem ARM wohl recht effizient.

Reiner S. schrieb:
> Außerdem hat der ARM einen Befehlssatz der modify Operationen auf
> Assembler Ebene atomar ausführt.
Aber eben nur auf Registern.
> Mit dem STM32F10x_StdPeriph_Driver werden auch I/O Zugriffe atomar.
Ach? Und wie sieht es mit folgendem aus (aus eben dieser Library, 
gekürzt):

void ADC_Cmd(ADC_TypeDef* ADCx, FunctionalState NewState)
{
  if (NewState != DISABLE) {
    ADCx->CR2 |= (uint32_t)ADC_CR2_ADON; // <-- (mindestens) 3 Instruktionen, überhaupt nicht atomar
  }  else  {
    ADCx->CR2 &= (uint32_t)(~ADC_CR2_ADON); // dito
  }
}

[Reiner S. (Gast)]

> Der STM32 (ARM) ist ein 32 Bitter und ein int hat 32 Bit und somit ist
> int i++ atomar.
>>Diese Folgerung stimmt nicht notwendigerweise, ist aber im Falle des ARM
>>korrekt. Was allerdings nicht korrekt ist, ist die Annahme dass
>>"Variable lesen => Variable inkrementieren => Variable zurückspeichern"
>>atomar ist! Dazu braucht man schon Locks. Das geht aber auf
>>Multithreading-freundlichen CPU's wie eben dem ARM wohl recht effizient.
Beim AVR ist int i++ schon auf Registerebene nicht atomar und das meinte 
ich.

Dr. Sommer schrieb:
>> Mit dem STM32F10x_StdPeriph_Driver werden auch I/O Zugriffe atomar.
> Ach? Und wie sieht es mit folgendem aus (aus eben dieser Library,
> gekürzt):void ADC_Cmd(ADC_TypeDef* ADCx, FunctionalState NewState)
> {
>   if (NewState != DISABLE) {
>     ADCx->CR2 |= (uint32_t)ADC_CR2_ADON; // <-- (mindestens) 3
> Instruktionen, überhaupt nicht atomar
>   }  else  {
>     ADCx->CR2 &= (uint32_t)(~ADC_CR2_ADON); // dito
>   }
> }

Da habe ich mich unklar ausgedrückt denn ich meine die Zugriffe auf Bit 
Ebene. Das Beispiele mit kann nicht atomar seinen und ST überlässt es 
dem  Anwender bei bedarf vor Aufruf der Funktion die Interrups zu 
sperren.
Das halte ich für eine gute Idee.

[Dr. Sommer (Gast)]

Reiner S. schrieb:
> Beim AVR ist int i++ schon auf Registerebene nicht atomar und das meinte
> ich.
Jo. Dass das beim ARMv7M auf Registerebene atomar ist bringt aber 
praktisch nix, da es auf Speicherebene nicht atomar ist (außer 
Geschwindigkeit).

Reiner S. schrieb:
> Da habe ich mich unklar ausgedrückt denn ich meine die Zugriffe auf Bit
> Ebene.
Ja aber das bringt nix, da es immer noch load-modify-store ist! Ob die 
Funktion intern mit 1 oder mehreren Operationen auf dem temporären 
Register arbeitet macht doch überhaupt keinen Unterschied.
> Das Beispiele mit kann nicht atomar seinen und ST überlässt es
> dem  Anwender bei bedarf vor Aufruf der Funktion die Interrups zu
> sperren.
> Das halte ich für eine gute Idee.
Ja, ist es auch. Aber zu behaupten die StdPeriphal Library wäre "atomar" 
ist gefährlich ;-)

[Leo B. (luigi)]

Entweder ist meine Frage unpräziese gestellt, oder das Thema hat sich 
ein wenig vom Ursprünglich angesprochenen/gefragten entfernt.

Klar bietet die ARM-Cortex nen haufen Atomarer Operationen aber bereits 
ein einfaches togglen eines Port-Pins (nur als Beispiel) gehört meines 
Wissens schon nicht mehr dazu...
Da ich aber das Interrupts sperren und freigeben mit 2 Funktionen nicht 
halb so übersichtlich finde wie einen ATOMIC_BLOCK hätte ich mich 
gefreut wenn bereits jemand so etwas für den STM32 (in meinem Fall 
konkret den STM32F100) geschrieben und veröffentlicht hätte. Ich selbst 
stehe noch sehr am Anfang des Verständnisses der ARM-Rechenkerne und 
könnte soetwas vermutlich nicht halb so elegant und performant 
implementieren wie ein erfahrener Programmierer.

Zum Vergleich:

[...]
someNonAtomicCode();
__disable_irq();
doSomeThing();
// some comment
doAtomicStuff();
// another comment
lastAtomicOperation();
__enable_irq();
someNonAtomicCode();
[...]

[...]
someNonAtomicCode();
ATOMIC_BLOCK(...)
{
    doSomeThing();
    // some comment
    doAtomicStuff();
    // another comment
    lastAtomicOperation();
}
someNonAtomicCode();
[...]

Darf jetzt jeder für sich entscheiden was übersichtlicher ist aber meine 
Meinung dazu steht fest...

es fehlt wie gesagt nur die Atomic-lib. Hoffentlich finde ich noch eine.
Danke
Gruß Leo

[Dr. Sommer (Gast)]

Es geht einfach nur darum __disable_irq(); und __enable_irq(); um einen 
Code-Block zu packen? Das ist doch supereasy. In C++ geht es elegant mit 
lambdas:

template <typename F> inline void doAtomic (F f)  {
  __disable_irq ();
  f ();
  __enable_irq ();
}

int main () {
  doAtomic ([] () {
    // ... geschützte Operationen ...
  });
}

Wenn man aus irgendwelchen obskuren Gründen kein C++ verwenden darf muss 
man sich mit ekligen C-Makros behelfen, muss hier mal ein C-Frickler 
helfen :o)

[Karl H. (kbuchegg) (Moderator)]

Dr. Sommer schrieb:

> man sich mit ekligen C-Makros behelfen, muss hier mal ein C-Frickler
> helfen :o)

In C benutzt man einen Trick.
Die Frage ist, wie kriege ich den Compiler dazu
* den { } Block so zu verpacken, dass
* ich am Anfang des Blocks eine Anweisung einschummeln kann
* ich am ende des Blocks eine Anweisung einschummeln kann

Dazu bietet sich wieder mal eine for-Schleife an.
Ihre 3 Teile benutze ich
* um die Initialisierungsphase dazu zu benutzen, eine Anweisung vor den 
Block zu platzieren
* die Laufbedingung dazu, damit der Block nur 1 mal ausgeführt wird
* den Inkrementteil, um damit die abschliessende Anweisung an das 
Blockende zu setzen und gleichzeitig die Laufbedingung ungültig zu 
machen.

Wie würde sich das in Langform schreiben?

Ich würde zb schreiben

  for( __disable_irq(), uint8_t cont = 1; cont == 1; __enable_irq(), cont = 0 )
  {
    Anweisungen ....
  }

Anstelle des 'umständlichen' for, wird der Teil noch in ein Makro 
verpackt und nähere mich damit dem Ziel

#define ATOMIC_BLOCK() for( __disable_irq(), uint8_t __cont = 1; __cont == 1; __enable_irq(), __cont = 0 )

was jetzt noch fehlt, sind diverse Argumente an das Makro mit denen man 
das Verhalten steuern kann. Ob man die braucht ist eine andere Frage, 
zur Not kann man ja auch 'verschiedene' ATOMIC_BLOCK Makros machen.

(Ja ich weiß, der Name der Hilfsvariablen __cont ist nicht ganz koscher. 
Ich rechne allerdings so ein Makro schon mehr der Implementierung zu. 
Von daher nehme ich mir das Recht raus, derartige Namen verwenden zu 
dürfen.)

[Dr. Sommer (Gast)]

Karl Heinz Buchegger schrieb:
> In C benutzt man einen Trick.
Das ist ja mal wieder maximal bösartig... ;-)

[Karl H. (kbuchegg) (Moderator)]

Dr. Sommer schrieb:
> Karl Heinz Buchegger schrieb:
>> In C benutzt man einen Trick.
> Das ist ja mal wieder maximal bösartig... ;-)


:-)
Ich habs mir von der avr-libc abgeschaut.
Ich hab mich nämlich auch gefragt, wie kriegen die das hin.
Wobei die noch einen zusätzlichen Trick verwenden, der aber nicht 
portabel ist. Die benutzen __cleanup, welches als eine Art Destruktor 
fungiert.
Aber so müsste es auch gehen, so lange sich keiner aus der for-Schleife 
raus-breaked. Womit dann auch der 'schwache' Punkt dieser Lösung 
angesprochen wäre.

[Leo B. (luigi)]

ich steig ja mit den GCC-Compilern noch nicht so recht durch, aber ist 
GCC nicht gleich GCC? also Dinge die dieses cleanup-attribut die beim 
AVR-GCC offenbar funktionieren, sollten doch auch beim ARM-GCC 
funktionieren oder nicht?
wenn nicht, kann mir jemand sagen wo ich ein entsprechendes Manual 
finde, wo solche tricks drin stehen? sowohl für AVR als auch für den 
ARM.
Ich habe bisher nur diese online-Doku
http://gcc.gnu.org/onlinedocs/
gefunden und die unterscheidet nicht zwischen arm und avr...

passender Link zum Thema:
http://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html

cleanup müsste dann beim STM32 genauso funktionieren. Auch wenn nicht 
ganz klar wird was der cleanup-function als Parameter übergeben wird, 
nehme ich doch an, dass es ein Pointer auf entsprechende Variable sein 
wird.

wäre ja sehr angenehm wenn man den AVR-Code da portieren könnte.

Danke euch
Gruß Leo

[Johann L. (gjlayde)]

Leo B. schrieb:
> ich steig ja mit den GCC-Compilern noch nicht so recht durch, aber ist
> GCC nicht gleich GCC? also Dinge die dieses cleanup-attribut die beim
> AVR-GCC offenbar funktionieren, sollten doch auch beim ARM-GCC
> funktionieren oder nicht?

Für diese Attribute: Ja.

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

Wäre noch anzumerken, dass man diverse atomare Operationen im RAM auf 
ARMs ab ARMv6 auch ohne Abschaltung der Interrupts erledigen kann, indem 
man LDREX/STREX bzw. die entsprechenden Funktionen vom CMSIS verwendet. 
Da dabei eine Datenabhängigkeit enthalten ist, gibts auch keine Probleme 
mit der Reihenfolge und Reordering.

Wenn man Interrupts abschaltet muss man immer drauf achten, dass der 
Compiler keine komplexe Operation vom Code davor zwischen rein mogelt. 
Das kann einem bei LDREX/STREX zwar auch passieren, aber da spielt es 
kaum eine Rolle.

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

Bissel was in der Hinsicht gibts im GCC plattformübergreifend schon von 
Haus aus, z.B.
      result = __sync_add_and_fetch(&var, 1);
für atomare Addition einer Variablen.

http://gcc.gnu.org/onlinedocs/gcc-4.7.3/gcc/_005f_005fsync-Builtins.html#_005f_005fsync-Builtins
http://gcc.gnu.org/onlinedocs/gcc-4.7.3/gcc/_005f_005fatomic-Builtins.html#_005f_005fatomic-Builtins

[Johann L. (gjlayde)]

Ja, ist alles "legacy" :-)

Wenn man es wirklich protabel halten will, dann mit C++11 und den Memory 
Models und GCCs libatomic, die m.W. für ARM implementiert ist.

http://gcc.gnu.org/onlinedocs/gcc-4.7.3/gcc/_005f_005fatomic-Builtins.html#g_t_005f_005fatomic-Builtins

[Adib (Gast)]

die Implementierung des ATOMIC_BLOCK im der avrlibc ist schon eine große 
Sache. Speziell weil man auch heraus break-en und return-en kann.

Um nicht immer glabel die Interrupts abzuschalten, modifiziere ich beim 
STM32 die BASEPRIO nach Bedarf. Dann werden nur gewisse Interrupts 
ausgeblendet.

HTH, Adib.
--

[Philipp S. (schroedi)]

In einem STM32-Programm für einen Versuchsaufbau habe ich auch ein paar 
Codezeilen, die nicht durch einen Interrupt unterbrochen werden dürfen. 
Das ATOMIC_BLOCK - Konstrukt vom AVR kenne ich auch und finde es 
nützlich.
Da sich die Lösung von Karl Heinz bei mir mit GCC nicht kompilieren 
lässt, habe ich etwas gebastelt. Mit den Informationen von 
http://stm32f4-discovery.com/2015/06/how-to-properly-enabledisable-interrupts-in-arm-cortex-m/ 
komme ich auf folgende Lösung, welche die Funtionalität von 
ATOMIC_BLOCK(ATOMIC_RESTORESTATE) für den AVR nachbildet:

#define ATOMIC_BLOCK for( uint32_t __cond = 1, __prim = __get_PRIMASK(); __cond != 0 ? __disable_irq() : 0, __cond != 0; __prim == 0 ? __enable_irq() : 0, __cond = 0 )

Damit man es nachvollziehen kann:

#include <stdio.h>

int Funktion1(void)
{
  printf("Funktion1\n");
  return 0;
}

void Funktion2(void)
{
  printf("Funktion2\n");
}

void Funktion3(void)
{
  printf("Funktion3\n");
}

void Funktion4(void)
{
  printf("Funktion4\n");
}

int main()
{
  for( int __cond = 1, __prim = Funktion1(); __cond != 0 ? Funktion2() : 0, __cond != 0; __prim == 0 ? Funktion4() : 0, __cond = 0 ) {
    Funktion3();
  }
  return 0;
}

[Marc (Gast)]

Das ist zwar ein alter Thread  aber das Update lässt mir keine Wahl:
Ihr baut die tollsten Konstrukte aber das ganze Konzept hat einen 
eklatanten systematischen Fehler:
Man darf auf keinen Fall am Ende eines atomaren Blocks den Interrupt 
unkontrolliert wieder aktivieren! Sonst passiert es, dass in einem 
Programmteil, in dem der Interrupt explizit ausgeschaltet sein muss, 
durch Aufruf einer Funktion mit dem Konstrukt ungewollte Interrupts 
aktiviert werden!

Die korrekte Vorgehensweise ist:

1. Zustand der Interrupts in einer Variablen sichern
2. Interrupt deaktivieren (einen oder alle…)
3. Atomarer Block…
4. Ursprünglichen Zustand der Interrupts wieder herstellen!

Man kann ja noch argumentieren, dass man als einsamer Entwickler weiß, 
wann die Interrupts an oder aus sind. Aber bei einem System mit vielen 
Entwicklern und Betriebszuständen (Bootloader, Calibrationmode, 
Errormode usw…) überblickt keiner mehr, wann wo Interrupts an/aus sind 
und dass dann bestimmte Funktionen (oder Unterfunktionen von 
Unterfunktionen….) nicht genutzt werden dürfen, da sie von sich aus 
Interrupts aktivieren…

Für IAR gibt es die folgende Intrinsic Funktionen auch für ARM
1. __istate_t  interruptstate = __get_interrupt_state();
2.    __disable_interrupt();
3.  // Atomarer Block…
4.  __set_interrupt_state(interruptstate);


Im Definitive Guide to ARM® Cortex®-M3 and Cortex®-M4 Processors 
empfehlen sie die Verwendung von __get_PRIMASK() und __set_PRIMASK().
Eine Info dazu findet sich in
https://devzone.nordicsemi.com/question/47493/disable-interrupts-and-enable-interrupts-if-they-where-enabled/

Was mich wundert: ist von Euch noch niemand über dieses Problem 
gestolpert?
Ich hatte diesen Fehler schon mehrfach entdeckt und halte ihn für sehr 
gefährlich.

[Falk B. (falk)]

@  Marc (Gast)

>Man darf auf keinen Fall am Ende eines atomaren Blocks den Interrupt
>unkontrolliert wieder aktivieren!

Doch, wenn man sicher ist, daß er vorher aktiv war ;-)

Die atomic.h des avr gcc bietet dafür 2 Möglichkeiten

22.26.2.2 #define ATOMIC_FORCEON
This is a possible parameter for ATOMIC_BLOCK. When used, it will cause the
ATOMIC_BLOCK to force the state of the SREG register on exit, enabling the Global
Interrupt Status flag bit. This saves on flash space as the previous value of the SREG
register does not need to be saved at the start of the block.
Care should be taken that ATOMIC_FORCEON is only used when it is known that
interrupts are enabled before the block’s execution or when the side effects of enabling
global interrupts at the block’s completion are known and understood.
22.26.2.3 #define ATOMIC_RESTORESTATE
This is a possible parameter for ATOMIC_BLOCK. When used, it will cause the
ATOMIC_BLOCK to restore the previous state of the SREG register, saved before
the Global Interrupt Status flag bit was disabled. The net effect of this is to make
Generated on Wed Jan 6 12:08:48 2010 for avr-libc by Doxygen
22.27 <util/crc16.h>: CRC Computations 292
the ATOMIC_BLOCK’s contents guaranteed atomic, without changing the state of the
Global Interrupt Status flag when execution of the block completes.

[Dr. Sommer (Gast)]

Marc schrieb:
> Was mich wundert: ist von Euch noch niemand über dieses Problem
> gestolpert?
Doch, seit 2013 schon... Man könnte es so machen:

class IRQLocker {
  private:
    uint32_t m;
  public:
    inline IRQLocker () { m = __get_PRIMASK (); __disable_irq (); }
    inline ~IRQLocker () { if (m == 0) __enable_irq (); }
};

template <typename F>
inline void doAtomic (F f) {
  IRQLocker l;
  f ();
}

void test1 () {
  doAtomic ([] () {
    /* tu was atomisches */
  });
}

void test2 () {
  {
    IRQLocker l;
    /* tu was atomisches */
  } // bei der Schließenden Klammer erfolgt das entsperren
}

Diese Variante mit extra Klasse hat den Vorteil, dass das entsperren 
auch funktioniert wenn man Exceptions verwendet (RAII-Style). Das Lambda 
braucht man dann nicht mehr unbedingt, wie in test2 zu sehen ist.

[Marc (Gast)]

Falk B. schrieb:
> @  Marc (Gast)
> Doch, wenn man sicher ist, daß er vorher aktiv war ;-)
Siehe meinen 3. Absatz...

> Die atomic.h des avr gcc bietet dafür 2 Möglichkeiten
Wir sind hier im Thread: atomic-lib für ***stm32***

Gruß
Marc

[Marc (Gast)]

Dr. Sommer schrieb:
> Marc schrieb:
>> Was mich wundert: ist von Euch noch niemand über dieses Problem
>> gestolpert?
> Doch, seit 2013 schon... Man könnte es so machen:
> class IRQLocker {
}

Jetzt bin ich beruhigt, dass ich nicht der Einzige bin.

Und eines muss ich Ihnen Herr Dr. Sommer jetzt offenbaren:

    Herr Dr. Sommer:
    ich liebe Sie für ihre guten
    Tipps & Informationen zu C++
    auf embedded systemen.


Nachtrag: zum Thema allgemein gab es schon einen Thread mit C 
Beispielcode:
Beitrag "Interrupts ein-/ausschalten beim ARM cortex-M3"

[Philipp S. (schroedi)]

Marc schrieb:
> Ihr baut die tollsten Konstrukte aber das ganze Konzept hat einen
> eklatanten systematischen Fehler:
> Man darf auf keinen Fall am Ende eines atomaren Blocks den Interrupt
> unkontrolliert wieder aktivieren!

Doch, wird berücksichtigt.

... __prim = __get_PRIMASK() ...

[Jan K. (jan_k)]

A. K. hat es oben zwar schon erwähnt, aber ich finde die Idee wichtig 
und schreibe es deswegen nochmal:

Es müssen nicht zwingend die Interrupts (partiell) ein-/ausgeschaltet 
werden! LDREX und das Pendant STREX gibt es als intrinsics (__LDREX bzw 
__ldrex), womit man super toll selbst atomare Funktionen bauen kann.

Oft läuft die kritische Sektion doch nur auf das Verändern von 1, 2 
Variablen (Zähler, Indizes, etc) Variablen hinaus, da kann man sich 
genau so gut so etwas in die Richtung schreiben (ungetestet, ob das mit 
dem void Zeiger so legitim ist müsste ich nachgucken)

int ATOMIC_IncrementVar(void * var)
{
  int32_t count;
  int32_t status;
  do
  {
    count = (int32_t) __ldrex(  (uint32_t *)(var) ); // load variable address exclusively
    status = __strex( ++count, (uint32_t *)(var) ); // status != 0, if no exclusive access was guaranteed
  }
  while ( status != 0 ); // 0 = success
  __dmb( 10 );        // recommended by arm -> make sure every memory access is done
  return ATOMIC_SUCCESS;
}

Der Vorteil ist, dass man im Fehlerfall auch returnen könnte, dann weiß 
man halt, dass die Variable nicht gesetzt wurde oder wie oben 
blockieren, bis es funktioniert.

Klar, für den Zugriff auf exklusive Ressourcen muss man anders vorgehen, 
aber da hilft auch ein atomic block von oben nicht (man könnte aber 
ATOMIC_IncrementVar nehmen, um einen Mutex/Semaphore zu bauen).

[W.S. (Gast)]

Marc schrieb:
> Was mich wundert: ist von Euch noch niemand über dieses Problem
> gestolpert?

Ähemm..nö.

Bei mir läuft der normale Kram, also main und alles, was darin 
aufgerufen wird, im Usermodus mit grundsätzlich allen Interrupts offen 
und erlaubt. Und mir ist es noch nie untergekommen, daß ich mal das 
Bedürfnis hatte, die Interrupts zeitweise abzuschalten. Eher denke ich 
an andere Synchronisier-Mechanismen als an exclusiven Zugriff zweier 
oder mehrerer Programmteile auf die selbe Ressource.

Wenn man schon irgendwas exclusiv machen will, dann eher mit nem SVC. 
Dessen Inhalt läuft dann im Supervisor-Modus und den kann man von 
vornherein so hoch ansetzen, daß er ungestört läuft. Ist beim Keil recht 
easy zu machen, aber beim GCC braucht es wieder mal nen 
Assembler-Wrapper dafür.

W.S.

[Marc (Gast)]

Jan K. schrieb:
> Es müssen nicht zwingend die Interrupts (partiell) ein-/ausgeschaltet
> werden! LDREX und das Pendant STREX gibt es als intrinsics (__LDREX bzw
> __ldrex), womit man super toll selbst atomare Funktionen bauen kann.

> ATOMIC_IncrementVar(void * var)


Du hast recht, man sollte vor dem Design erst mal alle 
Lösungsmöglichkeiten abwägen.  Ich setze auch LDREX / STREX ein, je nach 
Problemstellung.

Die Idee deiner Funktion ist gut, ich bin allerdings kein Freund von 
Parameterübergabe mittels void*
Der Compiler wirft keine Warnungen und mein schlampiger Kollege (oder 
ich nach einer langen Nacht…) bauen einen Aufruf mit einem 8 oder 16 Bit 
Parameter…

Und das Unheil nimmt seinen Lauf…

[Jan K. (jan_k)]

Marc schrieb:
> Die Idee deiner Funktion ist gut, ich bin allerdings kein Freund von
> Parameterübergabe mittels void*
> Der Compiler wirft keine Warnungen und mein schlampiger Kollege (oder
> ich nach einer langen Nacht…) bauen einen Aufruf mit einem 8 oder 16 Bit
> Parameter…
>
> Und das Unheil nimmt seinen Lauf…

Stimmt stimmt, wollte das zuerst generisch aufziehen. Vielleicht sollte 
man das ganze noch kapseln oder halt für jeden Datentyp eine Funktion 
erstellen. Und dann den void Pointer natürlich weg machen ;-)

[Marc (Gast)]

Vermutlich wäre eine Lösung für jeden Datentyp am sichersten.
(Noch schöner in C++ mit Templates...)

Und statt einem counter++ einen zusätzlichen Parameter, dann kann man 
fexibel addieren/subtrahieren. Beispielsweise so (habe die 
Variablennamen noch etwas angepasst):

bool ATOMIC_int32Add(int32_t *var, int32_t off)
{
  int32_t tempVal;
  int32_t lockedOut;
  do
  {
    tempVal = (int32_t) __LDREX((unsigned long *)var); 
    tempVal += off;
    lockedOut = __STREX(tempVal,(unsigned long *)var); 
  }
  while ( lockedOut ); // lockedOut: 0==Success, 1==instruction is locked out
  __DMB(10);  // recommended by arm -> make sure every memory access is done
  return true;
}

Den Rückgabewert könnte man noch verwerfen... Die Frage ist, ob man noch 
ein Abbruchkriterium einbaut wenn die Schleife X mal durchlaufen wurde.


Dazu eine Frage an die Leute, die dieses Verfahren schon mehrfach 
genutzt haben:

In welchen Fällen kam es zu Problemen (z.B. durch DMA Zugriffe in den 
Speicher), die dazu führten, dass __STREX immer ein "locked out" 
meldete?

Da ist ein  __disable_interrupt().... deterministischer. Was ist eure 
Erfahrung?

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

Und wenn ldrex/strex nicht weiterhelfen, dann kann man bei den Cortex M 
dennoch um die Abschaltung aller Interrupts herum kommen, indem man die 
Priorität nur so weit verändert, dass nur die relevanten Interrupts 
gesperrt werden. Dank des recht exakt dafür implementierten Registers 
BASEPRI_MAX geht das ausgesprochen einfach.

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

Marc schrieb:
> Da ist ein  __disable_interrupt().... deterministischer.

Sehr deterministisch und im Fall von DMA auch sehr sinnlos. Gegen DMA 
hilft die Abschaltung von Interrupts überhaupt nicht. Bei mehreren Cores 
sieht es ähnlich aus.

Wenn man die Sorge hat, in diese Falle laufen zu können, dann kann man 
solche Spinlocks auch ent-determinisieren, indem das Verhalten (Timing) 
abhängig von einem Durchlaufzähler variiert.

[Marc (Gast)]

A. K. schrieb:
>> Da ist ein  __disable_interrupt().... deterministischer.
> Sehr deterministisch und im Fall von DMA auch sehr sinnlos.

Ich denke dass ein Disabling .... Enabling deterministischer sein könnte 
als eine Schleife (ich sage nicht, dass es immer so ist...)

Szenario:
An verschiedenen Stellen im Code (auch in Interrupts) müssen mehrere 
Variablen modifiziert werden.  Beim Disabling kann ich genau bestimmen 
wie lange die Interrupts maximal gesperrt sind.
Bei LDREX / STREX geht das nur mit einer zusätzlichen Abbruchbedingung. 
Aber die Ausführungszeit schwankt eben (1 ... n Schleifendurchläufe) und 
ich muss danach prüfen ob es zum Abbruch kam

Vermutlich bin ich zu pessimistisch, bisher hatte ich keinen kritischen 
Spinlock.Daher eben meine Frage oben.

Anders formuliert: hatte jemand bei LDRES / STRED größere Probleme und 
was war die Ursache?

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

Marc schrieb:
> Ich denke dass ein Disabling .... Enabling deterministischer sein könnte
> als eine Schleife (ich sage nicht, dass es immer so ist...)

Interrupts abzuschalten macht das Zeitverhalten in dieser Phase 
deterministisch. Andererseits vergrössert sich der variable Anteil der 
Latenz von Interrupts, die Latenz wird also weniger deterministisch. 
Letztlich eine Abwägung, wo man den Schwerpunkt setzt.

Bei Forderung von taktgenauem Zeitverhalten im Hauptprogramm bei darin 
enthaltenen Zugriffen auf solche Variablen ist die Abschaltung natürlich 
obligatorisch. Das ist aber ein eher ungewöhnliches Szenario, zumal in 
komplexen Controller-Anwendungen mit etlichen Interrupts und ggf. DMA.

> An verschiedenen Stellen im Code (auch in Interrupts) müssen mehrere
> Variablen modifiziert werden.

So lange alle zu einer Variablen gehörenden ISRs die gleiche preemption 
priority haben, ist in ISRs kein ldrex/strex-Verfahren erforderlich. 
Diese Interrupts sind davon also nicht betroffen.

NB: Wer sich bei dem Cortex M fragt, wieso die Priorisierung des NVIC 
nicht durchweg preemptive ist, der hat hier eine Antwort.

> Bei LDREX / STREX geht das nur mit einer zusätzlichen Abbruchbedingung.
> Aber die Ausführungszeit schwankt eben (1 ... n Schleifendurchläufe) und
> ich muss danach prüfen ob es zum Abbruch kam

Kannst du ein im relevanten Rahmen zeitkritisches Szenario entwerfen, in 
dem ein solches pro Durchlauf nur wenige Takte dauernde Spinlock mehr 
als einige wenige Versuche benötigt, am Ende gar in ein Deadlock 
reinlaufen kann?

Ich kann mir dafür nur Szenarien vorstellen, in denen das Programm fast 
die gesamte Zeit in Interrupts verbringt.

[Marc (Gast)]

Danke A. K. für deine Infos.

>Ich kann mir dafür nur Szenarien vorstellen, in denen das Programm fast
die gesamte Zeit in Interrupts verbringt.

Meine Bedenken gingen eher Richtung DMA.
Szenario: Ein Stück Code wird in einem hoch priorisierten Interrupt 
ausgeführt. Die ISR soll möglichst kurz sein (eben um die Latenz für 
andere ISRs... nicht unnötig zu erhöhen). Parallel läuft aber ein DMA 
Schreibzyklus, der dazu führt, dass LDREX/STREX x Schleifen durchläuft.

Mmmm, ich glaube ich versuche mich mal an Testcode. Kann für's 
Verständnis nie schaden...

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

Marc schrieb:
> Parallel läuft aber ein DMA
> Schreibzyklus, der dazu führt, dass LDREX/STREX x Schleifen durchläuft.

Die ARMv7-M Referenz erweckt nicht den Eindruck, dass diese Befehle 
geeignet sind, sich gegen Zugriffe eines einfachen DMA Controllers für 
Peripherie-Transfers auf die gleiche Adresse abzusichern.

Ich gehe davon aus, dass solche DMA Zugriffe auf ausreichend 
verschiedene Adressen dem entsprechenden Monitor nicht ins Gehege 
kommen. Andernfalls wäre intensives DMA mit LDREX/STREX prinzipiell 
unverträglich.

Anders sieht es bei konkurrierenden Zugriffen mehrerer Cores aus. Da 
allerdings kommt man mit der Abschaltung von Interrupts nicht weiter und 
muss mit solchen Verfahren arbeiten. Da wird es dann auch etwas 
komplizierter.

[Jan K. (jan_k)]

Es gibt hier z.B. einige Infos zu den Exclusiven Monitoren: 
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dht0008a/CJAGCFAF.html

Und da steht konkret, wie er im M3 und M4 implementiert ist: 
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka16180.html

Und das ist hier das Manual zu der ARMv7-M Architektur, alles ab A3.4 
wird interessant. 
https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwiKwrae_6fMAhVUGsAKHZpUAGkQFgggMAA&url=https%3A%2F%2Fweb.eecs.umich.edu%2F~prabal%2Fteaching%2Feecs373-f10%2Freadings%2FARMv7-M_ARM.pdf&usg=AFQjCNHNAdnUhWjznYcJGCLNNdzgMGQmgw&sig2=bu77UAoozA51G2cblKD8Bg

Guckt man sich das state machine diagram in figure A3-2 an, steht da nur 
was von Store und StoreExcl instructions, werden diese vom DMA benutzt? 
Wenn nein, sollte der DMA kein Problem machen.

Edit: Oder meinst du echt einen Zugriff auf gleiche Adressen? Ich dachte 
eher du meintest eine Endlosschleife, die auf Grund von false negatives 
des LDREX Befehls entstehen.

Noch ein edit: der Cortex M3 scheint nicht einzelne Speicherbereiche zu 
taggen, sondern guckt nur, ob einfach, ob der monitor im exclusive 
Zustand ist und verweigert ggf das exklusive Schreiben

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

Jan K. schrieb:
> Noch ein edit: der Cortex M3 scheint nicht einzelne Speicherbereiche zu
> taggen, sondern guckt nur, ob einfach, ob der monitor im exclusive
> Zustand ist und verweigert ggf das exklusive Schreiben

Zumindest ist das entsprechend der Fussnote in ARMv7-M zulässig: "The 
IMPLEMENTATION DEFINED options for the local monitor are consistent with 
the local monitor being constructed so that it does not hold any 
physical address, but instead treats any access as matching the address 
of the previous LDREX. In such an implementation, the Exclusives 
reservation granule defined in Tagging and the size of the tagged memory 
block on page A3-75 is the entire memory address range."

Über das konkrete Verhalten vom CM3 Core finde ich grad keine Details. 
Beim CM4 und CM7 steht das aber ausdrücklich so drin, also wird es beim 
CM3 wohl auch so sein.

In diesem Fall hätte man dann aber doch ein DMA Problem, sofern der DMA 
Controller in diesem Sinn als "observer" gilt und beim DMA Zugriff 
folglich unabhängig von der Adresse dies zutrifft: "It is UNPREDICTABLE 
whether a store to a tagged physical address causes a tag in the local 
monitor to be cleared if that store is by an observer other than the one 
that caused the physical address to be tagged."

Bei dieser Kaffeesatzleserei bleibt mir vorerst die Erkenntnis, dass 
sich daraus keine zweifelsfreie Aussage über DMA ablesen lässt. Und 
eigentlich nur die heuristische Logik verbleibt, dass ein DMA Controller 
als "observer" arg wenig Sinn ergibt.

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

Ok, hier wird es klarer:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka16180.html

"For a design containing a single processor and some other agent such as 
a DMA controller, it is acceptable to tie EXRESPx = 0 if software which 
makes use of semaphore operations can ensure that the other agent is not 
accessing that address range while the semaphore operation is in 
progress."

M.a.W: Bei Controllern mit einheitlich von DMA ansprechbarem RAM wird 
der Zustand des Monitors von DMA wie erwartet nicht beeinflusst.

Bei Controllern mit verschiedenen nur teilweise von DMA ansprechbaren 
RAM-Blöcken oder -Adressräumen könnte angebracht sein, diese Variablen 
im non-DMA-RAM zu platzieren. Für den Fall, dass der Controller sich 
unwahrscheinlicherweise die Mühe macht, die Adressräume beim STREX 
auseinander zu halten. Da müsste man sonst bei ST&Co nachschlagen.

[Jan K. (jan_k)]

Noch eine andere Sache:
In 
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0375g/chr1359124997286.html 
steht, dass es sein kann, dass der Compiler store Befehle zwischen 
ldrex/strex packen kann. Das wäre eine blöde Sache, weil das exklusive 
Schreiben dann nie funktionieren würde. Ich vermute, dass die 
Quintessenz daraus ist, die Funktion vermutlich doch wieder als 
Assembler umzusetzen...

Darüberhinaus ist der intrinsic Befehl als deprecated markiert, weiß da 
jmd was drüber?

Die Passage tritt erst bei armcc v5.06 auf, vorher nicht:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0376d/CJAECCJJ.html 
(v5.05)

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

Jan K. schrieb:
> steht, dass es sein kann, dass der Compiler store Befehle zwischen
> ldrex/strex packen kann.

Normale Store-Befehle auf andere Variablen sind im hier betrachteten 
Rahmen (single core, local monitor) sicherlich kein Problem. Der Monitor 
wird die ebenso wenig mitkriegen wie die DMA Zugriffe.

[Jan K. (jan_k)]

Ich hab das so verstanden, dass jeder store Befehl den monitor 
resetten KANN und dieser eben nicht nur auf eine Adresse guckt:
"The local monitor's Exclusives Reservation Granule is 4GB, meaning that 
no address information is stored in the local monitor."

Somit würde selbst bei einem store auf eine andere Speicheradresse nie 
ein erfolgreiches exklusives Schreiben resultieren.

"When a processor writes using any instruction other than a 
Store-Exclusive:
• if the write is to a physical address that is not covered by its local 
monitor the write does not affect
the state of the local monitor
• if the write is to a physical address that is covered by its local 
monitor it is IMPLEMENTATION DEFINED
whether the write affects the state of the local monitor.
If the local monitor is in its Exclusive Access state and a processor 
performs a Store-Exclusive to any
address other than the last one from which it has performed a 
Load-Exclusive, it is IMPLEMENTATION
DEFINED whether the store succeeds, but in all cases the local monitor 
is reset to its Open Access state. In
ARMv7-M, the store must be treated as a software programming error.
"

Und "The compiler does not guarantee that it will preserve the state of 
the exclusive monitor. It may generate load and store instructions 
between the LDREX instruction generated for the __ldrex intrinsic and 
the STREX instruction generated for the __strex intrinsic. Because 
memory accesses can clear the exclusive monitor, code using the __ldrex 
and __strex intrinsics can have unexpected behavior. Where LDREX and 
STREX instructions are needed, ARM recommends using embedded assembly."

Bin ich schief gewickelt? =)

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

Jan K. schrieb:
> Ich hab das so verstanden, dass jeder store Befehl den monitor
> resetten KANN und dieser eben nicht nur auf eine Adresse guckt:

Ist implementation defined. Da das hier aber ausdrücklich als absolute 
Minimalimplementierung ausgeführt ist, um LDREX/STREX in dieser Rolle 
überhaupt nutzen zu können, wird es darauf hinauslaufen, dass der 
Monitor von anderen Stores als STREX überhaupt nichts mitbekommt. Die 
Alternative wäre aufwendiger und hätte keinerlei Mehrwert.

[M. K. (kichi)]

Leo B. schrieb:
> wollte mal fragen, ob jemand eine atomic-lib, wie es sie für den AVR-GCC
> gibt
> (http://www.nongnu.org/avr-libc/user-manual/group__util__atomic.html),
> auch für die STM32 kennt.

Philipp S. schrieb:
> #define ATOMIC_BLOCK for( uint32_t __cond = 1, __prim = __get_PRIMASK();
> __cond != 0 ? __disable_irq() : 0, __cond != 0; __prim == 0 ?
> __enable_irq() : 0, __cond = 0 )

Der Vollständigkeit halber:

#define ATOMIC_BLOCK(type) for( uint32_t __cond = 1, __prim = __get_PRIMASK(); \
                                __cond != 0 ? __disable_irq() : 0, __cond != 0; \
                                (type & __prim) == 0 ? __enable_irq() : 0, __cond = 0 )
#define ATOMIC_FORCEON          0
#define ATOMIC_RESTORESTATE     1

sollte sich Verhalten wie das AVR-Pendant.

Alternativ hat sich schonmal jemand die Mühe gemacht die ganze atomic.h 
zu portieren:
https://github.com/PaulStoffregen/cores/blob/master/teensy3/util/atomic.h

[M. K. (kichi)]

#define ATOMIC_BLOCK(type) for( uint32_t __cond = 1, __prim = __get_PRIMASK(); \
                                __cond != 0 ? __disable_irq() : 0, __cond != 0; \
                                (type && __prim) == 0 ? __enable_irq() : 0, __cond = 0 )
#define ATOMIC_FORCEON          0
#define ATOMIC_RESTORESTATE     1

bietet dem Compiler noch die Möglichkeit zu optimieren.
Man beachte "(type && __prim)" statt "(type & __prim)".

[Adib (Gast)]

Hallo Leute,

das sieht allles richtig gut aus.

Wie muss man das schreiben, um die BASEPRIO temporär zu setzen?

Danke und Grüße, Adib.

[M. K. (kichi)]

Adib schrieb:
> Wie muss man das schreiben, um die BASEPRIO temporär zu setzen?

Falls du das im Zusammenhang mit den ATOMIC_BLOCKs meinst, versuch mal

#define ATOMIC_BLOCK(prio) for( uint32_t __cond = 1, __prim = __get_BASEPRI(); \
                                __cond != 0 ? __set_BASEPRI(prio) : 0, __cond != 0; \
                                __set_BASEPRI(__prim), __cond = 0 )

das sollte sich den alten Werk merken, einen neuen setzen (den du mit 
"prio" übergeben musst) und anschließend den alten wiederherstellen. 
Getestet habe ich es ehrlich gesagt nicht, müsste aber funktionieren.

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

Wenn man anfangs BASEPRI_MAX statt BASEPRI setzt, dann vermeidet man das 
Risiko, die Prio versehentlich zu reduzieren. Das könnte sonst 
passieren, wenn man diesen Code in ISRs oder verschachtelt verwendet.

#define ATOMIC_BLOCK(prio) for( uint32_t __cond = 1, __prio = __get_BASEPRI(); \
                                __cond != 0 ? __set_BASEPRI_MAX(prio) : 0, __cond != 0; \
                                __set_BASEPRI(__prio), __cond = 0 )

[Adib (Gast)]

Hallo Leute,

mein Keil Compiler kommt offensichtlich nicht mit dem Konstrukt hier 
klar:

__cond != 0 ? __set_BASEPRI_MAX(prio) : 0

Es gibt eine komische Fehlermeldung:

TOMIC ....

Also das "A" wird vom "TOMIC" getrennt ???
Es hat wohl was mit der Anweisung ohne return __set_BASEPRI_MAX zu tun.

Danke und Grüße, Adib.
--

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

Yep, dieser Ausdruck ist kein korrektes C, weil links vom : vom Typ 
void. Probier mal:
  __cond != 0 ? (__set_BASEPRI_MAX(prio), 0) : 0

[Adib (Gast)]

Danke, funzt. Adib.

[M. K. (kichi)]

Ich habe das mal wiederverwertbar in einer Header-Datei zusammengefasst,
vielleicht kann es ja jemand brauchen.

[Johann L. (gjlayde)]

Leo B. schrieb:
> Hey Leute,
>
> wollte mal fragen, ob jemand eine atomic-lib, wie es sie für den AVR-GCC
> gibt
> (http://www.nongnu.org/avr-libc/user-manual/group__util__atomic.html),
> auch für die STM32 kennt. Compiler soll auch hier der GCC sein falls das
> wichtig ist.
>
> Ich konnte leider nichts passendes im Internet finden,

Na du HAST doch bereits was gefunden, nämlich util/atomic.h der 
AVR-LibC:  Es ist nämlich lediglich ein Header und KEINE Bibliothek.

http://svn.savannah.nongnu.org/viewvc/trunk/avr-libc/include/util/atomic.h?root=avr-libc&view=markup

Der Header ist dann für deine Maschine anzupassen, insbesondere die 
weiter unten im Headetr verwendeten

/* Internal helper functions. */
static __inline__ uint8_t __iSeiRetVal(void)
{
    sei();
    return 1;
}

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

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

static __inline__ void __iCliParam(const uint8_t *__s)
{
    cli();
    __asm__ volatile ("" ::: "memory");
    (void)__s;
}

static __inline__ void __iRestore(const  uint8_t *__s)
{
    SREG = *__s;
    __asm__ volatile ("" ::: "memory");
}

Was du anpassen musst:

sei(): IRQs global zulassen (I-Flag := 1)

cli(): IRQs global deaktivieren (I-Flag := 0)

SREG: Bei AVR ein 8-Bit SFR, über welches das I-Flag gelesen und
      geschrieben werden kann; bei STM geht das wohl über Support
      Funktionen wie __set_BASEPRI und __get_BASEPRI

uint8_t: Bei STM vermutlich ein 32-Bit Wert, also der Return-Typ von
      __get_BASEPRI

#include <avr/interrupt.h>: Wird nicht mehr gebraucht.
#include <avr/io.h>: dito

#include <stdint.h>: Neues Include falls uint32_t o.ä. verwendet werden
         sollen.

Und last not least Copyright beachten, d.h. das entsprechende Intro 
kopieren, und wenn du willst dich unter Dean Camera verewigen :-)

[technikus (Gast)]

Michael K. schrieb:
> Ich habe das mal wiederverwertbar in einer Header-Datei
> zusammengefasst,
> vielleicht kann es ja jemand brauchen.

Mein Compiler motzt hier:

#define ATOMIC_BLOCK(type) for( uint32_t __cond = 1, __prim = __get_PRIMASK(); \
                                __cond != 0 ? __disable_irq() : 0, __cond != 0; \
                                (type && __prim) == 0 ? __enable_irq() : 0, __cond = 0 )

Schweregrad  Code  Beschreibung  Projekt  Datei  Zeile 
Unterdrückungszustand
Fehler    second operand to the conditional operator is of type 'void', 
but the third operand is neither a throw-expression nor of type 'void' 
Debounce  C:\Users\daniel\Desktop\Debounce\Debounce\Debounce\cm_atomic.h 
80

Er schein __disable_irq() und __enable_irq() nicht zu kennen.

Könnt ihr mir weiter helfen?

[eagle user (Gast)]

Nett :) Wenn der Compiler __disable_irq() nicht kennen würde, gäbe es 
den Fehler nicht! Unbekannte Funktionen liefern int und nicht void. A.K. 
hat das Problem schon ca. 5 Beiträge weiter oben erklärt:
Beitrag "Re: atomic-lib für stm32"

[M. K. (kichi)]

technikus schrieb:
> Könnt ihr mir weiter helfen?

eagle user schrieb:
> A.K. hat das Problem schon ca. 5 Beiträge weiter oben erklärt:
> Beitrag "Re: atomic-lib für stm32"

Stimmt, da fehlt was. Mach mal

#define ATOMIC_BLOCK(type) for( uint32_t __cond = 1, __prim = __get_PRIMASK(); \
                                __cond != 0 ? (__disable_irq(), 0) : 0, __cond != 0; \
                                (type && __prim) == 0 ? __enable_irq() : 0, __cond = 0 )

draus. Habe grad keinen Compiler zur Hand, ist also ungetestet. 
Vermutlich braucht es das bei __enable_irq() dann auch noch, also:

(__enable_irq(), 0)

[technikus (Gast)]

Passt so.
Danke