Microcontroller power drain

[Paul Rubin]

Seems like everyone claims their cpu uses less power than the other guy,
but hardly anyone puts up any actual numbers. When they do, it's bogus
numbers rather than anything (it seems to me) that a designer can use.
Is there a reason for that?

For example, the ARM Cortex M0+ claims to be the most efficient (I guess
beating the MSP430), but it turns out you have to use a bunch of
intricate power control operations to put the cpu to sleep most of the
time, to get it to actually use less power than an MSP430 doing a
comparable amount of computing. The M0+ is a 32-bit cpu running at a
higher clock fequency than the 16-bit MSP430 and will apparently use
much more power with both running at maximum. I wonder if it's possible
to underclock the M0+ (run it at speed comparable to MSP430, like 8 mhz)
to decrease power and not have to mess with special modes.

Any idea where to find real numbers?

Disclaimer: I'm a software guy and my hardware questions may not always
be sensible.

Thanks.

http://hackaday.com/2011/04/09/how-low-can-you-go/ has some actual numbers.

[David Brown]

The key to low-power design is usually keeping a low /average/ power.
And the key to that is to be in the deepest sleep possible, for the
highest percentage of the time. So you typically want to wake up (in
response to some event), run at the highest possible speed to do the
job, then get back to sleep as soon as possible. Thus you are better
off running your M0+ at 40 MHz for 1 ms per second, rather than 8 MHz
for 5 ms per second to do the same job.

Of course, there are different requirements for different applications,
and sometimes peak power is more important than average power, and you
have to be able to turn off the high speed clock while sleeping.

See <http://www.energymicro.com/> for some information and ideas.

[Niklas Holsti]

Really? I may not be up to date, but as I understand it, the
conventional wisdom a few years ago was that a given amount of
computation would use less energy if done at a lower speed, because then
one could use a lower supply voltage, too. There was work on, for
example, setting the clock frequency and supply voltage to make a given
computation finish just on time (by the deadline), rather than early.

Perhaps current processors run at minimum voltages already? Or perhaps
other parts of the chip consume so much constant-drain or leakage power
(when not in deep sleep) that the power spent on the real computation is
not dominant?

(I'm not protesting, just trying to update my understanding.)

--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .

[Paul Rubin]

David Brown <da...@westcontrol.removethisbit.com> writes:
> The key to low-power design is usually keeping a low /average/ power...

> See <http://www.energymicro.com/> for some information and ideas.

Thanks for the good general advice. I spent a while looking around that
site and as with the others, I couldn't find any actual power
consumption numbers. The (maybe wrong) way I look at this is:

1) assume I'm using a commodity board like the TI Launchpad, Freescale
Freedom, etc. The hardware designer has no control over the software,
and therefore has to be able to say: what is the most power this board
can possibly draw, assuming the software does whatever it can to max out
everything? I found a blog post a while back where someone ran a busy
loop on a Launchpad and measured the current draw with a milliammeter.
That seems like an obvious thing to ask, but it's the type of number I
don't seem to be able to find in any spec sheets.

2) assume I'm writing the code for a circuit that's made in low enough
quantity that the unit price of the parts isn't important within reason
(the programming effort is much more expensive). If I'm very very
careful and willing to spend a lot of time optimizing and debugging, I
can probably get the thing to run in an M0+ with its 4k of ram. It
would sure be more convenient if I can use an M3 or M4 which has much
more resources, so I can program at a higher level (or some might say
sloppily). But how much more power is that going to cost? Again, I
can't find any numbers.

[David Brown]

Protest if you want - it's quite possible that I've got things wrong
here, and will hopefully be corrected by others :)


Roughly speaking, the power consumption is proportional to V琊f (with
perfectly efficient switch mode power supplies, etc.). So if you can
lower the voltage, that is definitely a good thing even if it reduces
the maximum frequency.

But at a given fixed voltage, we have power (or current) proportional to
frequency. That means it takes the same energy to do a calculation
whether it is at a high frequency and short duration, or low frequency
and long duration (obviously assuming a high enough frequency to do the
job). So the energy used for the calculations (and therefore average
power consumption) by the cpu core is the same regardless of the clock
speed. But while the cpu core is active, so is a lot of the rest of the
chip - oscillators, memories, timers, etc., whose current consumption is
less frequency dependant. When you can get into deep sleep and turn off
a lot of these parts, you gain overall. Thus the aim of a
short-duration high-speed wake period is more to reduce the average
current of the rest of the system than for the cpu core itself.

