I am working with a fairly barebones version of the Atmega2560 (minimum circuit, @3.3V and 8 Mhz) connected up to some basic peripherals (such as shift register, SD card, Xbee, etc.), all powered by Li-ion battery.
Now, out of curiosity, I looked through the power-consumption numbers on the Atmega2560 datasheet (pasted the data table in the image below) and I observed something interesting:
There appears to be substantial savings from cutting down on clock speed and supply voltage level (something also discussed on Nick Gammon's page: http://www.gammon.com.au/forum/?id=11497).
So with this in mind, I'm thinking of replacing my 8 Mhz external crystal with a much smaller 1 Mhz crystal instead.
The following activities are as intensive as I plan to get with my sketch (worst-case scenario):
20-30 LEDs (hooked up to an SPI-based shift register) blinked every 50 ms
Digital temperature sensor measured every 100 ms
SD card written to every 100 ms
Xbee transmission every 100 ms
Pushbuttons connected to hardware interrupts
I am aware that 1 Mhz is a million clock cycles, and hence a lot of instructions processed per second. But I want to make sure that's fast enough for the above activities (in terms of instructions run by their related libraries like the SD library or the Xbee-Arduino library, etc.) as well as any other instruction-consuming things that might exist in an Arduino sketch/its post-compilation assembly code.
So, my QUESTION is: With the above in mind, would going to a 1Mhz crystal be a wise choice? Am I way clear, or should I go to 2 or 4 Mhz or even 8 Mhz?
For reference, here is the table from the datasheet that I mentioned above:
Often running at full clock speed but then going into sleep mode when inactive can be more economical - because the rest of the circuit can be powered down for longer (the microcontroller takes less time to do stuff).
This will be especially noticeable with an SDcard and Xbee transceiver, these could take lots of current when active.
To get the most out of sleep mode you need to be able to put all the peripherals into shutdown mode too.
Oh yes, for CMOS the power consumption is roughly proportional to clock-speed times V^2 (but maximum clock speed depends on V)
There appears to be substantial savings from cutting down on clock speed and supply voltage level
Because at each cycle, you will need to remove from / add to the millions of cmos gates a tiny charge.
The following activities are as intensive as I plan to get with my sketch (worst-case scenario):
You can estimate that.
20-30 LEDs (hooked up to an SPI-based shift register) blinked every 50 ms
100 cycles per 8 bit, 20x a second = 2k cycles.
Digital temperature sensor measured every 100 ms
Not sure which one but 200 cycles / each read x 10x a second = 2k cycles
SD card written to every 100 ms
Not a clue but let's say 10k cycles per read x 10x = 100k cycles
Xbee transmission every 100 ms
1k cycles per read x 10x = 10k cycles.
Pushbuttons connected to hardware interrupts
50 cycles each and let's you furiously push the buttons 20x a second = 1k cycles.
For a total of 120k cycles per second.
So at 1Mhz, 8:1 clock divider is probably OK but 1Mhz, 1:1 divider gives you far more room for error.
Not sure if you have considered this but with a pin or two, you could have obtained the ability to run a variable speed rc oscillator that allows you to change the clock speed on the fly.
That is true. However, you waste time / energy going out of a crystal oscillator. Most people use 5 - 10ms as a rough estimate to when a crystal oscillator will stablize.
In addition to that, most chips waste certain cycles (some 1k, some 64k) before asserting the oscillator is OK and starting to run the core off the oscillator.
So putting the mcu into sleep makes a lot of sense if you intend to run it very infrequently (once a second or so).
Some chips get around that with a multi-staged start-up: start-up on rc oscillator and then transfers to a crystal oscillator.
Most people would just pick a chip designed for such (MSP430 for example).
With high frequency tasks here and uncertainty with push buttons (polling), I don't think this is one of those cases where you can benefit from putting the mcu into sleep.
Very valuable and interesting-to-read points. I hadn't considered the fact that the peripherals also consume additional current while the uC is awake longer.
So, it appears I can get good savings by using the 8Mhz and just going back to sleep quicker, and thus also without risking errors (esp. for SdCard's worst-case instruction count).
I am also curious about a couple of other things now:
(1) What kinds of applications are low clock speeds (e.g., 1 Mhz or lower) advantageous for? Or is the datasheet listing them just for theoretical reference?
(2) What exactly is counted as "Idle" (versus Active) when the microcontroller is running my code? The table you see above also infers that there is a sizable reduction in the supply current in the Idle condition vs. Active condition.
(1) What kinds of applications are low clock speeds (e.g., 1 Mhz or lower) advantageous for? Or is the datasheet listing them just for theoretical reference?
Battery-powered applications, cases where you don't have fast interactions with other devices (temperatures for example don't change quickly so it makes zero sense to read it 1 million times a second), etc.
(2) What exactly is counted as "Idle" (versus Active) when the microcontroller is running my code? The table you see above also infers that there is a sizable reduction in the supply current in the Idle condition vs. Active condition.
Modern mcus have extensive power management capabilities, built around routing clocks to peripherals / core / ram / oscillators. Because of that, you actually have different "kinds" of sleeps - with varying degrees of activity / inactivity for certain parts of the chip. Idle, as defined by Atmel, is the deepest types of sleeps for AVR, where pretty much any clock is turned off, other than CPU / Flash - so it can still run code. The most "active" sleep in the Atmel world is called "Power down".
@dhenry: You mention in Reply #4 that there is a 5-10ms clock stabilization time, but suppose my uC sleeps for 50 ms, wakes up and works for 50 ms, then goes back to sleep. In this scenario, isn't it still advantageous to use intervallic sleeping every 50 ms?
You mention that there is a 5-10ms clock stabilization time, but suppose my uC sleeps for 50 ms, wakes up and works for 50 ms, then goes back to sleep. In this scenario, isn't it still advantageous to use intervallic sleeping every 50 ms?
Yes, but the benefit is less.
See that the mcu consumes 10ma at full speed and nothing in sleep.
For every 50ms, the mcu is active for 5ms (start-up time) + 0ms (for your task). Total current consumption is 5ms * 10ma = 50ma*ms.
Rather than putting it to sleep, you run the mcu at 1/1000th of its speed, no start-up time (as the mcu is always running), as in the case of a variable rc oscillator.
For every 50ms, the mcu is 1/1000th for 50ms and 0ms(for your task, at full speed). Total current consumption is 50ms * 10ma / 1000 = 0.5ma*ms.
If you want to learn more about this, TI has an application note on msp430 - with heavy emphasis on its "instant on" oscillator. That family of mcu was specifically designed for low current consumption applications.