deep sleep api for esp32 #574

liebman · 2023-06-03T18:38:56Z

This is an implementation of deep and light sleep for esp32. Included is a minimal implementation of RTCPin for RTC GPIO pins for Xtensa chips.

Wakeup sources implemented:

Timer - wake from sleep via RTC Timer
Ext0 - wake from sleep via single RTCPin
Ext1 - wake from sleep via one or more RTCPin

Examples for wake up:

esp32/examples/sleep_timer.rs
esp32/examples/sleep_timer_ext0.rs
esp32/examples/sleep_timer_ext1.rs

Most of the settings for sleep were pulled from esp-idf or gleaned by comparing register settings between esp-idf-hal and esp32-hal directly after an initial boot and after wakeup from sleep. Note in particular RtcSleepConfig::base_settings which are the RTC_CTRL differences after boot between esp-idf-hal and esp32-hal.

In Deep sleep I'm seeing about 0.15mA with a ESP32-WROOM32 module on a custom board.

Thank you!

Thank you for your contribution.
Please make sure that your submission includes the following:

Must

The code compiles without errors or warnings.
All examples work.
cargo fmt was run.
Your changes were added to the CHANGELOG.md in the proper section.
You updated existing examples or added examples (if applicable).
Added examples are checked in CI

Nice to have

You add a description of your work to this PR.
You added proper docs for your newly added features and code.

jessebraham · 2023-06-06T14:39:54Z

Thanks for working on this, looking forward to it being ready for review! Please let me know if there is anything we can do to support you in the meantime.

liebman · 2023-06-06T18:03:30Z

@jessebraham I'd love thoughts on what the API should be - particularly with respect to ownership, for instance when you're going to wake using ext0 (RTC GPIO pin) the pin needs to be setup to be routed to RTC - and set in the RTC_IO ext_wakeup0 register - should that be handled in sleep or should that be separately managed by the user?

bugadani · 2023-06-11T19:06:02Z

Disclaimer: I'm just shouting in from the sidelines.

That is actually pretty nice, good job!

For what it's worth, I think I would still prefer if creating a wakeup source would immediately configure it. It wouldn't be hard from here - make the user create the WakeupTriggers object, then pass it to each WakeupSource constructor that immediately applies itself (or not if you want them reusable). Then, WakeupTriggers could be used to start the sleep, maybe.

The only difference would be that this way we wouldn't require dyn which I believe doesn't optimize pretty well. I'm not sure in this particular case which should be pretty simple but I think LLVM hasn't been particularly skilled in removing vtables at least a few releases ago.

liebman · 2023-06-11T20:13:26Z

I think I need to implement Drop for Ext0WakeupSource to at least set the pin back to the IO_MUX. Should i save the values for anything that I change to be restored at Drop?

liebman · 2023-06-12T17:03:52Z

For what it's worth, I think I would still prefer if creating a wakeup source would immediately configure it. It wouldn't be hard from here - make the user create the WakeupTriggers object, then pass it to each WakeupSource constructor that immediately applies itself (or not if you want them reusable). Then, WakeupTriggers could be used to start the sleep, maybe.

The only difference would be that this way we wouldn't require dyn which I believe doesn't optimize pretty well. I'm not sure in this particular case which should be pretty simple but I think LLVM hasn't been particularly skilled in removing vtables at least a few releases ago.

I like this idea, however I have some concerns: (apologies in advance for the rambling below)

There is also a RtcSleepConfig instance that would need to be passed in to apply. We could add WakeupTriggers to it.
This tracks what parts can be powered down during sleep and what is required to remain powered - and wake sources adjust this on apply. For instance Ext0 keeps the RTC Peripherals powered during sleep.

Also - what should happen if the a WakeSource instance dropped after it had been applied and before the sleep? We would need to undo the changes to RtcSleepConfig as well and if more than one wake source needs a particular setting how do you know when it can be undone.

Maybe make the apply method from the wake source return a RtcSleepConfig? Then the sleep method could take an array of RtcSleepConfig and apply them at sleep time. (still we have the issue of what to do when one was dropped before sleep....

EDIT: maybe make a SleepConfig like this?

pub struct SleepConfig {
    timer: Option<&TimerWakeupSource>,
    ext0: Option<&Ext0WakeupSource>,
}

To be passed to sleep() instead of the array.

liebman · 2023-06-16T16:11:19Z

well

#[derive(Default)]
pub struct SleepConfig<'a, P: RTCPin + Pin> {
    pub timer: Option<TimerWakeupSource>,
    pub ext0: Option<Ext0WakeupSource<'a, P>>,
}

