This action might not be possible to undo. Are you sure you want to continue?
By Scott Pape Courtesy of Embedded.com (07/26/2006 3:00 AM EDT) Whether it is an electric toothbrush, shaver, cell phone, PDA, MP3 player or the remote control for anything not within arm's reach, battery-powered devices are an everyday part of life. As such, power management is a significant issue for embedded designers today. The ubiquitous microcontroller offers designers a multitude of ways to manage the power requirements in many applications. The different MCUs themselves offer a range of current consumption and a variety of power saving features. However, power management in an MCU-based design is more than just selecting the right microcontroller. It also means coming up with a development strategy that most effectively uses these features. And at the system level, independent of the MCU that you have chosen, there are also a number of strategies that can be employed to further extend the battery life of your application. Example Application: Wireless Bicycle Computer To demonstrate effective power management, we will use a wireless bicycle computer as an example. This computer is composed of three modules, a control panel on the handle bars, a speed sensor on a wheel and a display on the rider's helmet. The speed sensor tells the control panel how fast it is turning. The control panel calculates information such as speed, distance covered, elapsed time and calories burned. The control panel sends this to the display. Figure 1, below, shows a block diagram of a bike computer control panel.
Figure 1. Block diagram for a wireless bicycle computer control panel, demonstrating the enhanced power management features on today's MCUs.
Increased number of low power modes. MCU's are moving into smaller geometries to reduce die size, which results in transistors that cannot tolerate direct application of 3 or more volts. So, voltage regulators are used to drop the voltage to the internal logic. Unfortunately, these regulators add to the MCU's current draw. However, since power is equal to voltage times current, a 1.8 volt to 3 volt system with a regulator may still be lower power than a 5 volt system without one. MCU's rely heavily on power management modes to keep the overall operating current down while still supporting regulated power supplies and increased clock speeds. New MCU's are providing multiple low power modes to address these needs and yet still maintain system flexibility. Freescale's MC9S08GB60 MCU has four low power modes: stop1, stop2, stop3 and wait. In wait mode, power is reduced by turning off the CPU clock, but leaving the clocks enabled to other MCU peripherals such as A-to-D converters, timers or serial communication modules. This mode is useful for saving power when these peripherals need to function, but the CPU has nothing to do until the peripheral completes its task. In our example, wait mode could be used while the SPI is used to communicate with the RF transceiver. To reduce power consumption further, three stop modes can be used. Stop1, stop2, and stop3 each provide different levels of operation that will reduce power consumption. Stop3 provides the most functionality of the three. In stop3, the on-chip voltage regulator is put into a power saving mode that still provides minimum regulation for retaining RAM and I/O register contents. Several interrupt sources and the reset pin can wake the
MCU up from stop3. Stop3 is the only stop mode in which the low voltage inhibit (LVI) module can be enabled. It is also the only stop mode in which the crystal oscillator can remain enabled In our example, stop3 can be used when the MCU is waiting between speed readings from the speed sensor. The RTI function that runs in stop3 can be used to wake the MCU in time for the next reading. Stop2 provides slightly less functionality, but reduces power consumption further. In stop2, the voltage regulator is powered down. However, the RAM contents are still retained. The I/O registers are powered down in this mode and need to be reconfigured upon wakeup from stop. In stop2, fewer interrupt sources are available to wake the MCU up, but the RTI function is still available. Back to our example, stop2 can replace stop3 to reduce power consumption slightly more. Since the RTI function and RAM both still work in stop2, the time between speed readings can still be measured. Stop1 is the lowest power mode of the MCU. It powers the voltage regulator down completely along with all peripherals, the CPU, RAM and I/O. Only the reset or IRQ pins can wake the MCU up. Stop1 is used when the MCU can be put into a powered down state, but still needs to respond to an external stimulus such as the press of a button. In the bike computer example, stop1 would be entered when the computer is powered down. Powering down with stop1 mode puts the MCU in the lowest possible power mode without actually removing power from the chip. Why not remove power from the chip? Removing power requires a more expensive toggle switch to disable power to the chip. Also, using a push button switch tied to an interrupt pin, allows the MCU to use the switch for multiple purposes, depending on the current state of the system. So stop1 mode is perfect for keeping the design simple, inexpensive and yet still consumes almost no current. Clock Management Many designers equate low power to slow clock frequencies. However, depending on what the MCU is doing and what low power modes are available on the MCU, running at top speed can actually save power. If the MCU has an efficient low power mode, then you will save the most power by spending the most time in this mode. So if the CPU needs to execute code before returning to sleep, running at the fastest possible speed to complete code execution and return to low power mode can burn less current than running constantly at slow speeds. Let's use our bike computer example. Assume the control panel gets a speed update once every 1 second and it takes 16,000 bus cycles to compute the data to be displayed. Running with a typical 32 kHz crystal and assuming a common divide-by-two bus clock, we have a 16 kHz bus, in which case it takes 1 full second to complete the calculations.
Now, if we can run at 8 MHz bus clock, it only takes 2 milliseconds to complete the calculations and 998 milliseconds can be spent in low power mode. Of course, not every task the MCU has to perform will benefit from top speed performance. In our example, the time required for the wireless communication would probably not require an 8 MHz bus rate if the data is fairly slow. So in this case, to minimize power consumption, we want to run the MCU as slow as possible until the wireless communication is complete. So we need an MCU with flexible clocks, such as Freescale's MC9S08GB60 MCU. With this device, you can use high or low frequency crystals or an internal oscillator. With any of these clock sources, you can optionally use the on-chip frequency-locked loop (FLL) to multiply or divide the bus speed to meet the needs of the task and minimize power consumption. Figure 2, below, shows how the power consumption changes during the different modes of operation of our bike computer example.
Figure 2: Chart of how power is managed in the bicycle computer example by alternating between short bursts of high activity and longer periods of inactive low power modes.
System hardware strategies to extend battery life In addition to low power modes and clock management, there are many other design considerations, both hardware and software, that can minimize power consumption. From a hardware standpoint, controlling power to peripherals, both internal to the MCU and external, can save considerable power.
It is straight forward enough to disable on-chip peripherals using the MCU's control registers. But it may not be as obvious to disable peripherals external to the MCU. Using general I/O pins, power can be controlled to external circuits. Our example uses a speed sensor to measure the speed of the bicycle wheels. This can be implemented as and LED and photosensor attached to the bike frame and a slotted disc attached to the wheel. Keeping the LED and photosensor on continuously will burn considerable current. Using I/O pins to enable the LED and photosensor only when taking a speed measurement greatly reduces this current. Now discreet components such as LEDs and photosensors may be obvious candidates for controlling with I/O, but just about any circuit can be controlled in a similar fashion. If the component requires more current than the MCU can provide directly, buffers can be used as power switches to these circuits. In some cases, simply connecting several I/O pins in parallel can provide enough current. The speed sensor also demonstrates another opportunity to reduce current. If the photosensor output is continuously read to determine if the light is shining through the disc, then the MCU has to be left in a higher current run mode. Since all we really care about is the transition point from light to dark and vice versa, we can use interrupts instead of constant polling. Interrupts allow the MCU to enter a lower power wait mode. The MCU's timer can continue to count and by using an input capture feature tied to the photosensor output, we can easily measure the light/dark timing of the speed sensor to determine the RPM. The MCU's I/O pins themselves can be a source of excess current if not configured properly. Unused pins need to be terminated to prevent a floating input from creating a high current path. This is frequently overlooked when using an MCU that comes in a variety of packages. We tend to forget that the pins available in the highest pin count version are still on the silicon in the lower pin count versions. Any input pin left floating will become a frustrating source of excessive current, many times only under certain circumstances such as temperature variations. In these cases, either an internal pull-up should be enabled or if the pin is an I/O, it can be configured as an output (data is irrelevant if it is driving an open circuit). System software strategies to extend battery life From a software perspective, there are some less obvious tricks to reduce power consumption. As stated previously, the best way to conserve power is to stay in the lowest power state for as long as possible. Since run mode with the CPU actively executing instructions is never the lowest power state, we want to minimize the amount of work the CPU must perform. This allows the CPU to complete tasks faster and allows the MCU to return to a low power mode.
Here are some tips for reducing the CPU execution time. Always use the smallest data type possible. When writing C code, it is easy to forget that the common integer is usually defined as 16 or 32 bit number, even on compilers for 8-bit MCUs. For 8-bit devices, always default to using the 8-bit char type unless a larger size is really necessary. Even then, you may be able to reduce code size by breaking a 16-bit or 32-bit number into 8-bit slices and only concatenate at the end of the data manipulation. Avoid using short loops or subroutine calls if you can afford the extra memory to use inline code. Every loop and subroutine uses additional CPU cycles to either determine if the loop is complete or to stack and unstack the program counter. If you know a short loop will always be executed four times, just write the same code four times in a row rather than using a for-next or while loop. If a subroutine only has 10 or 20 bytes of code, consider in-lining it instead of keeping it a subroutine. This will eliminate a fair amount of CPU overhead for simple tasks. Pre-calculate values when appropriate. Getting back to our bike computer example, assume the RF link uses two baud rates depending if the main control panel is talking to the display or to the speed sensor. When writing C code it may be tempting to pass the actual baud rate to the serial interface setup routine rather than the actual prescaler value the serial interface requires. After all, this makes the code more readable. However, this also forces the serial interface routine to calculate the prescaler value from the baud rate every time the baud rate is changed. Calculating the prescaler values beforehand and passing these to the serial setup routine will save CPU cycles and code space. Consider using look-up tables rather than complex calculations. MCUs such as Freescale's HCS08 family have very efficient instructions and address modes for accessing tabled data. Depending on the complexity of the calculation, this can save quite a bit of CPU effort. If calculations are still required, always check for early exits before starting the routine. A simple example is looking for multiplication by '1' or '0'. Conclusion Today's feature rich microcontrollers can offer designers of battery-powered applications many options for extending the battery-life of these products. Multiple low power modes and flexible clock sources give the designer the ability to manage power conservation versus performance as necessary to meet design targets. Run fast when the CPU demand is high and slow down when it is not. Always switch to low power modes when ever possible. In addition to managing the power of the MCU itself, foresight in system planning allows the MCU to manage the power consumption of the entire system. The MCU can enable and disable devices and circuits within the system as needed almost as easily as it can manage its on-chip peripherals.
And not to be left out, the software engineers can add their contribution to battery-life by establishing a CPU cycle awareness. The fewer instructions the CPU has to execute, the sooner the MCU can enter a lower power mode. Creating a lot of small functions may reduce code size, but can end up reducing battery-life. On the other hand, always using the smallest data type possible will reduce both code size and increase battery-life. So for your next battery-powered system design, remember to choose your MCU wisely and to use everything the MCU offers to manage the overall power of your system. Scott Pape is Systems Engineer in the Microcontroller Division, Freescale Semiconductor, Austin, Texas