Hacker News Reader

I hate that chip. I had a client pick it for a project that they wanted low power. You can't put the chip fully to sleep. There is errata on the NVM controller that it doesn't always wake from sleep so when the chip wakes it executes garbage. You have to keep the NVM controller powered during sleep to recover from sleep.

I was able to get this microcontroller into deep sleep of the range of a few microamps, and would always reliably wake up from the RTC interrupt. I wonder what caused your issues ?

You may have had newer silicon that fixed the issue, or you didn't have NVMCTRL fully asleep. Its in the errata "1.14.2 Power-down Modes and Wake-up From Sleep"

You too? I worked with the samr21 (includes a 802.15.4 radio. I had this exact same problem!

> My experience in this world of embedded chips, is that many of the tutorials you read do not deal with power consumption really. They assume that you're playing with a dev board. Or that your application has copious amounts of power. But if you live in a battery powered world, your entire game lies around navigating between sleep and wake states on the chip.

This has been my experience so far trying to build my own devices at home. They all assume I’ll connect things to a USB port or have a power adapter. Material on how to deal with battery voltage dropping over time, determining battery level, etc. is really scattered. Makes me wish I was an EE major instead of CS.

I got into ESP32 hacking a few months back, and I'm glad I happened to start with a battery-powered device (an M5stack StickC) because it imposed this awareness very early - the device has an internal battery, but it's only good for about half an hour running flat out. So after building a little wifi detector the first patch was adding a battery meter and an auto-dimmer to save a few mAh. Now every project starts out with some ideas about what I'd like the device to do, followed by questions about how much temporal resolution I really need, when and how to dump or store data etc. as well as the more obvious constraints of tiny memory and storage capacity.

It's...kinda fun? Perhaps more so as I only have to please myself rather than an employer or client. You can just query the ESP32 about battery voltage/current/charge state/temperature which of course makes things very easy. On the assumption that specifications and quality vary a lot and that voltage doesn't fall off in a convenient linear fashion, I've just been experimenting with it like any other environmental variable to decide between performance, economy, or panic modes.

The key to low power is to put the micro in a sleep state as much as possible. You have to rethink running things in a loop and make it interrupt / event driven.

Set it up to wake from sleep on some interrupt, do your processing, then go back to sleep. You can setup a timer interrupt to wake periodically to do processing as well.

My experience programming for the Watchy (epaper watch on esp32) exactly. Basically the only way of programming it is being woken up every minute by the RTC, running as little as possible, setting up the next interrupt by the RTC and going back to sleep.

I got mine to last about a week on the stock battery, i know of people who have done better but being a minute-resolution clock helps a lot.

Excellent advice! I'll try that out and see how long I keep it running between charges.

You speak of such truths :D. It's a seriously under-documented knowledge gap on the Internet. There are an infinite number of Cortex-M4 MCU's but only a few I would recommend hardware companies actually use, primarily due to power consumption of production work-loads (sleeping and deep sleep) and the software packages that are bundled, both of which are generally not assessed before choosing hardware.

Curious, which ones are good & which ones are bad?

Any STM32 L series or nRF can do very low power draw if used correctly. Gotchas include making sure other components on your board aren't drawing power.

Do you have any recommendations as to any resources on this?

So far... we've been pleased with our newer developments on the NRF52832 using Zephyr. It's the same chip (I think) that Apple used in their AirTags.

That said, we're still in that early-ish phase. Four-ish years from now, there's probably going to be a post where I start off with something like

"Ahh the Nordic NRF52832. Of all the chips to show up on HN today. This chip I know not half as much as I'd like to and half as much I wish I didn't have to..."

It's sort of a vicious cycle.

> But if you live in a battery powered world, your entire game lies around navigating between sleep and wake states on the chip.

Is this true of every chip, or are there eco-systems where it's documented better, or less of an issue for other reasons?

Yes. The key to saving power is to turn the hardware off as much as possible.

yeah we're using the SAMD21J18 for our controller board for an experiment in Greenland and... had a huge pain on porting a LoRAWAN stack to it due to clock domains affecting timing too much. It didn't matter too much (since the message rate is so low it doesn't really matter for power consumption) so I just made the tolerances really big.