Power Management Considerations For Efficient Embedded Systems Development

Usable product life is a critical factor in the success of any portable device, and managing power efficiency is a key requirement for embedded systems today. Historically, power management was seen as a “hardware problem” that plagued development teams, but with today’s sophisticated devices and more specialized hardware, this impacts the software developer, as well. One reason for this increased attention is the incessant demand for connectivity on embedded systems — particularly wireless — which makes the push for low power consumption an even greater challenge.

Up until now, it had been common practice to optimize for power late in the design cycle, when the device is nearly completed and power consumption was discovered to be too high. System developers would work backwards to shave power consumption in the suspect areas. Today, this approach is no longer acceptable. In order to successfully address power consumption issues, developers have to build power efficiencies into every stage of development.

To begin, consideration should be given to selecting hardware with power saving capabilities. This should be done in the early stages of design, particularly if the hardware features can be controlled by the software. Hardware can have a profound impact on the selection of an operating system (OS) and device drivers. Selecting an OS with a power management framework will help define power usage profiles as they relate to the functionality of each driver, and what is being demanded of a specific driver at any given time. Employing a power-aware OS enables measurable goals to be set and applied throughout the design process; teams are able to apply power-saving methods as they move to the final completion of an embedded device.

A power pyramid (Figure 1) shows key areas that can affect power consumption from the early stages (in hardware) up to the application level.

Fig. 1.

Hardware: Obviously not the domain of the embedded software developer, but some influence should be made on hardware selection, as the capabilities of the CPU and associated circuitry are critical to power management.

Use cases: In the early stages of software design, it’s best to run a series of use cases. These are modes of software operation, which may or may not involve user interaction. It’s good design practice to consider the resource requirements of these use cases in order to estimate their power profile.

Operating system: An operating system with a modern power management framework enables low power design to be performed at every stage of development. The availability of this functionality can be the key criterion for the selection of a specific OS.

Board support packages and drivers: Building power awareness into drivers is an essential aspect of using an OS with a power management framework. The driver corresponds to hardware that may be powered down when not in use—and the driver may encapsulate the “knowledge” of the device’s limitations.

Application(s): The top level of code offers the least opportunities for power optimization. However, poorly written code can influence the power profile of a design in a negative fashion.

Hardware selection
While power consumption is often viewed as a software issue, hardware has the greatest influence on power management. Hardware defines the best possible potential for power savings. Specific CPU features that influence power consumption include:

• The ability to turn off specific blocks when they are not required
• Dynamic Voltage and Frequency Scaling (DVFS), which allows the software to adjust the performance of the CPU by adjusting voltage and clock frequency
• Availability of particular low power modes

The design of the rest of the system around the CPU must be compatible with these features.

Establishing use case scenarios
A key step in designing an embedded system for low power consumption is to define it in a variety of use cases. A use case corresponds to specific functions performed by the device that may or may not involve user interaction. An example of a use case scenario might be a battery-powered portable medical device that monitors a patient’s vital signs with data shown on an LCD display and uploaded to a hospital server using a Wi-Fi connection.

Specific use cases for this medical device might include:

• The device takes a complete measurement
• The device uploads a set of measured data
• The user checks their own vital signs using the built-in display
• The device is idle, awaiting the next measurement

Use cases and power consumption
Functionality required for each use case can be determined in the medical device example. This gives a clear indication of which drivers – or hardware blocks – need to be enabled for each specified use case. The energy consumed by a use case can be calculated by looking at the estimated power consumption and the estimated time to execute the use case. The expected frequency of the use case as a scaling factor results in an energy breakdown showing battery charge usage over time as depicted in the chart below (Figure 2).

Figure 2:  This chart shows use case parameters of a medical device, which can help the designer make intelligent decisions on power consumption efficiency.

This chart shows two clear possibilities to minimize power consumption: data upload and user vitals check. The data upload consumes the most energy, since it performs at five-minute intervals when each measurement is completed. The data upload could be changed every 30 minutes, consolidating the data from the last six measurements. However, an upload could also be initiated if there is a sudden change in any of the vital sign levels. The display of user vitals check is the second most power-consuming use case. In this example, the display times out after 30 seconds. As most other hardware is disabled during this use case, this is clearly where optimization might be focused. Consider a shorter timeout period as more satisfactory.

The operating system
The operating system is the lowest layer of software closest to the hardware, and it has the most significant effect on power savings. Selecting an OS has a major influence on the power efficiency of a design. An RTOS-based system design provides two key advantages for developing power-efficient applications. First, the multi-threaded application model provides an enabling framework to switch the system to low power operating modes during system idle time (i.e., periods of inactivity when there are no tasks/threads ready to run). Second, an RTOS with power management capabilities provides software developers with proven, well-abstracted, ready-to-use APIs that enable application-level control of peripheral power states, system power states, and operating voltage and frequency.

Real-time operating systems such as the Mentor Graphics Nucleus RTOS provide built-in power management facilities software developers require to design an embedded system that is fully optimized for power efficiency. The power-aware Nucleus RTOS automatically utilizes the discovered power management capabilities within the hardware, allowing developers to effectively manage power consumption throughout all phases of the design cycle.

Board support packages and associated drivers
If the selected operating system has a power management framework, the power requirements for each driver are likely to be specified. Some of the factors addressed include:

• Which power states are supported: ON, STANDBY, SLEEP, OFF?
• At what operating points (combinations of voltage and CPU clock frequency) will the driver be used? Examples include A)  While ON, it may be required to work at both 200MHz and 100MHz, and B) SLEEP may reduce the clock to 1MHz, should be tolerated.
• Participation with dynamic voltage and frequency scaling (DVFS)
• Advising the OS of DMA transfer requirements since this may be adversely affected by power saving measures

When designing embedded devices, it is common that drivers are initially written for functionality only—with little consideration for power management. Designers simply copy the reference code from the hardware vendor, which turns on the device, leaving power optimization considerations until the end of the project. This usually results in sub-par performance and last-minute, hacked-in code that becomes dispersed throughout the product codebase. This also can have an adverse effect on portability. These shortcomings can be avoided with upfront planning to allow for the full realization of the hardware.

Application development
Application code is the last layer of software in an embedded system. There is little opportunity to optimize for power in application code; but there is still the possibility for poorly written code to adversely affect power performance. An OS with a built-in power features framework simplifies matters because the application programmer can be less concerned with fine details.

Using an OS, the application is constructed from a number of independent threads or tasks. Using a power management framework, each thread (or group of threads) registers its power needs: which peripherals are used and, therefore, which ones can be switched off, and the minimum operating point to provide DVFS parameters. The OS can take care of power management and also the context switch.

Conclusion
Power consumption will continue to challenge embedded and software developers. With hardware vendors launching new and intriguing power saving features, these challenges have the potential to increase exponentially. Embedded system design today introduces new levels of complexity in all phases of development. It’s critical for embedded developers to re-think how they approach embedded system design. To address increasing system complexity and low-power issues, it is increasingly clear that software developers must invest more time and effort in upfront planning versus attempts to optimize for power at the back end of development.