Hi,
Just noticed jacobbeningo's excellent post (10 Tips for Maximizing Battery Life) in Embedded on Maximizing Battery Life. Some really good advice which any designer should take note of. Thanks, Jacob!
This is a subject I've spoken on many times at conferences over the years. For many systems, battery life is the most important driver in the design and it's going to become more important as time goes on. Mirroring Jacob's excellent approach, my tips would be as follows...
#1 Minimize memory access
It is well known that memory access consumes significantly more energy than executing instructions. An instruction involving an external memory access can consume an order of magnitude more energy than one which doesn't. This is really the big elephant in the room when it comes to being frugal with energy. There is also a clear hierarchy in how much energy it takes to access different types of memory. register accesses are obviously cheapest, followed by on-chip RAM, then cache, then external memory. So, consider:
#2 Minimize instruction count
Executing instructions may be unavoidable but each instruction consumes energy. There is a lot you can do to minimize the number of instructions executed by your program, ranging from making sure you have the right compiler options (correct target system/architecture, optimize for speed etc) to choosing the right algorithm for the job.
#3 Make as much use as possible of power saving modes
Here, Jacob and I are on the same ground. All ARM-based systems include a range of power saving modes - it's built into our DNA! The chip implementers work very hard to ensure that the microarchitecture supports them as much as possible, with multiple clock and power domains etc. But if the software developers don't use them, they're wasted! The goal for any frugal software application must be to spend as much time as possible in as low power a mode as possible. Make sure you understand the modes supported by your chosen device and architect your system to make maximum use of them.
There are lots of other considerations as well and I'm presenting on just this subject at TechCon in a few weeks time. If you're interested in the subject, it would good to see you in the session.
Chris
ARM at ARM TechCon
Regarding point 3, I've been playing around with Silicon Lab's recent Zero Gecko. They have a nice test application that forces the microcontroller into a specific mode and keeps it there, ready to be tested. EM0 is the high-end mode, 24MHz. In this mode, active calculation (calculation primes) consumed an average of 2.7mA. EM1, still at 24MHz but with some peripherals deactivated, consumes 1.18mA. EM2, a very low energy mode at 32kHz, clocks in at 700nA. EM4 is deep sleep, and the consumption was so low that my tools couldn't pick it up. Creating a simple clock application for a book, I switched between EM0 and EM2 every second, and the results were spectacular. Thank you Chris, and thank you Jacob for two very interesting posts!
Hi Joseph - you are absolutely right. When I say "instruction count" I am referring to the number of instructions which are actually executed at run-time to carry out a specific task. As you say, this might be related to code density but the relationship is not always intuitive. In general, compiling for high speed will work to minimize the number of instructions which are executed (in return for a possible penalty in code size) and thus reduce power consumption. In addition to the reduced cost of executing the instructions themselves, there is the additional benefit of being able to spend longer in a sleep mode.
Thanks for pointing out the possible confusion!
Thanks Chris for bring this up.
Regarding #2 Minimize instruction count, this possibly worth a little bit extra details.
It is easy to mistaken this point as high code density. Although it is related, it is not exactly the same. The key point is getting the processing task done as quick as possible, and enter sleep modes longer.
For example, if you have spare memory space in the flash memory of a microcontroller, you can compile the program with higher speed optimization, e.g. loop unrolling switched on. This increases the flash memory size you use on the device, but given that the unused flash space will consume power anyway, you have nothing to lost. By doing that you might be able to reduce the number of clock cycles in active mode significantly and therefore allowing better battery life.
High code density helps when the program size is small enough that allow you to squeeze the design into a microcontroller device with a smaller flash memory. Which often have lower power consumption and have lower cost.
These are great tips! I might have to borrow them for future discussions!