## Clocks and power consumption

15 posts / 0 new
Author
Message

Okay, I'm a bit confused about something. The lower the speed of the cpu, the lower the power consumption, that I get. In my project on the Arduino (which has an external 16MHz clock) I use the "standby mode" of sleep, which stops most things except for the external clock.

Now, I had the clock prescaler set to as high as possible, achieving a clock speed of 62500Hz, BUT, since the standby mode does NOT disable the oscillator (which always runs @16MHz, the prescaler does nothing to affect the clock itself, right?), all I'm doing is making my software run slower. (?)

I checked the datasheet for "active supply current" of the atmega328p and the amp draw at 62500Hz would be around 0.65mA, and at 16MHz around 9.5mA. With a prescaler of 256, a piece of code takes 256 times as long to execute, thus drawing (0.65/9.5)*256 = 17.5 the amount of power as with no prescale...

So no matter what, a higher clock speed is always better for both response time of the system and power consumption..? Hm.

sol i sinne - brun inne

Last Edited: Tue. Feb 10, 2015 - 04:27 AM

Tickstart wrote:
I checked the datasheet for "active supply current" of the atmega328p and the amp draw at 62500Hz would be around 0.65mA, and at 16MHz around 9.5mA. With a prescaler of 256, a piece of code takes 256 times as long to execute, thus drawing (0.65/9.5)*256 = 17.5 the amount of power as with no prescale...

So no matter what, a higher clock speed is always better for both response time of the system and power consumption..? Hm.

Wrong!

First, power = current times voltage, energy = power times time.

The uC might require more energy to accomplish a specific task when running at a slower clock speed, but the processor is running all the time, whether it is doing a task or sitting idle, looping waiting for something to do.

Running at a slower clock rate will reduce the current used, which at a constant voltage reduces the power required and reduces the energy consumed per unit time.

While the oscillator is running at 16MHz, the prescaler reduces the clock rate used by the CPU in the uC, which reduces the current required.

Quote:
So no matter what, a higher clock speed is always better for both response time of the system and power consumption..?
In general, and overall, yes.  Provided that you shut things down and sleep when not needed.

However:

Quote:
I checked the datasheet for "active supply current" of the atmega328p and the amp draw at 62500Hz would be around 0.65mA
I don't know where you got that figure.

The active supply current graph begins at 0.1 MHz, which is 100 kHz.  You're running at 62.5 kHz.  The graph is linear however, so we can extrapolate.  Assuming you're running at 5V, running at 62.5 kHz would draw about 65 µA, not 650 µA.  At 16 MHz the draw is 2.4 mA, not 9.5.  So (70/2400)*256 = 7.5 times.

Remember though that this doesn't include draw from other peripherals, or from the oscillator itself.

And since you're talking an Arduino, don't forget that all the other components remain powered.  Is this an Uno?  If so, there's a voltage regulator, a power LED, a couple of opamps, and the ATmega16U2.  Even if you shut down the 328p completely, the Uno will draw around 35 mA.

EDIT:

Quote:
First, power = current times voltage, energy = power times time.
The term 'power' is often misused, when the appropriate term is 'current' or 'energy'.  Since we don't know what the OP wants, it's hard to say more.  However I'd hazard a guess that he cares about minimising energy consumption perhaps for a battery-powered device.

In that context the amount of energy consumed by an mcu executing a given segment of code will be higher when running at a lower speed for longer than when running at a higher speed for less time.  In any event the capacity of a battery can be expressed as watt-hours, but is perhaps more often expressed as amp-hours or milliamp-hours.

 "Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience.  Experience comes from bad judgement." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast.  Cheap.  Good.  Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl]

Last Edited: Tue. Feb 10, 2015 - 05:50 AM

There are some important facts here that get overlooked.

