This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

how to decide low power MCU btw MSP and ARM?

-MSP430F5419A datasheet(http://www.ti.com/lit/ds/symlink/msp430f5419a.pdf) provides typical power consumption as 230uA/Mhz and on page 42 it shows max value as 960uA/Mhz @ 25Mhz 

-EFM32G222 (http://www.silabs.com/Support%20Documents/TechnicalDocs/EFM32G222.pdf) which has ARM cortex M3, shows power consumption as 180µA/ MHz and on page 10 it shows current consumption as 235µA/ MHz @ 28Mhz

since ARM is 32 bit ,does it mean that EFM32G222 is low power compared to many of MSP430 series MCU's ?

-Both MCU's show thes stats @3.0V only and @ Run or Active mode and code executed from Flash. so,Is my comparision fair or am I totally wrong, Please correct me?

Thank You. 

  • thanks for the link. I donno why many people say that  MSP's are the lowest power is it due to voltage(MSP=3.6max and ARM=3.8max) 

    In both the data sheets on page 42 in MSP and page 10 in ARM the current consumption values are weird.

    If we observe the MSP datasheet(pg 42) it shows current consumption increases(35 to 960 uA) from 1Mhz to 25 Mhz.

    where as in EFM32G222 datasheet(arm)(pg 10) it shows current consumption decreases(220 to 180 uA) from 1.2Mhz to 32Mhz.

    how can current consumption increase in one and decrease in other MCU when frequency increases. usually when frequency increases current consumption increases(AFAIK).

  • karthik a said:
    -MSP430F5419A provides typical power consumption as 230uA/Mhz and on page 42 it shows max value as 960uA/Mhz @ 25Mhz
    -EFM32G222 which has ARM cortex M3, shows power consumption as 180µA/ MHz and on page 10 it shows current consumption as 235µA/ MHz @ 28Mhz

    That's the problem with one-dimensional values in those comparisons. The look good for one single point on the whole scale of operating conditions. And the marketing dept. of course picks this point for "proving" how good their product is.

    On 100Mph, the Wankel-motor-driven Mazda RX-7 surely consumes less gallons (<2) per 100miles than my Fiat Panda (>3).
    But inside a city, below 30Mph and with lots of start and stop, where I use my Fiat most, it consumes only 1/3 (<2)of what the Mazda requires (>4). And fits in the smallest parking lots.

    The key advantage of the MSP series is not the low power consumption at full speed, but the way more than just linear decrease of the required power when you do NOT require full speed. Which in embedded applications is true for 99% of the time. MSP delivers good CPU power at a reasonable cost when you need it, and excels in reducing power requirements when you don't need it.

    If you need the CPU running @28MHz 24/7, the ARM is surely the better choice regarding power consumption. Nobody will deny that.
    But usually, it's not just that. The MSPs flexible clock system makes things easier (and cheaper), its ability to shut off everythign not needed, including its variuos peripherals, makes it excel when you only need short periods of CPu activity and are waiting most of the time. I surely won't have an ARM in my TV remote. I'd have to recharge it every day. And I won't like to have an MSP in a smart phone.

  • I've recently had to switch from MSP to another uC (I've started (in fact was ending-70%) the devel on MSP FR5). I choose the STM8L152C8U6, which is not as low power as MSP, have a look a those series they have some interesting features, of course everything depend on what you want to do.

    For low power application,  the Renesas RL78 are even lower power (down to 46uA/Mhz) but I haven't used thoses devices, they are only too big package for my application.

    The MSP430 standard series is not the lowest power from some years, every manufacturer has it own competitors. The cortex M0 has higher performance with (globally) lower cost (EnergyMicro aren't), the STM8L is way cheaper, and so on... Every application has it's own chip, but I think the future of MSP430 will be very hard.

    "where as in EFM32G222 datasheet(arm)(pg 10) it shows current consumption decreases(220 to 180 uA) from 1.2Mhz to 32Mhz"

    Microcontrollers have a static power consumption, which is not related to the running frequency and a dynamic which is related to frequency. The number depends on how the calculation is done.

    STM8L has a dynamic of 220uA/Mhz and a static of 330uA, which represents 550uA @ 1Mhz and 3850@16Mhz which is 240uA/Mhz at this frequency, way lower thant the 550uA/Mhz@1Mhz.

  • Argail said:
    For low power application,  the Renesas RL78 are even lower power (down to 46uA/Mhz) but I haven't used thoses devices, they are only too big package for my application.

    Another thing that should be considered: how much work is done per CPU clock cycle? On MSP430, all register/register operations only require 1 MCLK cycle. Most other CPUs require more (at least two), doubling the required MHz for the same job, which also doubles the power consumption for the job.

  • We can take into account that the MSP has no divider and the multiplier is only available on some devices, this could do a difference too, and how many single cycle instruction with MSP430 are done in a firmware?

    It's always the same thing and the same mystery when it comes to architecture design, it fully depends on implementation and application.

    I spare a lot of power because I use DMA, and the main point of my application is byte communication where 8bit stm core is not a limitation. For the same price the STM with DMA will consume less than MSP430 (there is DMA on some MSP but I said "for the same price") even if on paper the STM is less optimized.

    When it comes to small uC like the ones we are speaking, they often are is sleep mode for 99% of time, so the small differences in active mode is only good on paper.

    Anyway, what if often underestimated is the code optimization itself, and this is can be a major difference.

    For my own experiences, I never had the input to do the device with the longest autonomy, I always specified with a minimal lifetime. This things should be ON for 3 years, it doesn't not matter is it is on for 3.5 year, it's a bonus but no relevant against competitors on the market. And there is only limited coin battery cell selection, we are speaking about 10/20mAh difference over the entire products life and this difference do not let to use another battery to spare money/place. Between those uC there is not the same gap between a standard MSP and a Wolverine one, which draw 4 to 5 times less power and let to choose a battery 4-5 times smaller.

    For conclusion, go with the one you have rather;) If you have none, go with the simplest architecture, so you have more time to optimize your code instead of loosing time playing with weird peripherals. But again, this is only my small experience with specific projects.

  • Argail said:
    We can take into account that the MSP has no divider

    How often do you need to divide? Sure, if you program an MCU like a PC...

    Argail said:
    and the multiplier is only available on some devices

    Most of them. And if you don't need it...

    Argail said:
    and how many single cycle instruction with MSP430 are done in a firmware?

    You'd be surprised. Lots. And more. Due to the orthogonal structure of the MSP, there's more than just a saved cycle here and there. Everything that works with registers is faster than with most other CPU types. Not to mention the constant generator (also a zero overhead register operation).

    Argail said:
    it fully depends on implementation and application.

    Exactly. I have seen people doing things where even the most efficient CPU will drain its supply where the task could have been done without CPU work at all. If one is doing bit-banging I2C because he's not smart enough to make the hardware I2C work, then low-power considerations for this project are rather futile -  and a different CPU won't make a change.

    But you're right, too often, the differences are in the "don't care" range. Like with PCs. While this or that manufacturer claims to have the faster CPU , it is known that 10% more speed are barely noticable (except if doing time-consuming calculations) and do not justify any higher price. Same for MCUs: unless the advantage crosses a critical border between 'sufficient' and 'not sufficient', it makes no sense moving from a known and tested platform to a different, slightly better one.
    If you start from scratch, things might be different.

    Argail said:
    For conclusion, go with the one you have rather;)

    Or what you already know. Learning to master a new CPU type takes time, which usually isn't available. And the better CPU in the hands of a non-experienced person won't bring any advantage at best (and lead to failure at worst)

    Argail said:
    If you have none, go with the simplest architecture, so you have more time to optimize your code instead of loosing time playing with weird peripherals

    Depends. Even the best code cannot compete with dedicated hardware support. Even though people tend to do everything in software - and demand bigger, less power-consuming processor then. :)

  • "as 230uA/Mhz and on page 42 it shows max value as 960uA/Mhz @ 25Mhz "

    sorry for the mistake actually it is 9.6mA @25Mhz, so 9.6/25 is 384uA/Mhz which is still higher than ARM's 235uA/Mhz..

    Thank you for the replies

  • karthik a said:
    so 9.6/25 is 384uA/Mhz which is still higher than ARM's 235uA/Mhz..

    That's maximum, not typical (or even minimum found on selected devices). And for execution from flash. Execution from ram is only half of it.
    It also includes the operating current for the clock generation with DCO and a watch crystal (which is usually excluded on the competitor's data).
    Digging deeper, the DCO apparently consumes 83µA @1MHz. (LPM0 to LPM2 difference) I guess if you clock the MSP with an external oscillator instead of the internal circuitry, you'll spare these 83µA/MHz too (maybe more on higher frequencies and not linearly increasing).

    On 8MHz, you're at 230µA/MHz too.(110µA for RAM execution). Minus DCO operating current.

  • Jens-Michael Gross said:
    For conclusion, go with the one you have rather;)

    Or what you already know. Learning to master a new CPU type takes time, which usually isn't available. And the better CPU in the hands of a non-experienced person won't bring any advantage at best (and lead to failure at worst)[/quote]

    Agree. Engineers talking about "what's best hardware" often forget about economics or just ignore it. If I need to manufacture 100 devices per year then 10% of price or power consumption difference usually are in "does not matter" category but saving on development costs is most important. On the other hand I would change my approach completely if expected manufacturing volume is for example 10000 or more. Then game changes completely

  • Ilmars said:
    On the other hand I would change my approach completely if expected manufacturing volume is for example 10000 or more. Then game changes completely

    Unfortunately, the usual requirements for the 10k volume are "drop cost and development time". It's often easier to pretend costs can't be dropped than to explain why development time can't be reduced. :)
    Also, it is usually more important to release the new devices ASAP than to provide a product that makes optimum use of energy. Usually, everything that is to expect to live longer than the warranty time is acceptable. Being second on the marked is not.

  • Jens-Michael Gross said:
    Being second on the marked is not.

    Second to release product or second in product features like battery life or cost? It depends on what kind of product actually it is. What if you simply can't be first to release particular type of product because it exists for decades? What if uC price is significant part of total cost and scope of development is instead - insignificant?

    Most probably you talk about companies having few developers knowing just single microcontroller. They usually do not manufacture in "10000 or more" quantities. They better work on products with lot of added value so hardware-associated costs are small fraction of product final price. Then for final product it is more or less in "don't care" department which exactly microcontroller to use - just stick to one you know or even better - have in stock already :D

  • > I guess if you clock the MSP with an external oscillator instead of the internal circuitry, you'll spare these 83µA/MHz too 

    Maybe. It's easy to forget that moving a power hog out of the MCU doesn't make it disappear. The whole circuit counts. Last I looked (admittedly some time ago) standalone oscillator units were significant (multi-mA) power hogs in themselves, and not fine-tunable (much less on-the-fly) the way the DCO is.

  • Usually low power application is based on a simple procedure:

    Sleep, wake up and run as fast as you (I fact with the best current/frequency) ratio can during the smallest time, and go back to sleep.

    Having an external high speed clock takes much times to be stable, time during uC can't works and draw a lot of power to start the system, more of that, starting  a crystal is a procedure not safe at all.

    More of that external crystal power consumption isn't negligible (hundredthS of uA), but need to measure it on a real circuit.

    External oscillator scales near the mA.

  • Bruce McKenney47378 said:
    Maybe. It's easy to forget that moving a power hog out of the MCU doesn't make it disappear.

    That's right, but they disappear form the datasheet and the comparison table, giving the marketing (bogus) ammunition.

    Bruce McKenney47378 said:
    standalone oscillator units were significant (multi-mA) power hogs

    Too true.

    Bruce McKenney47378 said:
    and not fine-tunable (much less on-the-fly) the way the DCO is.

    Most MCUs don't have anything near the DCO. ATMegas have an internal R/C oscillator and also oscillation circuits for external crystals, but require the clock selection made during programming (a 'fuse' defines how the CPU core is clocked)
    The PICs I used didn*t have anything at all - they required an external resonator/crystal or R/C components (external R/X oscillator). Or one fixed 4MHz internal oscillator. Not to mention that one instruction takes 4 oscillator cycles each. Giving a good µA/Mhz ratio but a bad nAs/instruction ratio. Also, configuration has to be done at programming time too. No flexible "use when required, shut down while not" operation like with the MSP.

**Attention** This is a public forum