-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cpu/stm32f0: add periph_pm support #9521
Conversation
Tested on a custom device (stm32f091 based) and works! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
minor readability question
cpu/stm32_common/periph/pm.c
Outdated
defined(CPU_FAM_STM32F4) | ||
#define PM_EWUP_CONFIG (PWR_CSR_EWUP) | ||
#elif defined(PWR_CSR_EWUP8) | ||
#define PM_EWUP_CONFIG (PWR_CSR_EWUP8 | PWR_CSR_EWUP7 | PWR_CSR_EWUP6 | \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe readability can be improved by using a static inline?
static const unsigned _pwr_ewup_config(void)
{
unsigned tmp = 0;
#if defined(PWR_CSR_EWUP8)
tmp |= PWR_CSR_EWUP8;
#endif
#if defined(PWR_CSR_EWUP7)
tmp |= PWR_CSR_EWUP7;
#endif
...
#if defined(PWR_CSR_EWUP1)
tmp |= PWR_CSR_EWUP1;
#endif
return tmp;
}
... then use PWR->CSR = _pwr_ewup_config()
below.
This should optimize to a single value even when assigning a volatile
register.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll give a try
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
Ping |
cpu/stm32_common/periph/pm.c
Outdated
@@ -1,5 +1,6 @@ | |||
/* | |||
* Copyright (C) 2016 Kaspar Schleiser <kaspar@schleiser.de> | |||
* Copyright (C) 2018 OTA keys S.A. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
According to the authors list order, I think the copyright order should be reversed. Otherwise this gives the impression that OTA Keys initially contributed this file, which is not true.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed
Apart from the copyright comment, the changes look good and work (tested on nucleo-f070rb). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK
@kaspar030's comment is addressed, so please also squash
fbd9b00
to
6603ab9
Compare
Squashed |
Thanks @vincent-d. Now let's wait for @kaspar030's approval (and merge ? :) ) |
Ping @kaspar030 |
please rebase, I'll to find a device for testing |
if good, we can dismiss @kaspar030 review |
6603ab9
to
c9df230
Compare
Rebased and adapted stm32l0 implementation |
c9df230
to
05b813e
Compare
rebased |
Ah yes, sorry ;) I'll have a look later. |
cpu/stm32_common/periph/pm.c
Outdated
#endif | ||
PWR->CSR |= _ewup_config(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think activating all wake-up pins available by default is a good choice. On nucleo boards WKUP2 is connected to user button and VDD which triggers wakeup from STANDBY mode immediately (except for stm32l433rc) (#11167). On other nucleo boards you have wkup pins connected to other peripherals which can also trigger weird resets.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it would be better if this was handled or at least over-writable for every board. Since wiring is very board specific enabling this for all boards using this cpu is prone to conflicts (in some stml4 base boards uart is connected to a wake-up pin too.) IMO default configuration should be no wkup-pin enabled (cpu can allways wake up from RTC), and then when enabling a wkup pin makes sense, this should be handled on board configuration files. Thoughts @aabadie @vincent-d @kaspar030 ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's actually how it's implemented. One can define PM_EWUP_CONFIG
to enable the pins depending on their needs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Your are right, sorry I didn't read the code properly. I like it!
I'll give a last try to this PR tomorrow and will merge it. After I'll adapt #11173. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tested this PR on nucleo-f091rc and STOP mode works although consumption seems quite high (~2mA instead of 7 in normal run mode). By default, the STANDBY mode doesn't work because all wakeup pins are enabled which causes troubles.
This is why I don't like the current default behaviour with wake-up pins. See my comment below.
cpu/stm32_common/periph/pm.c
Outdated
tmp |= PM_EWUP_CONFIG; | ||
#elif defined(PWR_CSR_EWUP) | ||
tmp |= PWR_CSR_EWUP; | ||
#else |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should be done differently.
In the current state, if the user doesn't provide a define for PW_EWUP_CONFIG
, then this function will activate all wake-up pins.
This results in an invalid default STANDBY configuration for most of the nucleo boards in this case. For example, on nucleo-f091rc, with this default configuration, the STANDBY mode doesn't work unless one builds the application with CFLAGS=-DPM_EWUP_CONFIG=0
.
What about having the possibility to provide the PM_EWUP_CONFIG
in the board periph_conf.h
and include this file in pm.c
?
Then there's no need for this function, just use the following snippet in the STANDBY case, below:
PWR->CSR |= PM_EWUP_CONFIG
And provide a default PM_EWUP_CONFIG to 0 somewhere in the periph_cpu_common.h
file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this has been inherited from the previous versions which used to enable all wake-up pins.
I don't mind changing to use PM_EWUP_CONFIG
only.
I changed the wake-up pins config, and refactored even more. |
Thanks for updating @vincent-d, it looks much better like this :) I think the history of commits should be reworked: one commit introducing the pm code refactoring and one adding the support for F0. That would make history cleaner. I'll give a try asap. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested on F0, F4, L0 and L1. It works.
ACK, please squash (see #9521 (comment) for a better git history proposal)
d6eeb2d
to
7590d52
Compare
@aabadie done! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK
Contribution description
Add stm32f0 support in stm32_common pm driver.
Tested with a nucleo-f091rc. Didn't check the actual power consumption yet.
Issues/PRs references
None