MicroPython • Re: How do you get a Pico W to sleep?

hippy, thanks for your feedback.

As you noted, the code in RP2-PowerCtrl is all in micropython.
It was relatively easy because currently the pico-sdk does not access with the underlying registers.
And the micropython interpreter only accesses them from machine.lightsleep.

Controlling the PLLs and reconfiguring the clock tree are more complex.
pico-sdk sets up the clock tree and initializes the PLLs at startup.
But, machine.lightsleep disables the PLLs on entry and re-configures the clock tree to run everything directly from the external crystal oscillator (XOSC).
Before returning lightsleep re-enables the PLLs and puts the clock tree back the way it was.
In addition, calls to machine.freq change the CPU clock by modifying the system PLL config.
If only one PLL is used machine.freq would need changes.

katak255 mentioned running only one PLL with everything clocked from the other PLL at 48 MHZ.
Indeed, that would save 1.5 to 2.5 milliamps.
There is a second option which likely would be easier to implement from micropython.
Look at the RP2040 datasheet RP2040 Datasheet section 2.18.2.
The PLLs have an internal oscillator called VCO when running at a high frequency more power is consumed.
One could choose to run VCO at a lower frequency while preserving the output frequency of the PLL.
With a lower VCO frequency the PLL output clock will have more jitter.
Section 2.18.2.1 in the datasheet says the system generally will tolerate this except for a few time critical applications.

The datasheet provides examples using lower VCO frequencies.
I made changes to ports/rp2/clock_extras.c to try this and I saw about 0.7 milliamp power saving.

You talked about a "Proof of Concept", I can code more changes to clock_extras.c and create a pull request for review by the development team for micropython. The changes would allow choosing between clock tree structures and setting PLL configuration.
I am still learning how the PLLs and clocks work. It will take some time.

hippy wrote:

I understand the modularisation but It would be possible to combine all the files into one which would mean users only having to upload one '.py' file.

I tried combining the code into a single file and ran into name conflicts.
The issue is the constants like EN0_CLK_SYS_I2C0 are not really bound to the class.
For 2040 EN0_CLK_SYS_I2C0 has a value of 6 and for 2350 it is 11.
I got a compile error for the second definition of one of these constants.
Some people might consider this a micropython bug. I won't pursue that.

I could add a new file power_ctrl.py containing:But now there are four files to upload.

I would argue it is not a big burden for someone to import a different file for RP2040 and RP2350.
You need to install a different micropython uf2 file and RP2350 has more bits assigned in SLEEP_EN1 and WAKE_EN1.
Power minimization strategies will differ somewhat between the two devices.

hippy Also wrote:

You could alter the 'EN0_CLK_SYS_SRAM3 = const(31)' to be 'const(1 << 31)' etc. That would allow the functions using those to also be called with a single integer mask value which would speed things up but that may not be necessary as they are likely only called at the start of code.

Two points:

• I agree with the last part. A user will likely set the sleep bits only once at the start of their code. In some limited cases a use might alter a few wake bits at runtime.

• I define constants for the EN0 and EN1 registers each 32 bits. For the EN1 registers the constant value is 32 plus the bit position. If I did not do that I would need twice as many APIs.

Statistics: Posted by cpottle9 — Mon Jan 06, 2025 9:03 pm

---