There are many threads on this forum and on the micropython forum about lightsleep on PICO and PICO 2.
I want to start a discussion about the best way forward.
TL;DR lightsleep is a blunt instrument for reducing power consumption. It turns off almost all of the RP2040 and RP2350. It has always had limitiation/bugs on PICO.
The RP2040 and 2350 have support for powering down individual hardware blocks that are not needed for a particular application. But there is no way to do that from micropython code now.
lightsleep has been has been broken in one way or another from day 1 on PICO.
The commit that added lightsleep support for PICO https://github.com/micropython/micropyt ... c54904a48c
includes
Yes, the initial implementation turned off all of the RP2040 chip except for the timer block.
It then used timer 3 to wakeup when the required time interval passed.
Nothing else would wake up the RP2040.
This meant lightsleep would prevent WIFI and USB from working (other things too).
Over time minor changes were made so WIFI and USB would work.
But, those changes mean calls to lightsleep return early when WIFI or USB are active.
Further, in version 1.24.0 a change was made such that lightsleep almost always returns early.
As long as USB and WIFI are not active it typically returns after 30 to 100 milliseconds.
I have a trivial fix for this. I will create a pull request next week to submit it.
On other hardware a button press can generate an interrupt through the Pin class and wakeup from a lightsleep.
That has never worked on PICO.
People use lightsleep to reduce the power needed to run their PICO from battery.
Right? Otherwise just use time.sleep_ms.
On PICO lightsleep is a very blunt tool it turns almost everything off.
Depending on what you are doing you may only need specific a few hardware blocks turned on.
Side note: If you are working with a PICO W the wifi block consumes a lot of power.
Before you do anything else you need to turn off the wifi block.
To be clear, when I say hardware blocks are being turned off that is not exactly true.
The clock to those hardware blocks is stopped.
Almost all of the power consumed happens on clock changes.
When the clock is stopped the power for the hardware block is almost 0.
If you are interested in reducing the power needed for your app the RP2040 and RP2350 have a rich feature set to turn off individual hardware blocks.
Take a look at the RP2040 data sheet https://datasheets.raspberrypi.com/rp20 ... asheet.pdf section 2.11 Power Control.
Also look at section 5.7 which documents how much power each hardware block consumes.
AS an example, if your application does not need I2C you can turn those blocks off forever.
Alternatively, you can turn hardware blocks off only when sleeping.
As an example, it is surprising but, if both ARM processors are sleeping SRAM can be powered down.
At this time there is no way from micropython code to control which hardware blocks are disabled.
I am working on changes to the rp2 module to allow control of the registers described in the data sheet in section 2.11.
A pull request for these changes will take a while.
I hope to have it ready early in the new year.
I want to start a discussion about the best way forward.
TL;DR lightsleep is a blunt instrument for reducing power consumption. It turns off almost all of the RP2040 and RP2350. It has always had limitiation/bugs on PICO.
The RP2040 and 2350 have support for powering down individual hardware blocks that are not needed for a particular application. But there is no way to do that from micropython code now.
lightsleep has been has been broken in one way or another from day 1 on PICO.
The commit that added lightsleep support for PICO https://github.com/micropython/micropyt ... c54904a48c
includes
That is still true.It doesn't yet support longer periods than 72 minutes, or waking up from GPIO IRQ.
Yes, the initial implementation turned off all of the RP2040 chip except for the timer block.
It then used timer 3 to wakeup when the required time interval passed.
Nothing else would wake up the RP2040.
This meant lightsleep would prevent WIFI and USB from working (other things too).
Over time minor changes were made so WIFI and USB would work.
But, those changes mean calls to lightsleep return early when WIFI or USB are active.
Further, in version 1.24.0 a change was made such that lightsleep almost always returns early.
As long as USB and WIFI are not active it typically returns after 30 to 100 milliseconds.
I have a trivial fix for this. I will create a pull request next week to submit it.
On other hardware a button press can generate an interrupt through the Pin class and wakeup from a lightsleep.
That has never worked on PICO.
People use lightsleep to reduce the power needed to run their PICO from battery.
Right? Otherwise just use time.sleep_ms.
On PICO lightsleep is a very blunt tool it turns almost everything off.
Depending on what you are doing you may only need specific a few hardware blocks turned on.
Side note: If you are working with a PICO W the wifi block consumes a lot of power.
Before you do anything else you need to turn off the wifi block.
To be clear, when I say hardware blocks are being turned off that is not exactly true.
The clock to those hardware blocks is stopped.
Almost all of the power consumed happens on clock changes.
When the clock is stopped the power for the hardware block is almost 0.
If you are interested in reducing the power needed for your app the RP2040 and RP2350 have a rich feature set to turn off individual hardware blocks.
Take a look at the RP2040 data sheet https://datasheets.raspberrypi.com/rp20 ... asheet.pdf section 2.11 Power Control.
Also look at section 5.7 which documents how much power each hardware block consumes.
AS an example, if your application does not need I2C you can turn those blocks off forever.
Alternatively, you can turn hardware blocks off only when sleeping.
As an example, it is surprising but, if both ARM processors are sleeping SRAM can be powered down.
At this time there is no way from micropython code to control which hardware blocks are disabled.
I am working on changes to the rp2 module to allow control of the registers described in the data sheet in section 2.11.
A pull request for these changes will take a while.
I hope to have it ready early in the new year.
Statistics: Posted by cpottle9 — Sat Dec 14, 2024 3:48 am — Replies 2 — Views 64