core: Automatically select the lowest possible LPM mode

[jnohlgard]

We have currently the following logical power modes in RIOT:

Mode	Comment
LPM_ON	MCU is active.
LPM_IDLE	MCU is idle.
LPM_SLEEP	MCU in sleep mode.
LPM_POWERDOWN	MCU is powered down.
LPM_OFF	MCU is off.
LPM_UNKNOWN	status unknown/unavailable

Currently, LPM_IDLE is activated when the idle thread is scheduled to run. This makes sense logically, but it is not optimal. This led me to implement the LPM driver for Kinetis [#2605] in such a way that it only checks if the requested mode was LPM_ON and return quickly, or for any other mode it will begin examining which modes are available given the set of peripherals active at the moment (using the atomic counters from #2321) and then pick the lowest possible sleep mode.
I would like to move this logic to the idle thread to let all platforms benefit from this automatic low power mode selection.

For Cortex-M platforms the modes are quite straightforward to map onto hardware modes. RUN, WAIT and STOP would correspond to the top three modes in the table above. For Kinetis it would be possible to further extend this and use VLPS or LLS modes for LPM_POWERDOWN and LPM_OFF. Each of these mappings would still need to be platform dependent since each platform has its own power modes and requirements, but the logic to choose between them could be centralized in the core LPM handler.

The plan:

• Introduce lpm_[un]inhibit_idle, lpm_inhibit_sleep etc. similar to the implementation in kinetis: Add LPM implementation #2605 which will inhibit the given mode and any lower modes.
• Let the peripheral drivers themselves tell the system if the peripheral is active and what power modes it requires in order to function. This is done by calling lpm_inhibit_xxx, for example an SPI driver in master mode might only be able to transmit if we are in WAIT mode or higher, then we call lpm_inhibit_sleep before beginning each transfer and then lpm_uninhibit_sleep after the transfer is completed.

Q: What was the original intent behind LPM_OFF? Is it supposed to turn off the MCU permanently, like when you do a shut down on a PC, or is it intended to be "resumable"?

Questions? Comments?

[PeterKietzmann]

I don't have detailed comments atm but I like your proposal in general and definitely see the need to spend some more work in this topic. Hope to do some thoughts in the after next week

[d00616]

Your plan looks good.

I have additional ideas:
The power management needs also to switch between an low latency mode and low power mode. This is provided by hardware on NRF51 platform. I think its an good idea to inform the driver about this mode to manage things.
Allow an driver to switch off the hardware like UART or SPI master when this is only triggered by MCU and not by external events.

[jnohlgard]

OK so @jfischer-phytec-iot started working on this in https://github.com/jfischer-phytec-iot/RIOT/commit/3034040ca40c0e4662e2ff88423b555fe0d59e59 as a generalization of the concepts introduced in #2605

@d00616 Do you want device drivers to start using the xxx_poweron(), xxx_poweroff() functions in the peripheral drivers?

[d00616]

@gebart I'm not sure what you mean with your question. Lesion i have learned is a driver must be in functional state when it's initialized.

I my opinion this _poweron, _poweroff model makes it difficult to implement an low power application. What device drivers are included and powered on is defined by choosing an board. But an application has to care about switching all devices off, but i don't know any devices are implemented in the future.

To power off devices unknown to my application, it needs integrating device drivers in global power management. So all devices can be switched of in an high latency power down mode until an application has configured an device to allow wake up events.

Next thing is switching off an part of hardware controlled by device driver. What if i don't need to wait for incoming events like receiving data via UART or SPI?

It looks like my ideas and questions are solved with new Nordic NRF52 platform. There is an automatic power management switching off unused components. To fulfill my needs the actual driver API needs no changes because i have no plans developing software on other platforms.

I don't know what Nordic competitors are planning. Its possible that we don't have to care about power management of MCU periphery in the future on modern MCU. But we are not at this point now.

For generic power management, i think it's an good idea to implement the option to switch between High Frequency Timer and RTC if available. This reduces energy consumption. Going into this mode needs to know if an task or driver is depending on high frequency timers (Radio, UART in receive mode...).

[punchcard60]

@OlegHahm In general I like this approach but I think it needs more. We need to consider whether to preserve the RTC and other things like SRAM. Consider is there a backup battery to preserve RTC/SRAM? Also clocking frequency and operating voltage can be set in some MPUs. It would be good if the power management facility could at least limit how these parameters are governed, even in RUN mode. @d00616 also raises several good points. I would be willing to shepard a task force to work this out if you think it is warranted.

[punchcard60]

@gebart wrote: Q: What was the original intent behind LPM_OFF? Is it supposed to turn off the MCU permanently, like when you do a shut down on a PC, or is it intended to be "resumable"?
I believe the answer is yes. Some MCUs can be put in a "powered off" mode and can only be brought out of this mode by hardware reset. In this mode power consumption is a couple of uA which lets the MCU live on a battery for months or years (MSP430 low power mode 4.5).

[OlegHahm]

@punchcard60, thanks for your input and willingness to shepherd this effort. How about some phone call/video chat on this topic soonish?

[punchcard60]

Yes. We can talk as soon as is convenient for you.
I'll touch base with you on IRC.

On 12/11/2015 04:31 AM, Oleg Hahm wrote:

@punchcard60 https://github.com/punchcard60, thanks for your input
and willingness to shepherd this effort. How about some phone
call/video chat on this topic soonish?

—
Reply to this email directly or view it on GitHub
#2927 (comment).

[punchcard60]

No description provided.

[miri64]

?

[kYc0o]

Is someone working on this? @punchcard60 ?

[punchcard60]

Hello,

I'd like to announce you that me and my family are moving, you may find more information here http://ndiquyjynta.happihome.com/aeloinc

My Best, jon

[PeterKietzmann]

@gebart is everything coverey by #5453? If yes, please close.

[jnohlgard]

@PeterKietzmann I guess you meant #6160.

I did not yet have time to investigate the layered mode in the pm module, but from the short description I read in the PR it seems like it corresponds with this issue. Closing.