Power consumption is an issue. With portable devices this affects battery life. [I am irritated by the short intervals between necessary charging sessions with my smartphone, for example.] With mains powered equipment, power consumption is also a concern for environmental reasons. The matter of power has always been seen as a “hardware issue”, but, of late, there has been an increasing interest in the role of software …

It is clear that software can take an active role in managing power consumption, if the right capabilities are provided. For example, parts of a system may be switched on and off, as required. The clock speed of a processor may be adjusted according to the amount of work it needs to do at a particular moment. The clock frequency can have a very significant effect upon power consumption.

Another, more simplistic argument is based upon selection of operating system. A traditional RTOS [like Nucleus] is likely to have a significantly smaller memory footprint than Linux, so less memory needs to be fitted. As memory consumes power, less memory means less power consumption. This argument is sound, but may be countered by the assertion that memory power consumption is really not too bad.

Last week, I was working with a colleague, who has been doing some research into these matters. He showed me that there is an even simpler perspective: the amount of power the CPU consumes, when doing a particular job, will vary depending upon the OS. His experiment was conducted using a media player device. It was decoding an MP3 of a 71db 220Hz sine wave. He ran the code twice: the first time executing the application under Nucleus, the second using Linux. The power consumed was measured and plotted over time.

On the plot power consumed, when running Nucleus, is shown in pink; Linux is dark blue. The results are interesting: when running Linux the CPU was consuming nearly 25% more power than when it was doing the exact same job under Nucleus.

There is also an increase in power consumption of another 20% [between about 3000 and 4000 on the plot] when running Linux. What caused this? We do not know. Obviously Linux was doing something in this time frame, which affected it CPU load.

This experiment set out to see whether a conventional RTOS really did benefit a design in terms of power consumption. It succeeded in this goal. It also illustrated quite graphically the non-real-time [i.e. unpredictable] behavior of Linux, which may be a problem for certain applications.

Read more from Colin on SciTech Connect:

• Vintage Multi-core – the IPC
• Staying Inline
• Thanks for the Memory
• Embedded Optimization: Small or Fast?
• C, C++ and the Family Tree
• Agile Embedded

Colin’s most recent publication, Embedded Software: The Works is available now on the Elsevier Store. Save 30% on his book and other Newnes Press and embedded systems books. Use discount code “STC3014″ at checkout. 

About the Author

Colin Walls (@Colin_Walls) is an embedded software technologist at Mentor Graphics (@mentor_graphics), the leading EDA software company.

You can read more about Colin and his work on embedded systems at The Colin Walls Blog at Mentor Graphics here. Connect with Colin online here: