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...
Reply by David Brown●February 3, 20132013-02-03
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...).
Reply by Paul Rubin●February 3, 20132013-02-03
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.
Reply by David Brown●February 3, 20132013-02-03
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.
Reply by David Brown●February 3, 20132013-02-03
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.
Reply by Waldek Hebisch●February 2, 20132013-02-02
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
Reply by Richard Damon●February 2, 20132013-02-02
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.
Reply by Vladimir Vassilevsky●February 1, 20132013-02-01
"Paul Rubin" <no.email@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
Reply by Tim Wescott●February 1, 20132013-02-01
On Fri, 01 Feb 2013 08:34:45 -0800, 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.
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
Reply by Paul Rubin●February 1, 20132013-02-01
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.