-
I'm planning to replace a STM32F microcontroller in an existing design with RP2040.
The main reason is:- I used a HC32 in mass production because it's cheaper and more available in stock. But it was having incomplete SDK. As the requried firmware features are increasing, it's hard to update firmware accordingly on HC32 microcontroller.
- RP2040 is in stock with enough quantity and unit price is also cheap (even with external flash chip). And it looks like much better software support.
With current HC32 microcontroller, I could get 30~40uA total power consumption in deep sleep mode on current board.
I tried to get the lowest current consumption data of RP2040.
But in most articles I found by searching, they're saying like 5~6mW in "deep sleep" mode.
Meaning more than 1mA?
What is the real current consumption of RP2040 in its deep sleep mode?
(not in RP2040 datasheet, but real case result) -
That's an interesting topic. I've seen only this thread: https://forums.raspberrypi.com/viewtopic.php?t=316458&sid=32c7d8e16d8bb1405df6276b133b0752&start=25 . The thread is only two pages, and numbers are a bit confusing, but I didn't find anything else on the net. As I get it, the real current consumption is around 0.39-1mA, which is pretty high imo.
-
What does the datasheet say?
https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.pdf
There is more data in the Pico datasheet.
https://datasheets.raspberrypi.com/pico/pico-datasheet.pdf
In all of them, the dormant power state seems to have 0.18ma as the lowest value. -
It's pretty bad. The RP2040 is great on many levels, but certainly not regarding power consumption.
Deep sleep current is never going to be lower than about 200-250µA according to many people, including my own experiments. And that's the best case. It will often be higher than this.
The RP2040 is not adapted to battery-powered devices. (A car battery would be fine though.
)
-
Some of these cheap MCUs have horrible analog specs. Power supplies are analog. Oscillators are analog. Power domain gating is analog. ADC/DACs are analog. The digital stuff is easy/cheap to prototype on a FPGA, and then synthesize and place-and-route via modern tools. The rest requires a lot of manual effort, even if you buy the IP.
IMO it's no surprise the RP2040 doesn't have great power consumption. It runs code from external FLASH, it's a dual core chip, has no code protection, etc. It's really tailored towards education and hobbyists, not much for the harshest of industrial applications.
-
What a disappointing outcome!
I expected that there would be some way to decrease power consumption under 50uA, just like (almost) all other microcontrollers.
I would rather consider ESP32-C3 bare chip, as it has similar performance spec with much lower sleeping current. -
What a disappointing outcome!
I expected that there would be some way to decrease power consumption under 50uA, just like (almost) all other microcontrollers.
I would rather consider ESP32-C3 bare chip, as it has similar performance spec with much lower sleeping current.
The ESP32-C3 is a bit more powerful MCU, although it only has 1 core and nothing similar to the PIO. But it does handle RF. It's RISC-V based. So pretty different specs overall.
Regarding its low power modes, it can get as low as about 5µA in deep sleep (not less than that), but you need to have in mind the limitations, which you are likely to overlook if you're not familiar with the ESP32 series.
When put in deep sleep, the ESP32-C3 pretty much powers down most of its internals. Almost nothing of the internal state is kept except for the RTC domain, and you can optionally (yes, only optionally) have the IOs state kept (it's not default, they'll go to high-Z by default in deep sleep! and if you opt for retaining IO state, this will increase the deep sleep current significantly). When getting out of deep sleep, it will do a full reboot (no it won't just go on at the next instruction as many other MCUs do in similar deep sleep modes) which can take up to several hundreds of ms.
With a ST MCU in stop mode, you can get as low as a couple µA or less, with all internal state, IO state and RAM content retained, and it will wake up in a few µs to a few tens of µs (if you're using a PLL.)
Those are very significant differences, it's very important people have them in mind before selecting MCUs.
-
I wonder if it's possible to improve on deep sleep with an external switch. Like TPL5110 (the first device I found). They have exactly this application on the first page of datasheet.
-
I wonder if it's possible to improve on deep sleep with an external switch. Like TPL5110 (the first device I found). They have exactly this application on the first page of datasheet.
Well, you can certainly do that but not every application is amenable to such hack. If you shut off power that means very slow wake up because the thing has to boot from scratch. Also all state would have been lost unless you take care to save it in some EEPROM or something. For some applications it may not matter but if it does, you are probably way better off finding a different micro than doing this. -
Yes you could.
Some RTCs even have this specific functionality. Like the AB1805: 14-55nA time keeping, RTCC, 256b battery-backed RAM, IRQ/clock out, and a PSW output which you could use to powergate the complete MCU.
The great thing about a RTC is that's far more accurate in time keeping than one of nano-power timers. TI is usually pretty good on low power stuff, but sometimes beaten by more niche devices.
Problem is that it's 2-chip solution. Plus the chip itself is about 2x the price of a RP2040. But if you want to go really low power, that's one way to do it.
-
Yes you could.
Some RTCs even have this specific functionality. Like the AB1805: 14-55nA time keeping, RTCC, 256b battery-backed RAM, IRQ/clock out, and a PSW output which you could use to powergate the complete MCU.
The great thing about a RTC is that's far more accurate in time keeping than one of nano-power timers. TI is usually pretty good on low power stuff, but sometimes beaten by more niche devices.
Problem is that it's 2-chip solution. Plus the chip itself is about 2x the price of a RP2040. But if you want to go really low power, that's one way to do it.
AB1805 specs looks nice.
I need just power on-off feature on a button long press.
The device has only one button. By clicking it, operation mode switches.
By long-pressing it, device power is "on" / "off",
I implemented this in HC32, where I set it in deep-sleep mode during "off".
Two-chip solution is fine.
Is there any power switching chip triggering by long-pressing?
I used toggle-switch ICs before for some other projects, but it was toggling by single click, not by long-pressing.
Is there any toggle switch ICs (of course with low poer consumption) that supports long-pressing timer?
If so, I can use RP2040. -
I need just power on-off feature on a button long press.
You could select almost any small low power MCU and make a switch-timer.
The device has only one button. By clicking it, operation mode switches.
By long-pressing it, device power is "on" / "off",
I implemented this in HC32, where I set it in deep-sleep mode during "off".
Two-chip solution is fine.
Is there any power switching chip triggering by long-pressing?
I used toggle-switch ICs before for some other projects, but it was toggling by single click, not by long-pressing.
Is there any toggle switch ICs (of course with low poer consumption) that supports long-pressing timer?
If so, I can use RP2040.
eg
A part like ML51BB9AE is MSOP10, and specs a sub 1uA low power 38.4kHz OSC.
Power management
- Normal run mode: 80 μA/ MHz + 400 μA
- Low power run mode (run with LIRC): lowest current 15 μA
- Idle mode: lowest current: 13 μA
- Power-down current: Lowest current < 1 μA
- Wake up from power down in 10us ( run with HIRC )
So you can run a button-time-state engine in that and manage power on / off and even save a few settings in the RAM or FLASH if you want.
There are dedicated button On/Off controllers like LTC2950 but they cost more than a simple MCU these days.
https://www.analog.com/en/parametricsearch/12984#/sort=s3,asc
New parts like MAX16150 have super low timing currents (10nA), but you need to work with their fixed 8 second shutdown timer.
If you are not making many, the time saved in not needing code may be enough to justify the more expensive part.
-
Can go as simple as one OR gate and code+GPIO: https://www.analog.com/en/design-notes/one-button-turns-microprocessor-on-and-off.html
The long push will be satisfied when the MCU asserts GPIO. (per the analog app note and assuming you have a shutdown capable power supply for the RP2040)
-
If you're after low power consumption, look into Silabs EFM32 Gecko family.
-
You could select almost any small low power MCU and make a switch-timer.
eg
A part like ML51BB9AE is MSOP10, and specs a sub 1uA low power 38.4kHz OSC.
Power management
...
There are dedicated button On/Off controllers like LTC2950 but they cost more than a simple MCU these days.
https://www.analog.com/en/parametricsearch/12984#/sort=s3,asc
New parts like MAX16150 have super low timing currents (10nA), but you need to work with their fixed 8 second shutdown timer.
If you are not making many, the time saved in not needing code may be enough to justify the more expensive part.
The main reason to choose RP2040 over existing HC32 design is to make the software development easier.
HC32 was enough for power consumption.
We con't want to move to just another less-widely-used microcontroller to achieve low poer consumption.
The LTC2950 looks good.
By adjusting the debouncing capacitor, it seems like we can get 2~3s delay time for "long-pressing". -
Silabs MCUs I mentioned are way more widely used in mass produced devices than RP2040. Which is more like tinkering product actually useable for something production worthy. Selecting RP2040 for ease of development is strange. IMHO the only thing attractive in for commercial devices (except dev/tinkering boards) it is a compute capability price to performance ratio.You could select almost any small low power MCU and make a switch-timer.
eg
A part like ML51BB9AE is MSOP10, and specs a sub 1uA low power 38.4kHz OSC.
Power management
...
There are dedicated button On/Off controllers like LTC2950 but they cost more than a simple MCU these days.
https://www.analog.com/en/parametricsearch/12984#/sort=s3,asc
New parts like MAX16150 have super low timing currents (10nA), but you need to work with their fixed 8 second shutdown timer.
If you are not making many, the time saved in not needing code may be enough to justify the more expensive part.
The main reason to choose RP2040 over existing HC32 design is to make the software development easier.
HC32 was enough for power consumption.
We con't want to move to just another less-widely-used microcontroller to achieve low poer consumption.
The LTC2950 looks good.
By adjusting the debouncing capacitor, it seems like we can get 2~3s delay time for "long-pressing".
But then I would not count on longevity, which pretty much sucked for their Raspberry pi products. -
The LTC2950 looks good.
IMHO it's only worth for lazy engineering when you do not care about BOM cost. And quiescent current is Higher than of many MCUs in sleep with RAM retention.
By adjusting the debouncing capacitor, it seems like we can get 2~3s delay time for "long-pressing". -
Yeah, keep in mind that any trick consisting in powering off the MCU entirely was something one could do decades ago with any CPU. Not that it makes it wrong, but certainly we have much better options these days.
As I and others have said, not being able to retain internal state and having to issue a full reset everytime it wakes up is a major pain. It may not matter one bit in some appllications, if there is no significant constraint for wake-up times and the "duty cycle" is very low, but otherwise it just renders the approach unusable. Think about the whole system before doing it. (What? You want engineers to think now? )
Beyond wake-up times and the inconvenience of having to retain internal state another way (for instance via an external chip that has a small amount of retained RAM, that you'll have to read at every 'reset' event), one other potentially major issue is the fact that GPIO state will also NOT be retained, leaving with all GPIOs in high-Z during your hand-made "sleep" mode. No problem you will say, just add pull-ups and pull-downs appropriately (assuming that only one state is required in "sleep" mode, which may not be the case.) But even so, while it will work with pull-downs, DO NOT use pull-ups in this scenario, ever. They will just power the switched-off MCU via the clamp diodes of its GPIOs, which will not only increase current draw dramatically but could make it run in absolutely uncontrolled ways.
If after all that, you're still positive, go for it!
-
Quote
powering off the MCU entirely was something one could do decades ago with any CPU. Not that it makes it wrong, but certainly we have much better options these days.
It depends.
I worked on a design about 1978 which needed very low power, to work for years from some AA batteries.
It was (and is) impossible to get a CPU which does anything useful at that power level. You have to power it down most of the time. Worth noting that probably the lowest Icc RTC chip ever is the DS1302, from ~1990, drawing ~200nA.
It was done by a little 32768Hz watch oscillator, a 4xxx series ripple counter or two, and powering the thing up for a second, every few mins. I won't say what it was (and there isn't a market for it today) but can say that it lived underwater and listened for a unique code. Not military, too... The CPU was a CMOS Z80
-
By adjusting the debouncing capacitor, it seems like we can get 2~3s delay time for "long-pressing".
How complicated/simple is your long-press power toggle ?
You could use a Schmitt Flipflop, which will be very cheap and only draw Icc when the button is pressed.
Nexperia
74HC74 says Schmitt-trigger action in the clock input, makes the circuit highly tolerant to slower clock rise and fall .
74LVC1G74 says Schmitt-trigger action at all inputs makes the circuit tolerant of slower input rise and fall times. This part has 32mA drive, so may be able to switch the RP2040 directly ? ]
Addit : lcsc has a clone, says the same Schmitt-trigger action at all inputs makes the circuit tolerant of slower input rise and fall times tho anyone might want to verify that ?
https://www.lcsc.com/product-detail/Flip-Flops_Wuxi-I-core-Elec-AiP74LVC74TA14-TB_C5361834.html
Lower voltage:
AiP74AUP1G74 : Schmitt trigger action at all inputs makes the circuit tolerant to slower input rise and fall times across the entire VCC range from 0.8V to 3.6V.
NXP: 74AUP1G74 : Schmitt-trigger action at all inputs makes the circuit tolerant of slower input rise and fall times.
Lower drive are TI
SN74HCS74 - Schmitt-trigger input dual D-type positive-edge-triggered flip-flops w/ clear and preset
SN74HCS72 - Schmitt-trigger input dual D-type negative-edge-triggered flip-flops w/ clear and preset
You want a Power on reset as well as a toggle so Schmitt on all pins is a good idea.
-
The cheapest and most reliable is debounce in firmware if done properly. I really hate when parts are needlessly thrown at the problem. It's really easy to make a barely working messy shit with tons of parts rather than make a lean elegant design which is actually more reliable.By adjusting the debouncing capacitor, it seems like we can get 2~3s delay time for "long-pressing".
How complicated/simple is your long-press power toggle ?
You could use a Schmitt Flipflop, which will be very cheap and only draw Icc when the button is pressed.
Nexperia
74HC74 says Schmitt-trigger action in the clock input, makes the circuit highly tolerant to slower clock rise and fall .
74LVC1G74 says Schmitt-trigger action at all inputs makes the circuit tolerant of slower input rise and fall times. This part has 32mA drive, so may be able to switch the RP2040 directly ? ]
Lower drive are TI
SN74HCS74 - Schmitt-trigger input dual D-type positive-edge-triggered flip-flops w/ clear and preset
SN74HCS72 - Schmitt-trigger input dual D-type negative-edge-triggered flip-flops w/ clear and preset
You want a Power on reset as well as a toggle so Schmitt on all pins is a good idea. -
The cheapest and most reliable is debounce in firmware if done properly. I really hate when parts are needlessly thrown at the problem. It's really easy to make a barely working messy shit with tons of parts rather than make a lean elegant design which is actually more reliable.
I think you have missed the entire point of this thread.
It is not about debounce, it is about using a button to provide power on / off, from suitable long press.
It needs very low idle currents. -
The "button" has been discussed on this forum before: https://www.eevblog.com/forum/beginners/push-button-power-circuit-for-arduino-trying-to-modify-it-for-12v-input/?all
Fairly good collection from the fluffy LTC2950 solution to the absolute bare bones discrete component ones.