Low power microcontrollers

[kevlar700]

The STM32U* and STM32L* parts have low power features namely; multispeed internal clocks (MSI) and sometimes low power run. This means the program can adjust the system clocks at any moment to reduce power usage. This would appear to only be compatible with light runtimes? I use light runtimes to make porting to chips more expedient in any case. I open this issue simply to raise awareness and consideration during future runtime developments.

Food for thought:
https://www.freertos.org/Documentation/02-Kernel/02-Kernel-features/07-Lower-power-support
https://www.freertos.org/low-power-ARM-cortex-rtos

[jklmnn]

Hi, thanks for bringing that up! The runtimes don't do any specific power saving however at least the light runtime should not interfere if it was done in the application code. For the tasking implementation it may depend on the timer configuration so I can't make any predictions on how the tasking would work together with power saving features.

[damaki]

In my experience the design of the runtimes already lends itself to low-power tasking; it's the target-specific code in package System.BB.Board_Support (file s-bbbosu.adb) that would need to be adapted to use any low-power timing features of a particular target. If you port the tasking runtimes to a new target you'd probably need to write your own version of this file anyway (if the SysTick-based one isn't appropriate for your requirements).

For example, back when I contributed the nRF52 runtimes in #12 I wanted to use it for low-power applications, so my implementation of s-bbbosu.adb used a 24-bit RTC peripheral to schedule the alarm interrupt. This allowed the CPU to sleep for long periods of time until the next scheduled activity, and since the RTC runs off the 32 kHz clock the main clock could also be turned off, resulting in an average power consumption of 3 µA while still maintaining task scheduling.

Someone doing a STM32U* or STM32L* port of the tasking runtimes could provide their own implementation of s-bbbosu.adb to handle any different timer/clock characteristics they need. For example, if the clock speeds could change, then the implementation would need to handle this by rescheduling the alarm when the clocks change so that the alarm still expires at the correct time.

In any case, some work would need to be done by whoever is writing the port so it'd take more time to port the tasking runtime than the light runtime.