In the realm of design, the quest for low power continues ad infinitum as a primary goal. Yet low-power requirements place significant additional constraints on designs, constraints that ordinarily would be secondary or non-existent. Often, a simple oversight in the firmware executing on a part can substantially reduce battery life.
When on this quest, designers must ask—before writing any code, selecting components, or creating schematics—what “low power” means. Almost always, the answer is that it depends. For instance, it depends on the application, the typical use case, and a whole slew of tradeoffs involving cost, performance, size, and other factors.
Table of Contents
- Classifying Devices With Regards To Power
- Means Of Measurement
• Eliminating Parasitic Peripherals
• Configuring Unused I/O
• Run-Mode Clock Throttling
• Taking Advantage Of Bursty Operation
• Rechargeable, battery-operated handheld devices: These devices, which often have a runtime measured in hours, are designed to be frequently recharged. They perform little or no processing when off, but significant processing when running. Portable media players and cellular phones fall into this category.
• Devices that spend most of their time in sleep/standby: Such devices have runtimes measured in weeks or months. There’s very little processing when the device is on, and it returns to sleep mode quickly. Most of the time, the device is in deep sleep or standby. These devices include IR/RF remote controls, portable test equipment, wireless keyboards, and blood-glucose meters.
• Devices that are barely alive: Runtimes for these devices are measured in months or years. Minutes, hours, or even days can elapse between short bursts of activity. They’re often found in remote monitoring applications. Utility metering and data loggers are two examples.
Means Of Measurement
So, how do you identify a low-power device? Once again, it depends. There are many ways to define and measure power consumption. Any datasheet, product brief, or application note for a low-power microcontroller comes replete with a colorful assortment of specifications. Common specs include MIPS/watt, mA/MHz, low-power run-mode current consumption, and sleep-mode current consumption.
No single specification tells the whole story, and the actual performance depends heavily on the use case. For instance, a device with a great mA/MHz specification might have an unacceptable sleep-mode current. What’s more, the functionality in each of these sleep modes may not even be easy to quantify. Does the part have any timers active in the mode of interest? Does it keep the contents of RAM? Comparing apples to apples here is an effort unto itself.
Despite the myriad product specifications, requirements, and design constraints, much can still be done in any design to minimize power consumption. The following standard techniques can help save power on most modern microcontrollers and processors:
Eliminating Parasitic Peripherals
Since many microcontrollers come out of reset with peripherals enabled, disabling unused peripherals will save a significant amount of power. Often, this is simply a matter of clock gating; turning off the clock to a peripheral will completely eliminate its power consumption. In some situations, though, a more sinister power sink lurks in the bowels of peripherals, a.k.a., quiescent current.
In applications that demand deep sleep and maximize every nanoampere, the peripherals’ quiescent-current consumption becomes vital. Analog peripherals such as comparators and analog-to-digital converters (ADCs) are good examples where clock gating alone won’t suffice when powering down the peripheral.
The specs shown in Figure 1 were lifted from datasheets for Freescale’s Flexis QE series low-power microcontrollers. On the Flexis QE32, the comparator’s power consumption falls in the 20- to 30-µA range. This may not seem like a lot, but considering that the deepest power-down current consumption on the device measures 350 nA (at VDD = 3 V), leaving that comparator on isn’t a viable option.
Configuring Unused I/O
Unused I/O can be a major source of unwanted power consumption if it’s left configured as an input. In standard CMOS logic, power consumption occurs only when switching states from on to off and vice versa. Floating inputs will cause unintentional switching. The best way to handle unused I/O is to set it as an output when power must be saved, i.e., in a power-down or low-power run mode.
From a board-level perspective, it’s important to consider the lowest power state of the circuit connected to the pin. For example, if the pin is pulled up or down externally, set the output to the value corresponding to VDD or ground, respectively.
Remember, in this scenario unused I/O isn’t limited to the I/O that’s never used. Any time a peripheral or a set of I/O isn’t necessary, it can be reconfigured as an output on-the-fly. This is generally a good idea when entering a low-power mode of operation that works with limited functionality. Dedicated analog inputs must be treated carefully at the board level, as they can be input-only pins with input impedances in the tens of kilohms.
Run-Mode Clock Throttling
In applications featuring a device operating in active mode, where the CPU is enabled and processing for extended periods of time, it makes sense to carefully evaluate the performance/power tradeoff. For instance, low-power applications rarely require blazing-fast speed. Usually, the CPU performs some rudimentary calculations on data or manages peripheral interaction with the outside world.
At times, the CPU needs to be on, but its role is limited. Here, lots of power can be saved by throttling its clock down to a level where it efficiently processes data without becoming idle. An excerpt from the Texas Instruments MSP430F2132 microcontroller datasheet illustrates this point, listing the active-mode current consumption at various CPU clock frequencies (Fig. 2).
Taking Advantage of Bursty Operation
On the other side of the CPU throttling coin, bursty operation for processing and data acquisition offers another good opportunity to save power. The principle behind this technique involves minimizing the time in an active mode of operation. It may be unintuitive, but performing the tasks that consume lots of static current for a shorter period of time can be more power-efficient than doing so for a longer period of time at lower power. This applies equally well to CPU run modes and high-power peripherals such as ADCs.
The burst-mode principle for processing data can be elucidated further by comparing power consumption between 8-bit and 32-bit hypothetical devices (Fig. 3). Both wake up with the same periodicity to acquire and process data. Because the 32-bit device (right) can complete the processing task faster, it’s out of its high-power mode quicker when the sleep interval and data-to-process remains constant. Also, note the difference in the baseline power consumption, with the 8-bit device having the lower of the two. The area under the curve represents total energy consumption. Therefore, the lower-power run-mode on the 8-bit device (left) isn’t necessarily an advantage.
Data-acquisition tasks from peripherals follow this principle, too. Turning on an ADC for short periods of time, only when needed, minimizes the time it’s actively consuming current. Interleaving the data acquisition and the processing tasks will result in more efficient power usage.
Low-power, low-frequency clock sources can be employed to manage sleep/wakeup cycles. Such a timer comes standard on most modern microcontrollers. If not available, then highly accurate and low-power 32.768-kHz watch crystals are an ideal substitute.
Hardware and software design for low power is application-specific. The key part of the process is to become intimately familiar with your product and its intended use case(s) before making any major design decisions.
Most of the design process depends on factors that change with each project. However, following some basic strategies, such as using power only when needed, managing parasitic peripherals, and being careful about clocking, can effectively minimize power consumption.
- “The Benefits of Single-Cell MCU Operation” by Steve Diaper, Field Applications Engineer, Silicon Labs: http://low-powerdesign.com/silabs_diaper.htm
- “Reducing energy use with MCUs” by Isaac Leung, Electronic News July 6, 2011: http://www.electronicsnews.com.au/news/reducing-energy-use-with-mcus
- General data and specs for Freescale Semiconductor’s S08QE Flexis 8-bit S08 Microcontrollers: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=S08QE
- Datasheet for Freescale Semiconductor’s MC9S08QE32 Microcontroller, Revision 7, September 2011: http://www.freescale.com/files/microcontrollers/doc/data_sheet/MC9S08QE32.pdf
- Datasheet for Texas Instruments’ MSP430F21x2, Mixed Signal Microcontroller (MCU), NOVEMBER 2007–REVISED JANUARY 2012: http://www.ti.com/lit/ds/symlink/msp430f2132.pdf
- How Green Is Your MCU? by John Donovan, EE Times, 4/27/2011: http://www.eetimes.com/electronics-blogs/other/4215522/How-Green-Is-Your-MCU-