Power Efficient Software Coding

Question

In a typical handheld/portable embedded system device Battery life is a major concern in design of H/W, S/W and the features the device can support. From the Software programming perspective, one is aware of MIPS, Memory(Data and Program) optimized code. I am aware of the H/W Deep sleep mode, Standby mode that are used to clock the hardware at lower Cycles or turn of the clock entirel to some unused circutis to save power, but i am looking for some ideas from that point of view:

Wherein my code is running and it needs to keep executing, given this how can I write the code "power" efficiently so as to consume minimum watts?

Are there any special programming constructs, data structures, control structures which i should look at to achieve minimum power consumption for a given functionality.

Are there any s/w high level design considerations which one should keep in mind at time of code structure design, or during low level design to make the code as power efficient(Least power consuming) as possible?

Answer 1

Do not poll. Use events and other OS primitives to wait for notifiable occurrences. Polling ensures that the CPU will stay active and use more battery life.

Answer 2

Consider using the network interfaces the least you can. You might want to gather information and send it out in bursts instead of constantly send it.

Answer 3

Zeroith, use a fully static machine that can stop when idle. You can't beat zero Hz.

First up, switch to a tickless operating system scheduler. Waking up every millisecend or so wastes power. If you can't, consider slowing the scheduler interrupt instead.

Secondly, ensure your idle thread is a power save, wait for next interrupt instruction. You can do this in the sort of under-regulated "userland" most small devices have.

Thirdly, if you have to poll or perform user confidence activities like updating the UI, sleep, do it, and get back to sleep.

Don't trust GUI frameworks that you haven't checked for "sleep and spin" kind of code. Especially the event timer you may be tempted to use for #2.

Block a thread on read instead of polling with select()/epoll()/ WaitForMultipleObjects(). Puts stress on the thread scheuler ( and your brain) but the devices generally do okay. This ends up changing your high-level design a bit; it gets tidier!. A main loop that polls all the things you Might do ends up slow and wasteful on CPU, but does guarantee performance. ( Guaranteed to be slow)

Cache results, lazily create things. Users expect the device to be slow so don't disappoint them. Less running is better. Run as little as you can get away with. Separate threads can be killed off when you stop needing them.

Try to get more memory than you need, then you can insert into more than one hashtable and save ever searching. This is a direct tradeoff if the memory is DRAM.

Look at a realtime-ier system than you think you might need. It saves time (sic) later. They cope better with threading too.

Answer 4

• Like 1800 INFORMATION said, avoid polling, subscribe to events and wait for them to happen
• Update window content only when necessary - let the system decide when to redraw it
• When updating window content, ensure your code recreates as little of the invalid region as possible
• With quick code the CPU goes back to deep sleep mode faster and there's a bigger chance that such code stays in L1 cache
• Operate on small data at one time so data stays in caches as well
• Ensure that your application doesn't do any unnecessary action when in background
• make your software not only power efficient, but also power aware - update graphics less often when on battery, disable animations, less hard drive thrashing

And read some other guidelines. ;)

Answer 5

From my work using smart phones, the best way I have found of preserving battery life is to ensure that everything you do not need for your program to function at that specific point is disabled.

For example, only switch Bluetooth on when you need it, similarly the phone capabilities, turn the screen brightness down when it isn't needed, turn the volume down, etc.

The power used by these functions will generally far outweigh the power used by your code.

Answer 6

Look at what your compiler generates, particularly for hot areas of code.

Answer 7

If you have low priority intermittent operations, don't use specific timers to wake up to deal with them, but deal with when processing other events.

Use logic to avoid stupid scenarios where your app might go to sleep for 10 ms and then have to wake up again for the next event. For the kind of platform mentioned it shouldn't matter if both events are processed at the same time. Having your own timer & callback mechanism might be appropriate for this kind of decision making. The trade off is in code complexity and maintenance vs. likely power savings.

Answer 8

Simply put, do as little as possible.

Answer 9

also something that is not trivial to do is reduce precision of the mathematical operations, go for the smallest dataset available and if available by your development environment pack data and aggregate operations.

knuth books could give you all the variant of specific algorithms you need to save memory or cpu, or going with reduced precision minimizing the rounding errors

also, spent some time checking for all the embedded device api - for example most symbian phones could do audio encoding via a specialized hardware

Answer 10

Well, to the extent that your code can execute entirely in the processor cache, you'll have less bus activity and save power. To the extent that your program is small enough to fit code+data entirely in the cache, you get that benefit "for free". OTOH, if your program is too big, and you can divide your programs into modules that are more or less independent of the other, you might get some power saving by dividing it into separate programs. (I suppose it's also possible to make a toolchain that spreas out related bundles of code and data into cache-sized chunks...)

I suppose that, theoretically, you can save some amount of unnecessary work by reducing the number of pointer dereferencing, and by refactoring your jumps so that the most likely jumps are taken first -- but that's not realistic to do as a programmer.

Transmeta had the idea of letting the machine do some instruction optimization on-the-fly to save power... But that didn't seem to help enough... And look where that got them.

Answer 11

To avoid polling is a good suggestion.

A microprocessor's power consumption is roughly proportional to its clock frequency, and to the square of its supply voltage. If you have the possibility to adjust these from software, that could save some power. Also, turning off the parts of the processor that you don't need (e.g. floating-point unit) may help, but this very much depends on your platform. In any case, you need a way to measure the actual power consumption of your processor, so that you can find out what works and what not. Just like speed optimizations, power optimizations need to be carefully profiled.

Answer 12

Set unused memory or flash to 0xFF not 0x00. This is certainly true for flash and eeprom, not sure about s or d ram. For the proms there is an inversion so a 0 is stored as a 1 and takes more energy, a 1 is stored as a zero and takes less. This is why you read 0xFFs after erasing a block.

Answer 13

Do your work as quickly as possible, and then go to some idle state waiting for interrupts (or events) to happen. Try to make the code run out of cache with as little external memory traffic as possible.

Answer 14

On Linux, install powertop to see how often which piece of software wakes up the CPU. And follow the various tips that the powertop site links to, some of which are probably applicable to non-Linux, too.

http://www.lesswatts.org/projects/powertop/

Answer 15

Choose efficient algorithms that are quick and have small basic blocks and minimal memory accesses.

Understand the cache size and functional units of your processor.

Don't access memory. Don't use objects or garbage collection or any other high level constructs if they expands your working code or data set outside the available cache. If you know the cache size and associativity, lay out the entire working data set you will need in low power mode and fit it all into the dcache (forget some of the "proper" coding practices that scatter the data around in separate objects or data structures if that causes cache trashing). Same with all the subroutines. Put your working code set all in one module if necessary to stripe it all in the icache. If the processor has multiple levels of cache, try to fit in the lowest level of instruction or data cache possible. Don't use floating point unit or any other instructions that may power up any other optional functional units unless you can make a good case that use of these instructions significantly shortens the time that the CPU is out of sleep mode.

etc.