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

• 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 better 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. ;)

Recently a series of posts called "Optimizing Software Applications for Power", started appearing on Intel Software Blogs. May be of some use for x86 developers.

Answer 2

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.