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 progra

Answer 1

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 2

• 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 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

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 5

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.