ESP32 enhancement: support automatic light-sleep / dynamic freq scaling
On the esp32 automatic light sleep / dynamic frequency scaling / power management puts the CPU to sleep when all tasks are idle thereby reducing the power consumption to about 1mA instead of around 40mA @ 160Mhz. The special feature of auto light sleep is that it can maintain a Wifi association by waking up at the appropriate times to receive AP beacons and respond to them. This ticket proposes to discuss how to enable auto light-sleep.
The first issue is that FREERTOS_USE_TICKLESS_IDLE needs to be enabled in sdkconfig.h and that machine.freq() must set pm.light_sleep_enable = true.
The next issue is that mp_hal_stdin_rx_chr and mp_hal_delay_ms in mphalport.h do not call vTaskDelay and instead call ulTaskNotifyTake which does not seem to enable auto light sleep (need to dig into this). Specifically, in the idle loop without wifi enabled ulTaskNotifyTake almost always returns after 100ms, which seems to be too little for light sleep to kick in.
The use of vTaskDelay got switched to ulTaskNotifyTake as part of https://github.com/micropython/micropython/commit/14ab81e87accedfb9ed231b206dd21f3a0143404 because it affects interrupt latency too much, see #3894.
Adding a call to vTaskDelay(4) in there for test purposes results in the expected power savings (a value of 4 is the minimum for light sleep to kick in). However, it messes up gpio: they all(?) go low, which is unexpected (I expected ESP-IDF to handle this appropriately). The gpio issue also affects the uart: the console no longer works unless one manages to get a char in while mp is polling. Mysteries...
Update: I had not understood the second parameter of ulTaskNotifyTake: setting that to 4 also causes light sleep to kick in.
esp32/modmachine: Add support for changing the CPU frequency.
I've tested this patch and it works well, to dynamically change the CPU frequency. The only issue is potential increase in latency of interrupt handling, as described by the ESP IDF:
Enabling power management features comes at the cost of increased interrupt latency. Extra latency depends on a number of factors, among which are CPU frequency, single/dual core mode, whether frequency switch needs to be performed or not. Minimal extra latency is 0.2us (when CPU frequency is 240MHz, and frequency scaling is not enabled), maximum extra latency is 40us (when frequency scaling is enabled, and a switch from 40MHz to 80MHz is performed on interrupt entry).
But since the patch here just uses a fixed frequency, not locks are auto-scaling, it should have minimal effect on interrupt latency (but latency has not been tested).
See issue #3832.