Power-Management on RIOT-OS

Hello alltogether,

at the moment I'm trying to bring the power-consumption of a STM32 device down as much as possible unter the control of RIOT-OS. I have some thoughts about what would be the right strategy, but I'm not shure. Therefore I would like to have some comment what I'm thinking....

As far as I know the idle-thread should bring the device to the lowest power level as possible.

So when I'm bringing the STM32 into STOP-mode and try to awake it under the control of the RTC or a low-power timer in the idle-tread how does the thread-management know what would be the next thread to work on?

Or should the "go to stop mode" implemented in the main-thread of the application? What about the other threads? Should they be stopped before such a power-management event?

I would be very glad if you could just give me some hints about what would be the right way for this functionality.

Thank you very much!

Regards,

Neo

1 Like

Dear Neo,

please have a look at https://github.com/RIOT-OS/RIOT/pull/6239 and at the documentation of the PM module: https://riot-os.org/api/group__drivers__periph__pm.html.

Cheers,

Hello Victor,

thank you for your answer, but the information in the PR or in the API-List is really not enough to understand how it should be implemented - this documentation isn’t really very helpful. A view words more would be helpful -> explanation, maybe with an example…

Can anyone explain a little bit more, how it should be implemented?

Thanks a lot!

Best regards,

Neo

1 Like

Hi Neo,

So when I'm bringing the STM32 into STOP-mode and try to awake it under the control of the RTC or a low-power timer in the idle-tread how does the thread-management know what would be the next thread to work on?

On wakeup, the ISR of the interrupt that caused the wakeup will be run. After that, RIOT's scheduler will chose the next runnable thread.

If the MCU went to sleep, it was because no other thread than idle was runnable, so idle will be chosen.

If you'd like a thread to run after an ISR, that ISR must set the thread runnable again, depending on what the thread is waiting for, via thread_wakeup(), by unlocking a mutex, sending a message or setting a thread_flag.

Kaspar