Atomisches "__enable_irq () + WFI" / condition variablen für ARM

[Niklas G. (erlkoenig)]

Moin,

wie kann man beim Cortex-M3/4 (STM32) in einem Schritt die Interrupts 
aktivieren und den Sleep-Modus (WFI) betreten, ohne dass Interrupts 
dazwischen funken?

Das ist relevant bei solchen Konstrukten, wenn man den Sleep-Mode zur 
Reduktion der Leistungsaufnahme einsetzen möchte:

volatile int counter = 0;

void TIM2_IRQHandler (void) {
  ++counter;
}

int main () {
  HAL_TIM_Base_Start_IT(&htim2);
  ...
  while (1) {
    __disable_irq ();
    int c = counter;
    counter = 0;
    if (c == 0) {
      __enable_irq ();
      // Race Condition hier!!
      __WFI ();
    } else
      __enable_irq ();
    
    if (c != 0) {
      doSomething (c);
    }
  }
}

Der Interrupt signalisiert über die Variable, dass etwas zu tun ist. Die 
Funktion doSomething kann nicht direkt im Interrupt ausgeführt werden, 
weil sie langsam ist, Delays nutzt, Teil einer proprietären Bibliothek 
ist welche nicht geändert werden kann o.ä. Die Interruptsperre ist aber 
nötig um counter konsistent modifizieren zu können.

Die Tücke ist: Wenn genau zwischen dem __enable_irq() und dem WFI der 
Interrupt kommt und den counter inkrementiert, betritt der Controller 
trotzdem den Sleep-Modus und wacht ggf. nie wieder/zu spät wieder auf.

Man muss irgendwie sicherstellen dass zwischen Abfragen des counters und 
Betreten des Sleep-Mode kein Interrupt auftreten kann - oder die ISR 
muss irgendwie das Betreten des Sleepmode verhindern. Ersetzt man die 
Interrupt-Sperre durch Atomics, hat man übrigens das gleiche Problem, 
aber eben zwischen Abfrage des Atomic-Werts und WFI.

Gibt es dafür eine smarte Lösung?

Eine Möglichkeit wäre es WFE statt WFI zu nutzen und SEV im 
Interrupt-Handler bzw. SEVONPEND. Aber eigentlich ist dieser Mechanismus 
für Inter-Core-Kommunikation intendiert, in Multicore-Systemen würde man 
damit unnötig andere Kerne wecken.

Das Problem tritt sehr ähnlich auf wenn man Task-Queues für "normale" 
Multithreading-Systeme implementieren möchte, dort können Condition 
Variables helfen. So etwas bräuchte man hier auch, aber eben ohne 
Multithreading.

Mir ist eine relativ komplizierte Lösung mit SVC und SLEEPONEXIT 
eingefallen. Kennt jemand eine elegante kompakte Lösung? Wie macht man 
das bei Controllern welche kein WFE+SEV oder SLEEPONEXIT haben, wie z.B. 
AVR?

[Peter D. (peda)]

Niklas G. schrieb:
> Wie macht man
> das bei Controllern welche kein WFE+SEV oder SLEEPONEXIT haben, wie z.B.
> AVR?

Beim AVR ist das elegant gelöst:
The instruction following SEI will be executed before any pending 
interrupts
D.h. der folgende Befehl kann noch nicht durch einen Interrupt 
unterbrochen werden. Die Sequenz SEI+Befehl ist also immer atomar und 
damit auch SEI+SLEEP.
Interessant wäre, ob das auch ohne vorheriges CLI funktioniert.

[Foobar (asdfasd)]

peda schrieb:
> Beim AVR ist das elegant gelöst
> The instruction following SEI will be executed before any pending
> interrupts

