Managing device power with an operating system
Device power issues are becoming increasingly important. It is widely recognized that this is no longer simply a hardware matter – software has an increasing impact on power consumption. The selection of an operating system (OS) may be governed by many factors; consideration of power management is an important matter. This article reviews the various aspects of an OS that can affect its influence on power consumption and offers guidelines to avoid pitfalls.
Operating systems’ influence on power consumption
The choice of OS influences the power consumption of an embedded system in two separate and distinct ways. First, there is active power management, where the OS takes specific action to control, limit, or optimize the device power consumption. Second, there is the passive influence on power consumption, where architectural features of the OS have an indirect (and probably unintended) effect on power consumption.
Active power management
There are an increasing opportunities for software to positively influence device power consumption. This is logical, as the software “knows” what is expected from a device at any given moment in time, in terms of functionality, speed, etc. It is logical that this power management capability be accommodated in the OS. There are three well defined areas where power may be managed by software:
- selective switching off of logic blocks (peripherals) when they are not required
- management of the clock frequency and supply voltage of the CPU; this is Dynamic Voltage and Frequency Scaling (DVFS)
- utilization of CPU low power modes
Peripheral power down
Many embedded systems have numerous peripherals, many of which are unused for much of the time. Examples might be Bluetooth and WiFi interfaces, displays, etc. If the software is provided with the means to switch off unused logic blocks, only reactivating them when they are actually needed, there is a lot of scope for power saving.
Dynamic voltage and frequency scaling
It is probably not intuitive to the average software engineer – though experienced embedded developers may have more hardware insight – that the power used by a system is increased with rising clock frequency. In a way, this is unsurprising, as clearly more work can be done in a given time period by a CPU that is executing faster.
It is increasingly common for systems to incorporate DVFS, which enables the software to adjust the CPU clock frequency. It makes sense that there are many times when all the available computing power is simply not needed, and a low frequency, which results in lower power consumption, would suffice.
Low power CPU modes
Increasingly, processors designed for embedded applications feature a number of low-power modes that, under the control of software, may be entered when circumstances allow. The details of these different modes and the terminology is far from standardized, but here are two typical examples that address the needs of many applications:
- Suspend is when the CPU and all peripheral devices are powered down, but power to memory is retained to preserve its content. This mode continues to consume some power (to keep the memory alive) and allows processing to resume with minimal delay.
- Hibernate allows a much longer period of inactivity. Memory contents are written to persistent storage (typically flash memory) and everything is powered down. This mode consumes almost no power at all, but there is a delay resuming operations when the memory is reinstated.
Care is needed in applying low power modes, as they all have a cost. Extra code is executed to enter and exit any of these modes and this consumes a certain amount of power. Clearly the power saved by using the mode must exceed that consumed to deploy it.
A power management framework
It is logical for the operating system to be given responsibility for power management, as it has a supervisory capacity over the application code. Ideally a power management framework is provided, which enables centralization of the power management operations.
A key requirement is for device drivers to be able to register their requirements with respect to power management. For example:
- which peripheral blocks need to be powered
- which CPU frequency (or frequencies) are acceptable
- DMA requirements
Power management is normally modeled using the concept of ‘operating points’, which are a series of voltage/frequency settings.