Implement support for light-/deep-sleep
We should provide APIs for entering light-/deep-sleep.
Chips which have been prioritized by the maintainers have associated tracking issues linked beside them. Community members are encouraged to attempt adding support for other chips as well.
- [x] ESP32
- [ ] ESP32-C2
- [x] ESP32-C3
- [x] ESP32-C6 https://github.com/esp-rs/esp-hal/issues/1028
- [ ] ESP32-H2 https://github.com/esp-rs/esp-hal/issues/1029
- [x] ESP32-S2
- [x] ESP32-S3
For inspiration
- https://github.com/bjoernQ/esp32c3-sleep-experiment
- https://matrix.to/#/!LdaNPfUfvefOLewEIM:matrix.org/$MGQY24t_Zo-eufQ6vFjUX99MLHOb7W41f9F44BwBHX8?via=matrix.org&via=tchncs.de&via=mozilla.org
Support for light-/deep-sleep for ESP32 added in #574. I will begin work on supporting additional chips in the coming weeks.
I'd like to add as a todo item that the HAL should probably not expose the RtcSleepConfig type(s) directly. Instead, the HAL should expose something akin to esp-idf's "sleep flags". The reason is, that currently it is possible to create subtly broken sleep configurations: the user is free to set whatever combination they want, and the driver has no way of verifying the sleep configuration. Wakeup sources may also need to take care of setting up correct values, which should be easier handled when applying sleep flags.
I'd like to contribute to this. Have an important use-case for C3, and a nice-to-have use case with S3 for light-sleep.
I have no idea how to go about doing this. I'll read through the links, but embedded and EE stuff is a bit crazy to me.
This will be my first time contributing to this project, and couldn't find a contributing file/instruction documentation. How should I go about contributing? fork-draft PR-iterate?
@jessebraham should we coordinate on this one?
I've made #712
at this point, it's just a note-taking exercise, but if all goes well, will shortly start implementing the different sleeps for c3.
ESP32-C3 support added in #795
I'm working on C6 now. It's a bit annoying as function names are different, but the flow seems to be similar enough. May take some time but I'll hope to get it working in a week or two.
Hi folks! I wanted to ask a question. Is there a particular reason for those delays introduced before sleeping? See here https://github.com/esp-rs/esp-hal/blob/main/examples/src/bin/sleep_timer.rs#L37-L40
I do realise that my esp32s3 sometimes never wakes-up after entering deep sleep with a timer wake-up source. I am not sure if the cause is that I do not delay enough, or that I use --release mode which optimizes things away. So... is there a good reason to delay before entering deep sleep? And how big should that delay be relative to the clock?
EDIT: I'm definitely not imagining things. When setting deep sleep with a timer wakeup source (without delaying manually), at 80MHz it works as expected, but the same code running at max clock, it never wakes up. I presume there's some latency involved into getting timers registered, and the delay must be explicitly added by users. Maybe it would be wise to incorporate these delays within the HAL itself, so users don't have to guess where a delay must be manually added or not.