How to extend the battery life of your

microcontroller-based design

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 in-
line 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