cpu/stm32: add pm support in uart, spi and i2c (f4)

[vincent-d]

This add pm_layered-based power management in uart, spi and i2c (f4 only so far though).

[roberthartung]

/cpu/stm32_common/periph/pm.c should use these defines in pm_set.

[vincent-d]

Fixed

[vincent-d]

Changed uart pm so that stop mode is blocked only if rx is used

[olegart]

I don't quite understand the concept.

E.g. we have sys/shell enabled — so it will block all power management until we manually disable corresponding UART every time before we go to sleep and reenable it right after wakeup?

Seems totally meaningless to me. Why anyone needs it? If you need shell access all the time, just disable PM at all.

[roberthartung]

@olegart a program with shell will never sleep, that's correct. Except if you have a low-power UART.

[kaspar030]

I don't quite understand the concept.

I think you do. The concept is just not fully implemented, thus you're right, on most (if not all) platforms, simple UART RX will block most low power modes.

[olegart]

Yes, but why?

If I need permanent shell access, I'd rather disable LPM at all, no difference with current RIOT logic. If I need sleepy device with occasional shell access (e.g. we have devices with 15 seconds of regular shell right after boot), I'll disable/enable LPM when I need that access.

With proposed changes — nothing actually changes for us in the first case, and the second case just doesn't work anymore as I can't just disable UART peripheral currently in use by the shell.

[olegart]

Long story short,

1. without layered PM — I can use shell (UART) whenever I want to by disabling LPM and I can have some sleep whenever I want to by enabling LPM

2. with layered PM — I can't use shell and LPM on the same system, period.

That's not an added functionality, that's reduced functionality.

[kaspar030]

we have devices with 15 seconds of regular shell right after boot

You can probably still do that. How's the timeout currently implemented?

[kaspar030]

with layered PM — I can't use shell and LPM on the same system, period.

That is not correct.

[olegart]

How's the timeout currently implemented?

RTC timer setting pm_prevent_sleep global variable to 0 after 15 seconds. PM checks the variable before switching to STOP mode.

You can probably still do that.

No. There's no option to disable shell, shell_run function is a one-way ticket. If I power down UART port used by it, shell will hang on the very next attempt to TX anything.

[kaspar030]

There's no option to disable shell, shell_run function is a one-way ticket. If I power down UART port used by it, shell will hang on the very next attempt to TX anything.

Let's please not mix up concepts and implementation.

Your use case could probably be implemented in uart_stdio (e.g., by adding uart_stdio_enable/disable_rx()), which would reinitialize the underlying uart with/without rx callback. Or in periph/uart, by offering a function to set/clear the rx uart independently from complete (re-)initialization.

You could also just unblock the corresponding powermode on your board once, after your timeout. Or add an option to shell to exit after a certain time.

The implementation of pm_layered is currently incomplete, but the general concept seems to map to most use-cases, on most hardware, so far.

[roberthartung]

See also: #7947

[kaspar030]

Please squash!

[vincent-d]

rebased and squashed

[kaspar030]

ACK.

[kaspar030]

Due to the default pm_blocker, problems won't show up for a while... ;)