Hi, STMicroelectronics has announced a new 32-bit ultra-low-power microcontroller named STM32L0. The MCU is based on a Cortex-M0+ core and show only 400nA power consumption with full Ram retention in stop mode (with fastwakeup time 3.5us). On top of that the ecosystem of STM32 is now really cool with Discosvery kit, Nucleo kit, CUbeMX toolset, Mbed compatible ...
I am seriously considering doing my own comparison test--an all out brawl--of MCUs that manufactures' are claiming to have "The industries lowest Power MCU". I plan to create three typical Low power applications and then optimizing to each processor and comparing their power performance. So far in my list of possible MCUs are:
Does anyone know if anyone else has done this? Does anyone else have a MCU they would suggest?
The challenge with power or energy optimization is that it depends on so many factors which are inter-related. As Taquino points out, it is hard to get the answers to all of these without doing design and prototyping on each target architecture.
I’m using the RL78/G13 in my graduate-level embedded class this semester at NC State University. (Disclosure: I wrote a textbook on the RL78 for Renesas). For the final project I let students choose their topic, and one option I pushed was benchmarking speed, power and energy for the RL78/G13 against the student’s favorite MCU. The RL78 has some very nice power and energy optimization features and numbers, and I wanted to get some datapoints about how effective they are in some sample applications. We had just had an energy optimization project (maximizing stopwatch run-time using a supercap for power) and a speed optimization project (bouncing graphics on an LCD).
I put in a caveat: They had to compare against the other processor using optimized implementations on each. Otherwise the resulting numbers are hard to believe. Sadly, none of the 91 students chose this option. So much for my crowdsourcing experiment! OTOH I believe that all 91 students now understand how hard it is to really compare the MCUs without building prototypes.
Which current dominates depends on the system design and MCU activity profile. The MCU power and energy use may be a small fraction of total system’s use. External constraints can make MCU current differences irrelevant.
Test conditions differ across manufacturers, so the reader must estimate to normalize all the performance numbers, introducing error.
How long will the MCU be idle? How many compute cycles are required? How long does the MCU take to wake up? Can the MCU avoid executing code? Is it possible to link peripherals together with hardware triggers?
Is the compiler producing good object code or not? There’s a surprising amount of variability. The list goes on…
On Microcontroller Central we have been talking about the possibility of the industry creating a benchmark for measuring power in the wake-act-sleep kind of activity that wireless sensor networks and numerous other applications require. Check out the discussion at http://www.microcontrollercentral.com/author.asp?section_id=1741&doc_id=242506& and feel free to add your thoughts.
aqua_man, Marius thank you for the suggestions. I haven't looked at Cyrpresses offerings, but will take a look.
As for processor selection, my group wanted to go with a single class of processor for various products and settled on ARM. That narrowed us to peripheral selection (LCD, USB, 2 I2C buses, 2 SPI busses and several timers and GPIO). After that we needed to be sure we could achieve our power budget (90 days of operation under 60mAh) We run at a sub 50Hz sample rate.
I selected and am currently targeting an EFM32LG (development is preceding on a EFM32GG). The wake up time, power/performance balance and peripheral availability in sleep modes pushed us toward it.
For purposes of this discussion I just wanted to point out that I found it very hard to select a processor purely from the data sheet. It wasn't until we had a rough design that we could select the features that could be exploited for power savings. The design has to be crafted to each processor to evaluate it objectively.
For instance, we had thought that we would be able to take advantage of the PRS (peripheral reflex system) but found that our application did not lend itself to its use. We abandoned that approach, since any savings would have been lost in the cost of configuring the system. In an application where data is collected at a higher rate, this would have made sense.
I've found that, as Cooltechguy points out, something like uA/DMIPS and DMIPS/MHz are much better indicators of final power usage when comparing 8, 16 and 32 bit architectures and even different offerings for a single vendor. Going from the PIC16Lf726 to PIC16Lf1938 for another project dropped our power usage by about 10%. That was simply a matter of changing a few names and compiling for a new target (cost delta = $0.13 per unit).
I would also recommend that you take a look at the EFM32 from Energy Micro, especially the EFM32TG series.It has a 900nA sleep mode with RTC, and 20nA in power down, in addition to a 150uA/MHz current when running code on the 32 bit Cortex M3. This processor has a much higher performance per clock than the 8-bit and 16 bit processors you are currently comparing against.
t.alex: I agree totally. Parts should be evaluated for what they will eventually end up doing in a system design. Variations will always exist between what is published and what is designed in. The proof is in the pudding, and that is what distinguishes a system engineer from a parts buyer.
I highly recommend you look at Cypress PSoC 3 family. The PSoC does a lot of work in digital and analog blocks while the MCU sleeps. Integrating the logic and analog from the board into the IC provides the lowest overall system power and cost. I've built products on PSoC in far less time than PIC and TI that were smaller and cheaper. PSoC has 1uA sleep and 200nA hibernate.
Check out their table http://www.cypress.com/?id=2232&rID=44224
A Book For All Reasons Bernard Cole1 Comment Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...