The big one is about batteries. They contain a specific amount of ENERGY. D cell contains a lot. C cell a bit less. AA less, AAA less. 9V quite a bit less than a C cell. If you have 3 C cells, no matter whether series or parallel, you have available 3 times as much energy as 1 C cell.

Second is about regulators. Linear regulators are first order constant current devices. Same current in as out (plus some quiescent current,. of course, at the input). Switching regulators are first order constant POWER devices. Same input power as output (plus some quiescent power). Linear regulators tend to be big power loosers. If the output voltage is Vo and the input voltage is Vi, then (Vi/Vo - 1)*100% of the power that comes in is lost to heat. That is often on the order of 40%. Switchers tend to loose 5% to 20% of the total input power. The point is that you can have a miserly MCU but be killed by excess power consumption if you do not manage voltage regulation well.

Joey is absolutely correct about power vs energy. If you have a device that consumes P1 power  for time T1 part of the time and P2 power for time T2, then the total energy used over this cycle is P1*T1 +P2*T2. If this pattern continues for some time, then just sum all the T1 energies and all the T2 energies and you have the total energy.  THIS is why sleeping saves energy. Suppose that the MCU takes a lot of power for a few milliseconds and almost none for some hundreds of milliseconds. Then you have a long time at low power and short time at high power. The secret is that, for most MCUs, it takes a specific ENERGY for each instruction. Run it fast or slow, SAME energy. So, run it fast, sleep lots, and you gain.

Jim

Until Black Lives Matter, we do not have "All Lives Matter"!

Last Edited: Tue. Feb 10, 2015 - 06:47 AM

Just to reiterate the point that an Arduino is not a good test bed for energy/power/current experiments anyway. It was not designed with power consumption in mind. The best kind of circuit to test this on is something built up from scratch where every addition to the circuit is considered for the effect it might have on power consumption. In fact a bare AVR on a board is possibly the best way to study the consumption of the AVR alone.

IOW design power consumption in from the start. Don't just pick some randomly chosen AVR board and expect to get meaningful results. Do you, for example, even know what the Arudino power supply design consists of? Clearly it's using Vusb but how exactly?

You also have to think what, for example, you are doing with unconnected pins on the chip. Again, by default I imagine Arudino is leaving most floating but it may even be using some pins for their peripheral functions. So what are you doing about turning all that stuff off before taking current readings?

Oh and exactly where are you taking the current readings anyway? Is it inline very close to the Vcc of the AVR or somewhere else in the circuit?

Last Edited: Tue. Feb 10, 2015 - 10:36 AM

I thank you for all you insight, electronics is not my field of work as you might suspect, but it's fun to learn. So what I've learnt from this is that, it is not far fetched that running fast can save energy in the long run. The MCU "consumes" the same amount of energy to perform instructions no matter what speed it's run, but heat dissipation of regulators and opamps etc plus peripherals kept alive during the meantime are the real power thieves.

sol i sinne - brun inne

Last Edited: Tue. Feb 10, 2015 - 01:06 PM

There have been endless threads about this here on Freaks over the years. The perennial argument is whether it is better for a mainly sleeping battery application to just wake up very briefly, run like the clappers, get some job done then return to sleep. Or is it better to wake up, run very slowly for much longer but at reduced "awake" power to get the job done. The answer is "it depends". On the whole the energy consumption may be the same overall and it may well depend simply on whether the thing to be done while awake needs the MCU to be awake for a while anyway - in which case wind down CLKPR and run slowly for a while or whether it just has to respond to something very briefly and doe snot need to wait. In which case, wake up, do the thing at full speed then SLEEP as soon as possible.

Another trade off to decide is how often you need to wake up too. Whatever has to be done might be done by ten bursts of 2ms each minute (every 6 seconds) or in two bursts of 10ms (every 30 seconds). That the raises the question of how much power is wasted in the waking up phase each time - a lot to do with "SUT". That then leads to a question of how you clock the AVR. A crystal (as main clock source) may not be the best choice if it takes 10's of ms to stabilize each time it is woken. A common solution to that one is to use the internal RC but, if accuracy is required, also include a 32.768kHz crystal in the design asynchronously clocking (usually) timer 2. It is then used to adjust OSCCAL to make the internal RC accurate. This combination is quicker to wake than a main crystal.

