32bit (C-M?) MCUs to process XX or XXX kHz streams with ultra low power? - Page 1
Forum section: electronics / general

author: evb149
author_rank: Regular Contributor
timestamp: December 18, 2016, 10:23:03 pm
content: Hi,One question I had a while back that I didn't find a great answer to is the following --Which current 32 bit SOC MCUs like Cortex-M0 or similar can acquire ADC data and process it inessentially real time (maybe with some buffering if needed) at XX kHz or XXX kHz rates and achieve ultra low power consumption while doing so?Basically I wanted to do a small amount of processing of something like continually digitizing audio and doing a bit of filtering / analysis on it but at XX microamp level average power consumptions.The problems I found with several devices I looked at from Cypress, TI, SiLabs, and Nordic were:(a) the MCUs had high power consumption for ADC operations and although the peak currents were high that could be OK except many had also high sustained overall ADC currents, and on several the ADC / reference could not be placed in idle / sleep / off / low power mode and still woken up in time to process the next sample within XX to XXX microseconds.There only seemed to be a couple discrete "ultra low power" 12 bit+ ADCs that could run at XX kHz, few or no MCU integrated ones, and of those the latency to wake up / sleep was high and the overall microamps power consumption seemed questionable.(b) The ARM CORTEX M MCUs had basically uselessly high "sleep" mode power consumption (milliamp range maybe or even XXX microamps and that's without even doing the acquisition / processing job). So "sleep" wasn't a solution.(c) The C-M MCUs often had fine "deep sleep" or similar power modes with low enough current consumption, but they would all be specified to take too long to "wake up" to any mode where data processing / acquisition could happen so that it could not keep up with 10kHz++ sample rates if set to deep sleep between samples.(d) The C-M MCUs investigated generally were not specified to have their processing units able to be clocked down to where they could run at XXX kHz or so overall clock rates. I know that "hurry up and get idle" is often a good strategy for power consumption so running at X or XX MHz for a burst and then going to deep sleep is often a good strategy for minimizing overall power consumption but that can only be done if the MCU can deep sleep and wake fast enough to handle the task / sample rate. So if that could not be done then it might be interesting to see if a MCU could be clocked to run from a 32kHz or 500kHz or whatever low frequency so that dynamic power consumption could be minimized and maybe therefore the faster to wake "sleep" mode might be usable with adequately low power consumption, but most MCUs I saw weren't well specified to run from DC to XXX kHz or even 32kHz to sub-1MHz rates. I guess some might have been able to do so but if so either the ADC or static power consumption seemed high or the specification for the static+dynamic power consumption in such low clock rate regions was too poorly specified to inspire confidence or so on. It would be interesting to know if in specification or in practice what ULP C-M MCUs can actually *run* at kHz or maybe 1MHz clock rates without requiring an external or internal oscillator / master clock as X MHz+ rates that would itself consume quite a bit of needless power. Being able to run a MCU off, say, 32kHz LFXTAL would be interesting as a mode of operation particularly if the latency to boost it up to X MHz for a burst of processing could be low so it could mode-switch in a few microseconds or less.(e) The possibility to use some kind of sub-sleep maybe deep sleep or intermediate power mode which affected the MCU core but the ability to leave integrated peripherals like ADC, analog comparator, analog op-amp or whatever active and useful for signal processing in that mode would be interesting and useful in such applications. Ideally one could start an ADC conversion and put the MCU to deep sleep for 50 microseconds or whatever while the ADC converted and then wake up to read / process the last sample and begin the conversion of the next one. But all C-M MCUs even the "ultra low power" ones from TI, SiLabs, Freescale, ST, ... seemed to be totally incapable to leave the ADC, opamps, comparators or whatever on and processing (and achieving low power consumptions) when the MCU was in anything substantially lower than "sleep mode" itself. That seemed like quite a flaw since either you have way too high static / average power consumption or you can't do the processing in time.Even the TI CC2650 with the integrated "sensor controller" coprocessor / peripheral system did not seem capable of this kind of continuous real time processing with XX or low 1XX level microamp level power consumption at 10 to 50kHz or so sample service rates. I guess an external MSP430 or something in a whole different class of MCU might be able to do it but then a bigger C-M processor would often be needed for other aspects of the system I envisioned so overall the size / space of a multi-MCU solution was not so attractive.I looked at DSPs used in things like hearing aids and such but even those seemed to be either inadequate or marginal for the level of power consumption and capability, though I'm sure some ASIC ones could, the few COTS DSP solutions seemed marginal.So what platforms or tricks do you know of for processing truly real time mixed-signal streams at XX kHz rates and still running from battery power like a mobile device might?Are there MCUs or ADCs that I missed seeing that can do exceptional synchronous processing by either fine grained control of peripherals in sleep modes, fine grained clock / sleep control or so on?Also I wondered about oscillators, it seemed like there were only one or two (and not so available) oscillators specified for say 1-4MHz range operation while taking only say under 20uA current levels. There were plenty of low current 32kHz oscillators. And I did not notice anything like an external variable rate oscillator that could be (at very low power) switched between say XX kHz rates and X MHz rates which could be interesting if there actually was a MCU that could operate off such an external and variable frequency clock source. Ideally of course the internal LF / main MCU oscillator would have high dynamics of fast start / stop / frequency control but that did not seem to be the case with the MCUs I saw to the extent that the result would be XX or (1-2)XX uA level power consumption.Thanks in advance!