has the issue that you have to specify a type for P even if ext0 is being set to None - we'd have to type erase it using dyn...

bugadani · 2023-06-16T16:16:05Z

You can do a trick like I did in the object-chain crate, where you build up a type in compile time. It will not be very nice, though, and not very flexible.

bjoernQ · 2023-07-13T15:30:54Z

My two cents: This looks already good and maybe we should just get it in a mergeable shape (checking comments and documentation) and merge it. Then the community can iterate on the API based on real use cases

I don't think having breaking API changes here in the future is going to be a big problem (like we currently have them everywhere)

jessebraham · 2023-07-13T15:57:21Z

I'm sort of leaning towards what @bjoernQ has said as well. We can nitpick the API as much as we want, but I think this is very useful already in its current state and we can open issues for any problems which have been identified. I'd prefer to have an imperfect solution than no solution at all :)

(Also I'm sorry it's taken us so long to come to this conclusion!)

I think if you're able to please rebase then this is probably pretty much good to go.

bugadani · 2023-07-13T20:46:53Z

(Also I'm sorry it's taken us so long to come to this conclusion!)

Sorry for being a cause of delay here. I have some interest in adapting this PR to the S3, so I'd second getting this merged sooner than later.

add Ext0 wakeup source (WIP/Non-working)

bjoernQ

LGTM - just want to wait for Jesse's approval before merging

jessebraham

Thank you once again for all your work on this, LGTM!

* deep sleep api for esp32 * move to list of wakeup sources * improve Ext0WakeupSource - still WIP * add deep sleep with timer wakeup example add Ext0 wakeup source (WIP/Non-working) * removed alloc (using heapless now) * Sleep: ext0 wakeup working * add sleep_timer_ext0 example * API change: move sleep into RTC as sleep, sleep_deep, sleep_light * fix sleep examples for new API * sleep only implemented for esp32 at this time * sleep only implemented for esp32 at this time * Implement a simple RTCPin trait to support sleep * implement RTCPin for all xtensa SOC * cargo fmt & update changelog * fix change log order (accidentally swaped during rebase) * implement Drop for Ext0WakeupSource * added Ext1 wakeup source * cargo fmt * healpess was unused, removed * fix pase macro usage

dimpolo · 2023-12-06T13:00:52Z

Hi, sorry for commenting on this closed issue.
What is the reason for the 100ms delay before going to sleep?

liebman · 2023-12-06T13:08:37Z

Hi, sorry for commenting on this closed issue. What is the reason for the 100ms delay before going to sleep?

In the examples? To make sure the print messages are sent before the UART is powered down.

dimpolo · 2023-12-06T14:55:01Z

Hi, sorry for commenting on this closed issue. What is the reason for the 100ms delay before going to sleep?

In the examples? To make sure the print messages are sent before the UART is powered down.

Sorry, I meant here: https://github.com/liebman/esp-hal/blob/a2b0941001a95366759009c3206b980423769e9e/esp-hal-common/src/rtc_cntl/mod.rs#L239

liebman · 2023-12-09T18:02:56Z

Hi, sorry for commenting on this closed issue. What is the reason for the 100ms delay before going to sleep?

In the examples? To make sure the print messages are sent before the UART is powered down.

Sorry, I meant here: https://github.com/liebman/esp-hal/blob/a2b0941001a95366759009c3206b980423769e9e/esp-hal-common/src/rtc_cntl/mod.rs#L239

I'd have to assume then that this was left in by mistake. Please open an issue so we don't loose track of this.

liebman force-pushed the esp32-sleep branch 2 times, most recently from b48671f to 31ba351 Compare June 11, 2023 16:36

liebman marked this pull request as ready for review June 11, 2023 16:44

liebman force-pushed the esp32-sleep branch from f6ffe65 to de58edb Compare June 20, 2023 21:47

bugadani mentioned this pull request Jun 30, 2023

