Microcontroller power drain

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 for some information and ideas.

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

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.

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²xf (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.

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.

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

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

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.

There is no point.

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

Vladimir Vassilevsky DSP and Mixed Signal Consultant

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.

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

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.

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.

That's absolutely true (and mentioned earlier).

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.

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.

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.

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

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