author: Someone
author_rank: Super Contributor
timestamp: December 18, 2016, 10:54:26 pm
content: Quote from: evb149 on December 18, 2016, 10:23:03 pmNot going to happen with continuous audio rates/resolutions, low power codecs are already blowing the power budget. An Atmel AVR can do the low power part but you'll have to put up with a low resolution ADC.Quote from: evb149 on December 18, 2016, 10:23:03 pmMobile devices have big batteries and short battery lives. Getting the processing duty cycle down and only waking to check periodically instead of continuous will save some power but it really depends on how sparse your application can be.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: December 18, 2016, 10:56:31 pm
content: Most "low power" MCUs are optimised for sleep/standby, and power draw for other operations will be very difficult to predict as there are so many variables.For what you are doing, it will be near-impossible to estimate power from the datasheet, except maybe get a maximum, and you'll just have to start building hardware or buying devboards and writing code.And for absolute minimum draw, there will be a lot of code-tweaking, and optimising of clock rates etc. - e.g. processing in parallel with conversion at a clock that's just enough to complete when teh next ADC result comes in.You might even find that an external ADC might be better, especially if it has a FIFO, as you may be able to do some sleeping inbetween bursts of processing.I'd be surprised if you'll get down to microamps for realtime audio.I've not used them but the dsPICs might be worth a look as they're optimised for signal processing - no idea about power though.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: December 18, 2016, 11:00:26 pm
content: It may be worth reading through some standalone ADC datasheets, as this will give you some idea as to what the lowest-possible current per ksps acheivable is without being complicated with the MCU part.If you can't find a standalone ADC at any price with the performance you want, it's not going to happen on an MCU

author: Jeroen3
author_rank: Super Contributor
timestamp: December 19, 2016, 08:35:40 am
content: Have you looked at Silabs? They've made some low power stuff. Their 8051 are super low power, compared to power hungry STM32's. However, less feature rich and easy to use.Their EFM32 might just be what you're looking for.51 µA/MHz sleep mode150 µA/MHz run mode with code executed from flash

