Microcontroller power drain

Paul Rubin <no.email@nospam.invalid> wrote:
> David Brown <david@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
hebisch@math.uni.wroc.pl 

On 01/02/13 17:34, Paul Rubin wrote:
> Richard Damon <news.x.richarddamon@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.
>

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.

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.

David Brown <david.brown@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.

On 03/02/13 20:32, Paul Rubin wrote:
> David Brown <david.brown@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...).

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