Standby power optimization card-io-ecg/card-io-fw#58

Closed

liebman added 3 commits July 14, 2023 06:09

deep sleep api for esp32

acac9c4

move to list of wakeup sources

22493af

improve Ext0WakeupSource - still WIP

905abec

liebman force-pushed the esp32-sleep branch from 139b15a to 42548ae Compare July 14, 2023 13:23

liebman added 11 commits July 14, 2023 06:56

add deep sleep with timer wakeup example

cf7dc6d

add Ext0 wakeup source (WIP/Non-working)

removed alloc (using heapless now)

44c1014

Sleep: ext0 wakeup working

dc382aa

add sleep_timer_ext0 example

6ecbea2

API change: move sleep into RTC as sleep, sleep_deep, sleep_light

c81f9d0

fix sleep examples for new API

a5900b2

sleep only implemented for esp32 at this time

b569858

sleep only implemented for esp32 at this time

54bac9c

Implement a simple RTCPin trait to support sleep

065a767

implement RTCPin for all xtensa SOC

2ac0e3e

cargo fmt & update changelog

2b69b0e

liebman added 6 commits July 14, 2023 06:59

fix change log order (accidentally swaped during rebase)

e84b147

implement Drop for Ext0WakeupSource

a7faaed

added Ext1 wakeup source

beefb5b

cargo fmt

1ef535b

healpess was unused, removed

995512b

fix pase macro usage

a2b0941

liebman force-pushed the esp32-sleep branch from 42548ae to a2b0941 Compare July 14, 2023 14:07

bjoernQ approved these changes Jul 14, 2023

View reviewed changes

jessebraham approved these changes Jul 14, 2023

View reviewed changes

jessebraham merged commit 37466fd into esp-rs:main Jul 14, 2023

jessebraham mentioned this pull request Jul 14, 2023

Implement support for light-/deep-sleep #375

Open

7 tasks

bugadani mentioned this pull request Jul 20, 2023

ESP32-S3 deep sleep #660

Merged

dimpolo mentioned this pull request Jan 15, 2024

Possibly redundant delay in Rtc::sleep #1082

Closed

liebman deleted the esp32-sleep branch January 26, 2025 18:59

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

deep sleep api for esp32 #574

deep sleep api for esp32 #574

liebman commented Jun 3, 2023 •

edited

Loading

jessebraham commented Jun 6, 2023

liebman commented Jun 6, 2023

bugadani commented Jun 11, 2023

liebman commented Jun 11, 2023 •

edited

Loading

liebman commented Jun 12, 2023 •

edited

Loading

liebman commented Jun 16, 2023

bugadani commented Jun 16, 2023 •

edited

Loading

bjoernQ commented Jul 13, 2023

jessebraham commented Jul 13, 2023 •

edited

Loading

bugadani commented Jul 13, 2023

bjoernQ left a comment

jessebraham left a comment

dimpolo commented Dec 6, 2023

liebman commented Dec 6, 2023

dimpolo commented Dec 6, 2023

liebman commented Dec 9, 2023

deep sleep api for esp32 #574

deep sleep api for esp32 #574

Conversation

liebman commented Jun 3, 2023 • edited Loading

Thank you!

Must

Nice to have

jessebraham commented Jun 6, 2023

liebman commented Jun 6, 2023

bugadani commented Jun 11, 2023

liebman commented Jun 11, 2023 • edited Loading

liebman commented Jun 12, 2023 • edited Loading

liebman commented Jun 16, 2023

bugadani commented Jun 16, 2023 • edited Loading

bjoernQ commented Jul 13, 2023

jessebraham commented Jul 13, 2023 • edited Loading

bugadani commented Jul 13, 2023

bjoernQ left a comment

Choose a reason for hiding this comment

jessebraham left a comment

Choose a reason for hiding this comment

dimpolo commented Dec 6, 2023

liebman commented Dec 6, 2023

dimpolo commented Dec 6, 2023

liebman commented Dec 9, 2023

liebman commented Jun 3, 2023 •

edited

Loading

liebman commented Jun 11, 2023 •

edited

Loading

liebman commented Jun 12, 2023 •

edited

Loading

bugadani commented Jun 16, 2023 •

edited

Loading

jessebraham commented Jul 13, 2023 •

edited

Loading