4 ms·

Ahh the SAMD21G18. 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. We porte

Ahh the SAMD21G18. 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. We ported a rarely heard of RTOS to this chip (TNEO), and one of the most difficult parts was running tickless with sleepable states. The difficulty (discovered only by blood, sweat, tears, wtf oscope moments, dumb luck, and a random comment found on some obscure forum, definitely not in the data sheets) was that accessing certain registers (in our case RTC.CNT) would cause the chip to go in to a different clock domain temporarily and suddenly take as much as 300 usecs to read. Just this line: uint currentClock = RTC.CNT; That's all it took. Whereas most store some register into some local variable took nanoseconds, this one took a long long time. 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.

not_the_fda 4y ago
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.
- 4gotunameagain 4y ago
  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 ?
  - not_the_fda 4y ago
    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"
- maguirre 4y ago
  You too? I worked with the samr21 (includes a 802.15.4 radio. I had this exact same problem!
watermelon59 4y ago
> 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.
- bradrn 4y ago
  Do you have any recommendations as to any resources on this?
  - travisgriggs 4y ago
    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.
- tyhoff 4y ago
  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.
  - MrBuddyCasino 4y ago
    Curious, which ones are good & which ones are bad?
cozzyd 4y ago
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.
detrites 4y ago
> 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?
- not_the_fda 4y ago
  Yes. The key to saving power is to turn the hardware off as much as possible.

not_the_fda 4y ago

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.

4gotunameagain 4y ago
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 ?
- not_the_fda 4y ago
  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"
maguirre 4y ago
You too? I worked with the samr21 (includes a 802.15.4 radio. I had this exact same problem!

watermelon59 4y ago

> 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.

bradrn 4y ago
Do you have any recommendations as to any resources on this?
- travisgriggs 4y ago
  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.
tyhoff 4y ago
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.
- MrBuddyCasino 4y ago
  Curious, which ones are good & which ones are bad?

cozzyd 4y ago

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.

detrites 4y ago

> 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?

not_the_fda 4y ago
Yes. The key to saving power is to turn the hardware off as much as possible.