arduino-pico
arduino-pico copied to clipboard
earlephilhower
Add LowPower library
My attempt at making a nice low power library, that works for RP2040 and RP2350. Will close #2528, related to #345.
Adds a modified version of pico_sleep that removes some stuff (like STDIO reinit) that we can't just do in this core.
Currently working on RP2040 with a Pico board, work in progress.
Current state:
- with all unused GPIOs set to PULLDOWN: 2.08mA
- disabling input gate (
gpio_set_input_enabled(p, false)) : 1.87mA - using
INPUTmode instead: 1.58mA - disabling SWDCLK, SWDIO pins (magic pin number 30 and 3): 1.51mA
- turning off the brown out detector: 1.48mA
- changing the regulator for the digital voltage from 1.10V dow to 0.8V: 1.35mA
- powering down the USB memory: no effect, 1.35mA
- noticed that I was connected my power meter to VBUS and giving it 3.3V here, so all measurements above were actually at 3.3V
- changed to supplying 5V to VBUS: 1.22mA
- change to supplying 5V to VSYS pin (bypasses diode between VBUS and VSYS): 760µA!! (0.76mA at 5V)
ToDo and notes:
- make management of GPIO pins before sleep and after wakeup easy, provide good defaults for a e.g. Pico board
- GPIO pin leakage minimization is important
- turn off as much digital logic as possible to minimize static power dissipation; in DORMANT mode wiht GPIO wakeup, all clocks are off, so dynamic power dissipation is 0
Powering it from the actual 3V3 pin with my power meter gets the current to 869µA @ 3.3V, which is less Watt than 750µA @ 5V (3750µW vs 2870µW).. so bypassing the regulator gives good savings, too, if it can be done.
Very neat! Do any clocks or subsystems need to be reinitialized after the sleep modes? I'm thinking of things like USB or UARTs, PWM, DMA, etc.? Or do they just preserve their state and freeze clocks so that they just jump back to life afterwards?
Same here. I have a RAK11300 based project and the OEM's Arduino Framework does not seem to support any power saving measures. Thanks for all your efforts! I'm really excited to see the new features in a new release.
I'm going to set up my arduino-pico environment and try the current version for testing. :-)
@maxgerhardt is this still a draft? I'll be releasing a minor update next week...
Still a draft, need to test the sleep mode (instead of dormant) plus testing on RP2350. Also fixing the CI (the copy of the board jsons from Arduino-Pico into the platform-raspberrypi folder blocked the pio pkg update to work due to git conflicts). End of next week might be realistic.
No worries, just wanted to double check since I saw you merging master recently. Thx!
I'm just curious (i.e. not trying to be pushy :); do you have an estimated release date for this yet?
Is there anything that I could do that might possibly help?
I'm not familiar with the "workflow" business detailed below - the one that states, "Some checks were not successful". However, it seems like the only issues are with: Mac (macOS-12) (pull_request) - which seems like an odd reason for holding things up. What I am trying to learn is if this PR is effectively "ready to use" - or is it not??
Thanx!
Per @maxgerhardt this is still WIP. He does work on lots of different embedded systems so probably got caught up with other things recently.
The Mac CI issue is a non-issue, related to GH sunsetting older Mac system images which CI called. The next time Max merges with master the CI will re-run with the updated Mac x86 runner.
@earlephilhower
OK - that's fine... Just wanted to make sure I hadn't missed anything as @maxgerhardt had estimated it would be completed o/a Dec 7.
Looking at the RAK11300 I wonder how this chip will be useful for battery powered IoT applications. Even with the 869µA @ 3.3V (better than whats stated in the RP2040 datasheet 🤔), the power consumption is quite high. Thats just 3 months on a 2 Ah battery (not considering any losses). Did you make any progress on your project @ThomasLeister ?
Tbh I have up on the chip because of the power draw. I'm now planning to use the RAK 3372 / 3172
https://store.rakwireless.com/products/wisblock-core-module-rak3372?f=5&s=2
Looking at the RAK11300 I wonder how this chip will be useful for battery powered IoT applications. Even with the 869µA @ 3.3V (better than whats stated in the RP2040 datasheet 🤔), the power consumption is quite high. Thats just 3 months on a 2 Ah battery (not considering any losses). Did you make any progress on your project @ThomasLeister ?
FWIW: I'm thinking of dredging up the MSP430 (Texas Instr) project I started months ago... it appears @maxgerhardt's low power library isn't going to launch.
Mmm... so we've gone from "very neat" in November - to WIP in December w/ expected completion in a week - to dead in the water/start over in June.
That's discouraging...
Is it the hardware?... does the hardware suck? ... or something else?? Just curious...
FWIW, and in closing: After a couple of "failed miserably" experiences attempting to wrangle something like "low power operation" from Raspberry Pi's "pico" microcontroller, I have reached some conclusions:
-
The Raspberry Pi organization's attempt to build a "world-class" micro-controller is a failure. It's a failure because low power operation is essential for micro-controllers! Further, the Raspberry Pi organization's failure to acknowledge this failure has permanently damaged their credibility.
-
For proof of this design failure, one need look no further than the Raspberry Pi forum on Pico. It is littered with posts documenting the failure of the design.
And so we need wonder no more why @maxgerhardt dropped the proposed pull requests here. It's like "beating a dead horse"!
I think the consensus is the RP2040 low power modes aren't in the same league(solar system, maybe) as the established players.
The RP2350, however, seems to have fixed a multitude of sins of the RP2040's low power modes. It's not the lowest power MCU, but it's been shown to get it down to 50-60uA standby current. The SDK's Powman APIs give pretty fine controls over what goes to sleep vs. unpowered and how wakeup happens.
@earlephilhower
Perhaps the RP2350 is an improvement over the RP2040... I guess what still disappoints me is how the RPi organization responded to these failures of the RP2040. Despite multiple posts and questions on GitHub "issues" , and in the forums, nobody would even acknowledge the issue. We all make mistakes, but refusal to acknowledge them does not inspire confidence.