Software strategies simplify power puzzle

Battery-operated applications are not the only ones that demand low power. Power budget constraints exist for consumer/industrial applications powered directly from the mains using rectifiers and passive components, and even in automotive applications to ease the burden on the car battery.

However, low power consumption cannot be achieved just by using the most power-efficient processor. Unoptimized software may squander the opportunities available in the hardware. Many power-management techniques are implemented purely in software, and there are others that may be supported by hardware but do not become operational unless software takes advantage of them.

The simplest applications, such as a handheld remote control, have only two modes: on and off. Yet, even this seemingly simple example is complex. The off mode is not truly off, because the remote is waiting for the user to pick it up and press a button, upon which it wakes up and enables the clock rate and circuits it needs to perform its function. For example, if a remote monitoring/control device for utility meters uses wireless communication, it may power up its radio transceiver. A slightly more complex example will have modes intermediate between on and off-shutting off a display backlight after user inactivity, for example.

In addition to the system-level power-management modes, there can also be peripheral-specific modes. The display backlight needs to be kept alive only while the user interface is active. A Bluetooth radio transceiver only needs to be powered when the device is communicating over a piconet. A hard-disk drive only needs to be spinning during file access.

At the software level, these mechanisms are typically implemented in a timer-driven task under a multitasking real-time operating system. A hardware timer is programmed to provide the RTOS with periodic interrupts, causing the RTOS to call the timer-driven task. The task manages software timers that are cleared when certain events occur. If a software timer overflows (for example, due to lack of user activity), it triggers system-level or peripheral-specific actions to shut down peripherals or change the system power-management mode.

The application should exploit power-management modes built into off-the-shelf software packages such as protocol stacks. For example, modes specified in the Bluetooth protocols can be used to control system-level power management.

Today's microcontrollers provide hardware support for various power-management techniques. Designers should look for such features as active, power save, idle and halt modes, and at other power-reduction strategies including:

• Peripheral shutdown: Microcontrollers include on-chip modules such as timers and A/D converters, but there is no need for all of them to run at the same time. Power dissipation can be reduced by disabling the clock to unneeded modules.
• I/O port drive: Input ports should be driven by external devices or the MCU. If a port input is allowed to float, it could drift to a level between the maximum logical low voltage and minimum logical high voltage, which may cause excessive power consumption in CMOS devices.
• Multi-input wake-up: In many designs such as PDAs or PDA/phone combos, an MIWU can eliminate the need to scan inputs such as keypads for activity. The CPU can be halted, saving power.
• Power cycling: A watchdog timer can break the system out of idle mode after a specific time period. The device wakes up, checks for events that need to be serviced, then goes back into idle mode.
• Internal switching: The active operating current is directly linked to the internal switching of on-chip transistors. The more transistors that transition to logic high from logic low or vice versa, the higher the internal current drain. The application software should thus be designed to minimize internal switching.
• Oscillator stabilization: When switching between modes, power dissipated while the frequency and amplitude of the oscillator stabilize is wasted. In devices such as gas meters and smoke detectors, the mode transitions can occur 100,000 times a day. Designers must balance frequent mode switches vs. total time spent in idle or halt mode.

Abdul Aleaf (abdul.aleaf@nsc.com) is the applications manager of the Device Connectivity Division for National Semiconductor Corp. (Santa Clara, Calif.).