Deep Sleep: Best Practices / FAQ

[dannyyy]

Hi,

Despite I'm experienced in software engineering, the world of ESP32 and Arduino is new to me.
I've some questions regarding the ESP deep sleep functionalities and which best practices has been established to solve these.

• I use the 3V3 power source of the ESP32 developer board to power my sensors. If my ESP32 goes to deep sleep, the sensors are still power sourced. What is best practice in this case? Using one of the GPIOs as a switch between the VCC/GND and the sensor to cut off power before deep sleep? Or better to use a transistor instead of using the GPIO pin? I assume the sensor is tollerant to these power offs
• Some libraries are working async. This means I can request a messurement and I will get a callback as soon as the results are ready. Is there any possibility that a callback can survive a deep sleep? Otherwise I have to busy wait until the callback has arrived to initiate the deep sleep afterwards.
• How long should the ESP32 sleep that it's worth? Or to rephrase the question, is there a difference in sleeping for 1s and doing something for 0.1 and sleeping for 20s and doing something for 2s. It's the same ratio but propably not the same power consumption overall.
• Some actors / sensors have a (session) state to work properly. Going to deep sleep means the variables and instances gets killed. Is it allowed to attribute all these with "RTC_DATA_ATTR"? Or is there a high potential, that the internal state gets invalid/corrupted? Especially sensors which needs to run for at least several seconds to minutes to produce proper results, are affected by this.
• A lot of libraries use millis() internaly. As far as I have observed, millis() starts from 0 after a wakup. Is there a way to persist this? As a temporary solution, I save the current value to RTC memory and restore it as an offset. To work with I have a helper function which sum up the "millis()" + "offset" + "sleep duration" to have more or less good estimation of the real value. What is the proposed and bullet proofed solution for this? Mainly I use this to check whether a certain job has to be done after wake up or can be done later (like a polling interval).
• Is it useful to combine deep sleep functionality with multitasking to reduce the woken up time by doing stuff in parallel or at least use the waiting time meaningful? How to synchronize the main thread to the others until the ESP32 can sleep again? In Java and other languages there is somethin like CoundDownLatches. This could be easily adapted with the few options ESP32 provides.
• If the main thread initializes communication ports/protocols like HardwareSerial, I2C, OneWire with xyz.begin(), is it allowed to use this ressource from another task (maybe core) as long as I can guarantee that there is no mutual access to the same ressource by using a Mutex? Or is it just allowed, that only the creating (main) task should use the ressource? In that case I need to maintain a flag which the creating task can check and do somethin with it.

I guess a lot of these questions are basics (I didn't get until now), or "depends" on the use case. Nevertheless I'm looking forward the get some examples in which specific case, an experienced developers did what.

Kind regards
Danny

[boarchuz]

1. That will depend mostly on the sensor. Maybe it has a shutdown input pin, maybe you can instruct it via I2C to enter a lower power state, maybe its current draw is low enough that you can drive it directly with a GPIO or maybe you'll need a load switch / MOSFET.
2. Are measurements taking so long that that's a concern? Are the sensors going to fail gracefully if the host disappears mid-transaction? Callbacks won't 'survive'- there's nothing to execute them in deep sleep and memory is reinitialised on wakeup.
3. I don't have a good answer, but if you have to ask the question, perhaps light sleep is more appropriate? Of course the longer the deep sleep the better, especially if you're doing something power hungry every wakeup like connecting to WiFi.
4. Yes, RTC_DATA_ATTR is fine.
5. The 150kHz RTC slow clock will keep ticking in deep sleep.

Code: Select all

#include "soc/rtc.h"
#include "esp_clk.h"
uint64_t rtc_ticks = rtc_time_get();
uint64_t time_us = rtc_time_slowclk_to_us(rtc_ticks, esp_clk_slowclk_cal_get());

I just remembered the deep sleep example has a neat printout of sleep time: https://github.com/espressif/esp-idf/bl ... main.c#L86
6. Naturally, the sooner it can return to sleep, the better the power savings. Look into FreeRTOS docs, examples, etc for how to parallelise and synchronise tasks.
7. Generally that's fine. A lot of the IDF has resource locking internally so you don't need to handle it yourself, and the Arduino libraries may even implement their own as well. It depends on the peripheral, implementation, etc.