Dummerweise im clib falsch umgesetzt.  "sei(); sleep_cpu();" soll das 
erledigen.  Allerdings sind das zwei getrennte asm-statements und der 
Compiler darf dazwischenpfuschen.  Habe erlebt, dass das sleep_cpu durch 
CSE verschoben wurde - im Assemblercode stand dann ein 
"sei+jmp_to_sleep" :-(

[Tassilo B. (big_t)]

Niklas G. schrieb:

> if (c == 0) {
>       __enable_irq ();
>       // Race Condition hier!!
>       __WFI ();
>    } else
>
>     __enable_irq ();

Ändere das zu

if (c == 0) {
  __WFI ();
}
__enable_irq ();

und fertig. Das WFI kommt sofort wieder wenn ein aktivierter Interrupt 
'pending' ist, unabhängig davon, wie das globale INTs-enable gerade 
steht. Siehe auch
https://community.arm.com/support-forums/f/architectures-and-processors-forum/4039/wfe-wfi-and-pending-interrupts

und
https://developer.arm.com/documentation/dui0552/a/the-cortex-m3-instruction-set/miscellaneous-instructions/wfi?lang=en

oder
https://www.embedded.com/use-an-mcus-low-power-modes-in-foreground-background-systems/

[Niklas G. (erlkoenig)]

Tassilo B. schrieb:
> Das WFI kommt sofort wieder wenn ein aktivierter Interrupt
> 'pending' ist, unabhängig davon, wie das globale INTs-enable gerade
> steht.

Ahhh stimmt, der interessante Satz ist:

> WFI is a hint instruction that suspends execution until one of the following 
events occurs: [...]
> an interrupt masked by PRIMASK becomes pending

Damit ist es tatsächlich ganz einfach. Man sollte wohl nur direkt nach 
dem WFI die Interrupts wieder aktivieren damit diese schnell 
abgearbeitet werden.

Klasse, danke!

[Niklas G. (erlkoenig)]

Weil ich da mal wieder drüber gestolpert bin habe ich mir ein Makro 
dafür gebastelt:

#define SLEEP_WAIT_COND(cond) do { \
  uint32_t sleepWaitCond_primaskState = __get_PRIMASK (); \
  __disable_irq (); \
  while (cond) { \
    __WFI (); \
    __enable_irq (); \
    __NOP (); \
    __disable_irq (); \
  } \
  if (sleepWaitCond_primaskState == 0) {\
    __enable_irq (); \
  } \
} while (0)

Dieses Makro aufzurufen wartet darauf, dass die angegebene Bedingung 
false wird. Funktional identisch zu

uint32_t sleepWaitCond_primaskState = __get_PRIMASK ();
while (cond);
if (sleepWaitCond_primaskState == 0) __enable_irq ();

Aber eben energieeffizienter weil der Sleep-Modus benutzt wird. Die 
Bedingung muss natürlich in einer ISR auf false gesetzt werden, und 
dafür werden natürlich zwischenzeitlich die Interrupts aktiviert. Der 
vorherige Interrupt-Zustand wird am Ende wiederhergestellt.

z.B. bei einem STM32Cube-Projekt kann man das in der syscalls.c so 
nutzen:

static int stdoutstate = 0;
__attribute__((weak)) int _write(int file, char *ptr, int len)
{
  (void)file;

  stdoutstate = 1;
  HAL_UART_Transmit_DMA (&huart2, (uint8_t*) ptr, len);

  SLEEP_WAIT_COND (stdoutstate != 0);

  return len;
}

void HAL_UART_TxCpltCallback(UART_HandleTypeDef *huart) {
  extern UART_HandleTypeDef huart2;

  if (huart == &huart2)
    stdoutstate = 0;
}

Dadurch werden printf() -Aufrufe dann energieeffizienter, weil der 
Prozessor im Sleep-Modus bleibt bis die Daten komplett abgeschickt sind 
(bis auf Interrupts natürlich).

[M. K. (kichi)]

Vielleicht kannst du hier Beitrag "atomic-lib für stm32" 
was hilfreiches finden.

[Niklas G. (erlkoenig)]

M. K. schrieb:
> Vielleicht kannst du hier Beitrag "atomic-lib für stm32"
> was hilfreiches finden.

Das hat nichts mit Sleep/WFI zu tun.