Power management in embedded systems – new thinking required

Colin Walls, embedded software technologist, has over twenty-five years of experience. A frequent presenter at conferences and seminars, and author of numerous technical articles and books on embedded software, Colin is a member the Mentor Embedded Systems Division.

Designing an embedded system involves managing complex interactions between hardware and software. As the need for power management has grown, the hardware and software development processes have had to become more closely integrated to achieve the best results.

A simple example: hardware engineers may want to minimize the memory in their designs, to save power, but they’ll need the software engineering team to tell them how much memory the code needs to work effectively.

Another example: hardware engineers’ choice of CPU may be driven in part by the onboard power-management facilities, but it’ll be the software engineers who define when those facilities can be used without undermining system function.

Managing power in embedded systems is, therefore, increasingly a case of understanding the functionality of the target device, working out how it will be used, and then writing software to run the hardware as efficiently as possible in each use scenario. This takes systemic thinking.

Let’s use the example of a portable health monitor design. The device measures various health indicators, and sends that data to your doctor over a WiFi link at regular intervals. There’s also a button and display on board, so patients can get a readout on demand.

If we want to manage the power in this device, we need to understand how it will be used.

For example, when the device is monitoring vital signs, it needs to power the CPU and sensors, but not the display and WiFi. When it sends the data, it doesn’t need to power the sensors or display. Then there are the variables: how often do we need to take a reading? How often should the data be sent? How often is the user going to press the button?

This analysis usually ends up as a spreadsheet of profiles of functionality, required performance, and likely power usage for each use case. It’s once you have this insight that you can start some detailed design thinking. Should you only send data when the readings change significantly? How should the device’s behavior change when its batteries run low?

Systemic design thinking can also guide decisions about using hardware power-saving modes. If there are long gaps between readings, it may make sense to use a hardware ‘hibernate’ mode. But if it takes a lot of code to save the device’s state, and a long time to wake the device from hibernation, the apparent benefits could be undermined. Storing and running the hibernation code will take energy. And if the device takes a long time to switch on when users press the button for a reading, they may worry unnecessarily.

The point is that all low-power modes have costs associated with them. In this case, it might make better sense not to hibernate the device, and instead simply reduce its operating voltage and frequency when idle, so that it consumes as little power as possible while also responding quickly.

There are tools to help understand how power is used in a design. Mentor’s Sourcery Analyzer for example, which you can think of as a trace tool on steroids, enables designers to compare power consumption with software activity throughout the development process.

However the biggest change necessary to achieve more effective power-managed embedded systems design doesn’t involve the tools. It involves the culture of the engineers and the teams in which they work.

Telling software engineers that power usage in multiple use cases, and the resultant overall battery life, is now their responsibility presents them with a new (and perhaps unwelcome) challenge.

What we ultimately need is a culture in which a team is given a device’s functional specification and the design gets accepted when it meets both the functional and power requirements.

I can’t name a single company that is applying this philosophy today, although it’s undoubtedly what they need to do. Full acceptance of the new philosophy requires an entirely new mindset, in which everyone in an embedded-system engineering team recognizes that they are going to have to think more deeply, widely and systemically about what they are doing in order to achieve good designs that have effective power management strategies.

Company info

Sign up for more

If this was useful to you, why not make sure you’re getting our regular digests of  Tech Design Forum’s technical content? Register and receive our newsletter free.