author: janekm
author_rank: Unknown
timestamp: December 19, 2016, 09:26:50 am
content: The most important thing when using a Cortex-M chip is to ensure that as much peripheral "work" is being done independently in the background without waking up the core (same is true for most other MCUs, of course). So in your case it's crucial to use an MCU that can keep the ADC running in the background without having to wake up the MCU for each sample, DMA-ing the data to a buffer and only waking up the MCU once every n thousand samples or so.Depending on what kind of processing you want to do with the data after it's been sampled you'd also want to pick a Cortex-M4 for the DSP instructions.Two choices that I would recommend you look at are Nordic NRF52 and Silabs (former Energy Micro) EFM32. I'll talk about the NRF52 since I know it better.Your concern about SLEEP mode is true for some Cortex-M based designs where you have to separately instruct the power / clock peripherals to enter the appropriate sleep mode, but for example NRF52 can handle it all internally using the WFE (wait for event) instruction, giving a typical 1.5uA power consumption (not taking into account any active peripherals).In your case, you'd likely have to keep the 64MHz oscillator running for the ADC, if you use the RC oscillator that's 60uA. The ADC peripheral has an internal timer for continuous sampling so you may not need an active TIMER peripheral. The ADC can be configured to take up to 16384 samples independently without waking the core. ADC current during acquisition & conversion is 700uA. Minimal acquisition time is 3us per sample + 2us conversion time, so total 5us per sample best case (you may need an external opamp to reach that acquisition time). That means for 20kHz sample rate the ADC peripheral is active 1/10th of the time best case, so optimistically 70uA average consumption, total 120uA (but not taking into account actually doing anything with the data, which is a whole other story).NRF52 core has a run current of 3.3-6.7mA when running from RAM at 64MHz (depending on your supply voltage and whether you're using the DC/DC converter). You'd probably want to run from RAM to avoid any potential wait states when executing from flash. So when it comes to actually doing something with your data, it's going to run circles around an MSP430 or worse PIC or AVR.ADS7822 might look great at first glance, but you have to feed in an external clock (nice way to cheat to make the power consumption look better), so that means your MCU will still need to keep its oscillator running so staying with the example you'd still have the 50uA from the NRF52 oscillator (it won't be much better for other MCUs), plus the run current for the TIMER (5uA for NRF52 when run from 1MHz clock). And then there's the problem of how to get the data out over SPI without waking up the CPU core, which would get really tricky, and SPI peripheral run current on NRF52 is also 50uA so any potential gain is quickly eaten up here.So I think you'd struggle to reach less than around 150uA system current while sampling at 20kHz, it would need a very creative (and likely expensive) solution.Another thing I would recommend you look into, though, is if there's any way you could limit your sampling to when there's actually data of interest present. Maybe you could sample at 100Hz until a certain condition is met?

author: Brutte
author_rank: Frequent Contributor
timestamp: December 19, 2016, 12:09:32 pm
content: At 20kHz and with real time processing this means that you run the filtering algorithm at similar 20kHz rate, without jitter and delay. Of course it would be much easier to run 20kHz sampling with DMA for a second and then just wake up and do the processing of whole 20k samples in one chunk, once a second, but if your audio does not allow for longer delays, that won't work.So what is the allowable delay of your setup, from ADC S&H, to a processed output?

author: Jeroen3
author_rank: Super Contributor
timestamp: December 19, 2016, 12:37:28 pm
content: It'll be a challenge for the software, do you have any idea how much instructions you're going to need on an M0?

author: andyturk
author_rank: Frequent Contributor
timestamp: December 20, 2016, 12:36:26 am
content: Quote from: janekm on December 19, 2016, 09:26:50 amI was just reading up on this over the weekend. From some of the discussions on the Nordic forums, it seems that you also have to factor in the current draw of EasyDMA if you're going to use the SAADC that way. I.e., add another 1200uA to the estimate, even before any calculations done by the M4F.More details here:https://devzone.nordicsemi.com/question/69346/nrf52-saadc-current/

author: daybyter
author_rank: Frequent Contributor
timestamp: December 20, 2016, 07:49:08 am
content: Did you check the stm32L versions? Or maybe stm8L? They are designed for low-power operations.I am evaluating a similar scenario at the moment, but my problem is the consumption of sd card as the storage media. While the cpu might work at micro amps, it seems they still need more power like 100 ma. And it is hard to find good info on their power consumption.

author: janekm
author_rank: Unknown
timestamp: December 20, 2016, 09:28:07 am
content: Quote from: andyturk on December 20, 2016, 12:36:26 amThat is indeed disappointing, and pretty much rules out the NRF52 for this use case. Oh well.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: December 20, 2016, 11:36:51 am
content: STM32L versions are very good for some low power projects.I've already used it and, for my application, the STM32L0 was the best, but it was closely followed by the geckos (EFM32)!It's been a while and I can not remember the values ...

author: thmjpr
author_rank: Regular Contributor
timestamp: December 21, 2016, 04:40:08 am
content: Quote from: daybyter on December 20, 2016, 07:49:08 amI have some measurements here from a STM32L4 and microSD running in 1-bit mode at 12MHz, with clock power save disabled (clock always on).Current increase just from inserting the card is 60 to 88uA (sandisk, samsung, mixza 2-8GB).Write current shouldn't be that bad, from my research its ~20mA but I have yet to measure that. Even if it is that high, how much data are you writing out? If its not much, buffer for as long as possible, and write intermittently. You could switch power off to the card to eliminate quiescent current, but it wasn't worth it for me, and with clock disabled its got to be miniscule.

author: daybyter
author_rank: Frequent Contributor
timestamp: December 21, 2016, 10:20:19 pm
content: Problem is, that my power source is very limited. Even drawing 20 mA for fractions of a second might cause me trouble. I thought about using caps to buffer some energy, but than I need some circuit to charge those caps very slowly.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: December 22, 2016, 12:06:05 am
content: MicroSD cards will be variable and unpredictable. You also have to switch their power off if you want minimal standby drawIf you don't need the high capacity, SPI flash may be a better option.

author: thm_w
author_rank: Super Contributor
timestamp: December 22, 2016, 10:00:59 pm
content: Quote from: daybyter on December 21, 2016, 10:20:19 pmFor SPI flash in a SOIC8, you will be limited to about 16 or 32MB (eg W25Q128FVSIG). But read write on that specific chip is still quoted as 15/20mA, and 50uA standby.Maybe mike is aware of some lower power versions.How much space do you realistically need?Charging cap could be done with a resistor or single transistor current source, if the flash chip doesn't mind slow power on and you don't need to read it right after power up.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: December 23, 2016, 01:18:36 am
content: Quote from: thm_w on December 22, 2016, 10:00:59 pmStandby is tens of uA, but you can do a powerdown command to get it to a few uA or less. No significant time penalty going in/out of powerdown.Though power draw is significant, it will probably be for less time than sd, unless you need a lot of erases, and importantly it will be very predictable and consistent, more so than an sd card.

author: e100
author_rank: Frequent Contributor
timestamp: December 23, 2016, 04:44:25 am
content: Quote from: evb149 on December 18, 2016, 10:23:03 pmCan you steal some energy from the audio signal that you are digitising?

author: mrm2007
author_rank: Contributor
timestamp: December 25, 2016, 07:42:10 pm
content: Hi,I think you can use STM32L4 Series. Download STM32CubeMX. Select a MCU (For Example :STM32L476, Cortex-M4F) , In Power Consumption Tab , you can calculate power with Different options :For Example : STM32L476 (ADC @ 10KHz, FLASH, AHBs, DMAs, GPIOA, GPIOB , 1xSPI All Active)MODE= LOWPOWWER_RUN (Voltage 1.8~3.6V)Core Clock = 400KHz ==> Estimated Current <125uACore Clock =1MHZ ==> Estimated Current <215uAADC=1MSPSCore Clock = 400KHz ==> Estimated Current <295uACore Clock =1MHZ ==> Estimated Current <385uAcheck different STM32L Families.(Except ST32L1xx, Their ADC Requires around 1 ma , but it's more flexible)

author: autobot
author_rank: Regular Contributor
timestamp: December 28, 2016, 08:30:16 pm
content: One of the lowesst power mcu on the market is from ambiq micro , it's a cortex-m4, including floating point, uses <10ua/mhz.[1[http://ambiqmicro.com/apollo-ultra-low-power-mcu/apollo2-mcu/

author: coppice
author_rank: Super Contributor
timestamp: December 28, 2016, 09:40:33 pm
content: Quote from: autobot on December 28, 2016, 08:30:16 pmThe Ambiq devices look interesting, but they don't seem to be creating a lot of buzz around their products. The Apollo 2 is very new, but the Apollo 1 was launched a couple of years ago. Has anyone here tried them?

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: December 29, 2016, 01:11:15 am
content: Quote from: coppice on December 28, 2016, 09:40:33 pmLooks like they've yet to realise that they need to be in Digikey/Mouser etc. to be taken more seriously...and put the datasheets on their website.

author: Jeroen3
author_rank: Super Contributor
timestamp: December 29, 2016, 06:46:15 am
content: If you have to ask them for prices and documents there will be a catch.I think they basically run the chip at ultra low voltages and include some level translators on the edges. It includes a dc/dc converter to which you have to hook up some external inductors.

author: Howardlong
author_rank: Super Contributor
timestamp: December 29, 2016, 07:05:47 am
content: Thinking a bit more out of the box, the TLV320AIC3254 is a CODEC that includes a fair bit of programmable DSP processing on chip. I haven't used this in new designs for a couple of years, so there may be other options now.Trying to do any real time DSP on any MCU at audio rates will be in mA, not uA I'm afraid.I am currently working on two projects in single digit and sub uA using nanowatt XLP Microchip parts. It is exceptionally hard to design anything that actually does something useful that even approaches the datasheet figures, so take those datasheet figures with a grain of salt, the devil is in the detail, and I would highly recommend prototyping before committing to a device. Those DS figures often seem to be in the unicorn league of reality.