All of this and more has been discussed (as infinitum) in many prior threads - worth searching out if you can think of suitable search terms.

Sometimes, very unexpected things can happen, like power requirement decreases when you increase a baud rate... How can THAT happen? Imagine an application where the processor wakes up, sends a message, and goes back to sleep. Boosting the baud rate left the processor awake a shorter time. There are LOTS of things to think about!

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut.

Which voltage do you need for the things you control?

At full speed you may need 5V, but if you lower the voltage to 2.5V the AVR will only spend 1/4 of the power to run, so

if it can run faster than 1/4 of full speed, the lower speed will save energy!

just fast for a 324:

20MHz 5V 12mA = 0.06W or 3mW pr mips

10MHz 2.7V  3mA = 0.008 W or 0.8mW pr mips

4 MHz 1,8V 1mA = 1,8mW = 0.45mW pr mips

Last Edited: Tue. Feb 10, 2015 - 02:09 PM

That is true, I can't control the voltage on the Arduino, but if I could design the system that would indeed be true.

sol i sinne - brun inne

There are few hard a fast rules.  Every app will be different.  Different requirements and different constraints.

An app which runs on a CR2032 battery won't be able to run at 16 MHz, not within spec, anyway.  So you can only run so fast to begin with.  What's more, that kind of battery has a relatively high internal resistance.  10 ohms for a fresh cell, as high as 45 ohms at 50% capacity.

The effect of this is that energy is lost in the form of heat within the cell.  The proportion of that lost energy compared to energy put to useful work by the load is greater when that load is higher.

For example, take a fresh cell at 3.6V and 10 ohms internal resistance.  With a 1M load, current will be 3.599964 µA.  Power dissipated by the load will be 12.959740804 µW, while that lost as heat within the cell will be 129.597408039 pA, a ratio of 100001 to 1.

With the same cell but a 100 ohm load, power dissipation in the load will be 107.107438015 mW, while that lost as heat within the cell will be 10.7107438 mW.  An 11-to-1 ratio.

What's more, the greater the current drawn by the load, the greater the voltage drop it will see.  All of this gets worse as the battery discharges.  It gets worse too with prolonged discharge at higher current, as the by-products of the chemical reaction within the cell accumulate faster than they can be removed, and the internal resistance of the cell rises.  We've all experienced this phenomenon when we let a battery 'rest' before re-use.

So sometimes running faster will consume less energy at the load, but more energy overall.  What's more, since running faster means that the device will see a greater voltage drop, and since devices are spec'd to run at a given speed down to a certain minimum voltage, running faster means that the device will reach the a point were it will be running out of spec sooner, leaving more energy in the battery before doing so.

No hard and fast rules.  Determine your requirements.  Read the datasheets.  Do the math.

 "Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience.  Experience comes from bad judgement." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast.  Cheap.  Good.  Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl]

Hardware and Firmware Issues in Using Ultra-Low Power MCUs

by Jack Ganssle
December 2014

http://www.ganssle.com/reports/ultra-low-power-design.html

...

6 - Running Fast to Save Power

http://www.ganssle.com/reports/ultra-low-power-design.html#runningfast

...

"Dare to be naïve." - Buckminster Fuller

1. A lot of good info.

2. Only about 2032 power source

3. The pic he ref. to don't save the same as an AVR at lower voltage.

And I forgot that (some) AVR's can automatic turn BOD off under sleep, and on again when it wake up.

And for this kind of operation one need to look into the use of a crystal for RTC, but it't all depends of needs.

most often it's outside things that control how the AVR runs best.

So as others say find out what you need, and can.