[Richard Damon]

The biggest problem with getting a worse case power consumption is that
it really is a lot of work to figure out what the absolute worse case
would be. Executing different sequences of instructions will consume
somewhat differing amount of power (based largely on how much of the
chip is getting exercised). Then you get the problem that will a company
really spend much time (and money) to finds ways to be able to advertise
a worse spec for their part. This absolute worse case number is likely
to come from some code sequence that is very unlikely to actually occur
in real life, so it also isn't really useful to the users. Most boards
will be speced with what power you need to supply to the board to make
it run, which may not be a real accurate number, but is what most people
really need.

[Paul Rubin]

Richard Damon <news.x.ri...@xoxy.net> writes:
> The biggest problem with getting a worse case power consumption is that
> it really is a lot of work to figure out what the absolute worse case

> would be.... This absolute worse case number is likely

> to come from some code sequence that is very unlikely to actually occur
> in real life, so it also isn't really useful to the users.

OK, fair enough. Let's just take a simple real-world use case then. I
want to digitally filter some signal which to first approximation means
a simple multiply-accumulate loop. It would sure be nice to know how
much power that would take. But it seems very hard to find this number
short of buying a bunch of different boards, porting code to each of
them, and measuring the current draw. Is this something that actual
designers don't care about? In the world of desktop and server cpu's
(closer to what I'm used to), the number of watts consumed by a cpu is
usually written right in the description, e.g.:

http://www.newegg.com/Product/Product.aspx?Item=N82E16819116501

but it doesn't seem to be that way for these embedded cpu's, even when
they advertise themelves as ultra low-power.

[Tim Wescott]

It's a harder number to pin down, and subject to many variables. So the
marketing guys (who don't necessarily understand the technical issues)
play specsmanship games.

The MPS430 guys actually had the right idea a long time ago, and for a
while they were pushing it. It's what David was saying: if you want the
least _average_ power consumption, then you need minimize the amount of
energy that it takes to do whatever your periodic computation is.

The MPS430 guys latched onto this, and made their chip so that it had a
deep sleep mode that used a hair more power than the competition, but
that used fewer micro Joules to come out of deep sleep, then got the job
done at speed with less micro Joules before it fluffed up the pillow and
snoozed again. Since then I think at least some of the microprocessor
manufacturers have woken up (so to speak) and tried to do some of the
same things.

So: you need to calculate this, and you probably need to buy a few
example boards and do some measurements. If you're really doing signal
processing, you may find that your best bets are either the smallest
Cortex M4 that you can find, or a fixed-point DSP chip, because even if
the core current consumption is higher, you'll be out of sleep mode for
less time.

Go to the data sheet. Look for these numbers:

1: how much current in deep sleep.
2: how much current "at speed"
3: how long does it take to wake
4: instruction cycle count estimates

Use (4) to estimate how long it'll have to stay awake each time once it's
awake. Then that, with the information from (2) and (3) should let you
estimate the energy consumed per waking event. Basically the times you
get from (3) and (4), times the current you get from (2), times the
chip's running voltage, should give you a number in Joules. Multiplying
that by the frequency of the wake-up, and you should end up with an
average power.

I don't think you'll ever get close to the minimum with an evaluation
board, unless it's one that's specifically designed to puff off a micro's
low power consumption. (There were some MPS430 boards that did just
this; I can't speak to whether anyone's done it with a Cortex-cored part).

This also means that if you really want to attain the absolute minimum
power consumption that you're going to need to design a board
specifically for your task.

I also don't think that you should think in terms of a Cortex M0 or a
Cortex M4, etc. -- yes, the core means something, and ARM will have
designed for power consumption. But you're not buying a naked core,
you're buying a whole chip from ST or TI or NXP, and the way that the
rest of the chip is designed, and even (I'm willing to believe) the way
that the core is implemented is going to affect the power consumption.

--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

[Vladimir Vassilevsky]

"Paul Rubin" <no.e...@nospam.invalid> wrote:

> OK, fair enough. Let's just take a simple real-world use case then. I
> want to digitally filter some signal which to first approximation means
> a simple multiply-accumulate loop. It would sure be nice to know how
> much power that would take.

If the workload is considerable, then power consumption is going to be
pretty much same for all MCUs of the same class.
The difference could be significant only in the special scenarios. Such as
very low workload where the idle consumption matters. Or utilizing advantage
of a peripheral specifically fit for the job.

> But it seems very hard to find this number
> short of buying a bunch of different boards, porting code to each of
> them, and measuring the current draw. Is this something that actual
> designers don't care about?

There is no point.

> In the world of desktop and server cpu's
> (closer to what I'm used to), the number of watts consumed by a cpu is
> usually written right in the description, e.g.:
>
> http://www.newegg.com/Product/Product.aspx?Item=N82E16819116501
>
> but it doesn't seem to be that way for these embedded cpu's, even when
> they advertise themelves as ultra low-power.

Read datasheets. There is power breakdown for different MCU subsystems. You
can get ballpark estimate.


Vladimir Vassilevsky
DSP and Mixed Signal Consultant
www.abvolt.com

[Richard Damon]

On 2/1/13 8:10 AM, David Brown wrote:

> But at a given fixed voltage, we have power (or current) proportional to
> frequency. That means it takes the same energy to do a calculation
> whether it is at a high frequency and short duration, or low frequency
> and long duration (obviously assuming a high enough frequency to do the
> job). So the energy used for the calculations (and therefore average
> power consumption) by the cpu core is the same regardless of the clock
> speed. But while the cpu core is active, so is a lot of the rest of the
> chip - oscillators, memories, timers, etc., whose current consumption is
> less frequency dependant. When you can get into deep sleep and turn off
> a lot of these parts, you gain overall. Thus the aim of a
> short-duration high-speed wake period is more to reduce the average
> current of the rest of the system than for the cpu core itself.
>
>

Actually, memories, timers, etc tend to be very frequency dependent in
their power consumption, as most power is spent moving charge on
clock/data transitions (just like the core). I find that often I do
better with a slower clock rate for power consumption. The math working
something like this:

You have a choice of doing N units of work in 1 unit of time, or N units
of work at 1/N the clock rate in N units of time. Both of these options
will consume similar energy. For the faster mode, you now need to sleep
for N-1 units of time. Sleeping does cost some energy, and going in and
out of sleep also tends to cost energy, so you really do want to
minimize the number of times you go into a deep sleep (when you are
expecting a longer period of inactivity it make sense, but not for
shorter periods). For shorter periods of inactivity there are often
light sleep modes that don't power down things but stop/greatly slow
down the clock to large parts of the system, which can often be switched
back fairly quickly with little loss of power for the transition, and in
the no/slow clock period power draw is greatly reduced.

The second advantage of slower processing, is for some parts, it may be
possible to reduce the supply voltage at reduced clock rates, which will
greatly improve power savings.

The limiting factor for dropping clock rate will be needing to get the
work done in the time allowed, and any latency requirements on the system.

As with many things, the specifics make all the difference. There well
could be processors that do use less power when run in quick bursts
followed by deep sleeping.

I suppose my preference may be due to the fact that I normally can't
just put the whole system to sleep, needing the I/O system active to
keep looking for events from the outside that needs handling.

[Waldek Hebisch]

Paul Rubin <no.e...@nospam.invalid> wrote:
> David Brown <da...@westcontrol.removethisbit.com> writes:
> > The key to low-power design is usually keeping a low /average/ power...
> > See <http://www.energymicro.com/> for some information and ideas.
>
> Thanks for the good general advice. I spent a while looking around that
> site and as with the others, I couldn't find any actual power
> consumption numbers. The (maybe wrong) way I look at this is:
>
> 1) assume I'm using a commodity board like the TI Launchpad, Freescale
> Freedom, etc. The hardware designer has no control over the software,
> and therefore has to be able to say: what is the most power this board
> can possibly draw, assuming the software does whatever it can to max out
> everything? I found a blog post a while back where someone ran a busy
> loop on a Launchpad and measured the current draw with a milliammeter.
> That seems like an obvious thing to ask, but it's the type of number I
> don't seem to be able to find in any spec sheets.
>

Have you looked at MSP430G2x53 datasheet? They have a lot of
tables/charts giving you current consumption under various
conditions. Chart on page 22 says that active CPU on
TI Launchpad should draw slightly less than 5 mA. Of course
You need to count peripherials too. On Launchpad the biggest
current consumers are probaly LED-s -- from the schematics
it seems that one will take abut 6mA, other 3mA. Datasheet
contains info about low power modes which allow you to
deduce how much current is used by oscilators. There is
info abut current used by temperature sensor. I find no
info about UART/SPI/I2C/ADC and comparator. My guess it
that at max frequency this probably can match CPU (IIRC
for other processors I saw data with peripherisls on/off
and current use of peripherials was comparable to CPU
current).

I did not measure how datasheet info relates to actual
use...

--
Waldek Hebisch
heb...@math.uni.wroc.pl

[David Brown]

Some microcontroller manufacturers provide tools that can help with
power estimations, and perhaps give more accurate figures than you get
from the datasheets alone. For example, Energy Micros have such tools
(I have never used them myself, so I can't comment on their quality).

You also want to think about the work you are doing in the calculations,
and how well the cpu suits them. An M4 might take more power per clock
cycle than an M0 core - but it will do a FIR-filter in far fewer clock
cycles (if coded well) due to the DSP instructions.

[David Brown]

On 02/02/13 05:08, Richard Damon wrote:
> On 2/1/13 8:10 AM, David Brown wrote:
>
>> But at a given fixed voltage, we have power (or current) proportional to
>> frequency. That means it takes the same energy to do a calculation
>> whether it is at a high frequency and short duration, or low frequency
>> and long duration (obviously assuming a high enough frequency to do the
>> job). So the energy used for the calculations (and therefore average
>> power consumption) by the cpu core is the same regardless of the clock
>> speed. But while the cpu core is active, so is a lot of the rest of the
>> chip - oscillators, memories, timers, etc., whose current consumption is
>> less frequency dependant. When you can get into deep sleep and turn off
>> a lot of these parts, you gain overall. Thus the aim of a
>> short-duration high-speed wake period is more to reduce the average
>> current of the rest of the system than for the cpu core itself.
>>
>>
>
> Actually, memories, timers, etc tend to be very frequency dependent in
> their power consumption, as most power is spent moving charge on
> clock/data transitions (just like the core).

The key issue here is that there are two power figures that are relevant
- static power, and dynamic power. Dynamic power is (normally)
frequency dependent for cpus, timers, memories, etc., and also for
analogue parts. Static power is pretty much independent of frequency
(though it is dependent on voltage). You save static power by turning
off or deep-sleeping modules entirely. So the dynamic power required to
read a block of data from a memory is much the same at any frequency -
you can have a higher power for a shorter time, or a lower power for a
longer time - but doing the work in a shorter time means longer times in
deep sleep with much of the circuitry disabled, and lower static power.

> I find that often I do
> better with a slower clock rate for power consumption. The math working
> something like this:
>
> You have a choice of doing N units of work in 1 unit of time, or N units
> of work at 1/N the clock rate in N units of time. Both of these options
> will consume similar energy. For the faster mode, you now need to sleep
> for N-1 units of time. Sleeping does cost some energy, and going in and
> out of sleep also tends to cost energy, so you really do want to
> minimize the number of times you go into a deep sleep (when you are
> expecting a longer period of inactivity it make sense, but not for
> shorter periods). For shorter periods of inactivity there are often
> light sleep modes that don't power down things but stop/greatly slow
> down the clock to large parts of the system, which can often be switched
> back fairly quickly with little loss of power for the transition, and in
> the no/slow clock period power draw is greatly reduced.

You certainly need to take into account things like wake-up delays and
the costs of transitions. And if you already need your main clocks
running, such as for driving a UART receiver, then there is less to gain
by sleeping, and you might just as well run the cpu at a lower
frequency. There are no fixed answers here - just general guidelines.

>
> The second advantage of slower processing, is for some parts, it may be
> possible to reduce the supply voltage at reduced clock rates, which will
> greatly improve power savings.
>

That's absolutely true (and mentioned earlier).

> The limiting factor for dropping clock rate will be needing to get the
> work done in the time allowed, and any latency requirements on the
system.
>
> As with many things, the specifics make all the difference. There well
> could be processors that do use less power when run in quick bursts
> followed by deep sleeping.
>
> I suppose my preference may be due to the fact that I normally can't
> just put the whole system to sleep, needing the I/O system active to
> keep looking for events from the outside that needs handling.
>

Yes, it depends on the system, and on the features of the
microcontroller in question. Some micros let you keep I/O systems alive
even in deep sleep, others require the main clock system to be running
if you still want to react to some events.

[Paul Rubin]

David Brown <david...@removethis.hesbynett.no> writes:
> you can have a higher power for a shorter time, or a lower power for a
> longer time - but doing the work in a shorter time means longer times
> in deep sleep with much of the circuitry disabled, and lower static
> power.

There is another issue too, which is that power management is
traditionally rather complex to program. Using a 5 mhz clock running
steadily can give simpler software than a 100 mhz clock jumping in and
out of sleep modes, even if the total energy consumption is a smidge
higher.

One circuit I'm thinking of basically will run an RTC and listen to a
few pushbuttons, only occasionally doing something when someone pushes a
button, so its computational requirement is small. But it has to run
for 5+ years on battery power, so I need a good power estimate to
conservatiely decide how big a battery pack to use.

I guess the typical fancy digital wristwatch uses an 8-bitter clocked at
32 khz? Maybe I can use something like that.

[David Brown]

On 03/02/13 20:32, Paul Rubin wrote:
> David Brown <david...@removethis.hesbynett.no> writes:
>> you can have a higher power for a shorter time, or a lower power for a
>> longer time - but doing the work in a shorter time means longer times
>> in deep sleep with much of the circuitry disabled, and lower static
>> power.
>
> There is another issue too, which is that power management is
> traditionally rather complex to program. Using a 5 mhz clock running
> steadily can give simpler software than a 100 mhz clock jumping in and
> out of sleep modes, even if the total energy consumption is a smidge
> higher.
>

Adaptive timing can quickly be very difficult to manage. Usually you
want a microcontroller with flexible clocking, so that you can run
slower clocks to peripherals and keep them going at that constant speed,
and run your cpu core at either 0% or 100%. If you start doing
on-the-fly frequency jumps for your timing-dependent stuff, it will be a
serious challenge to get right.

> One circuit I'm thinking of basically will run an RTC and listen to a
> few pushbuttons, only occasionally doing something when someone pushes a
> button, so its computational requirement is small. But it has to run
> for 5+ years on battery power, so I need a good power estimate to
> conservatiely decide how big a battery pack to use.
>
> I guess the typical fancy digital wristwatch uses an 8-bitter clocked at
> 32 khz? Maybe I can use something like that.
>

You /could/ run everything at 32 kHz, but my first thoughts for
something like that is a microcontroller with an RTC at 32 kHz with
interrupts on the push buttons, and with the cpu core running from an
internal RC oscillator (or perhaps a PLL from the 32 kHz clock, but a
PLL takes more time to wake up). Keep the cpu and the core in dead
sleep most of the time.

Of course, if you don't need accurate timing, you can dispense with the
RTC as well to get even lower power. I once made an AVR Tiny card that
had a standby time of around 200 years from a tiny watch battery
(assuming, of course, the battery had no leakage or aging...).

[j.m.gr...@gmail.com]

On Monday, February 4, 2013 8:32:09 AM UTC+13, Paul Rubin wrote:
> One circuit I'm thinking of basically will run an RTC and listen to a
> few pushbuttons, only occasionally doing something when someone pushes a
> button, so its computational requirement is small. But it has to run
> for 5+ years on battery power, so I need a good power estimate to
> conservatiely decide how big a battery pack to use.

If you need a RTC and not much grunt, then certainly direct clocking from 32KHz is an option.
I once did a timer design that clocked the cpu at 50Hz - it needed to think in seconds, but be accurate over days, and they had mains on the board...

You then need to find a uC that properly specs _running_ at 32KHz, and not many do. Next to consider is if you need WDOG or BOD in the design...