The number of embedded devices that must be run off of battery power or parasitic power continues to grow. The traditional approaches to designing these systems vary from simply relying on semiconductor manufacturers to provide the lowest power parts to the liberal use of pentagrams, black candles, and rubber chickens.

Every low power design is different and will have its own interesting set of problems to solve. You have to think through every element of the design if you want to operate at very low power levels.

Begin at the beginning

Where do you begin when designing an embedded system for low-power operation? Like any other design task, the answer to that question is to ask more specific questions. Some of the important issues to consider include the power consumption limits, size restrictions, I/O requirements, and operational duty cycle.

It has been our experience that getting someone to volunteer a parameter for how long a device must operate on batteries is much easier to do than to get serious consideration paid to this problem. To have a meaningful discussion of battery life, those taking part must understand something about the end use of the device. Here are some things to consider.

Is recharging practical?
The answer to this question is not always yes. In fact, for an embedded device that operates for long periods of time without actually being held by a human, the answer is almost always no. An example of this would be a data collection collar for wildlife (it's pretty difficult to get a raccoon to plug in his radio collar before he goes to bed).

Another area where recharging may not be practical would be when continuous use by multiple users is required. Consider the digital thermometers used by hospitals today. Since the same device may be used by the nurses on all shifts, when can you let it sit in a recharging station? It is important to remember that, from the embedded electronics design standpoint, there is little difference between a device with replaceable batteries and one with removable, rechargeable batteries.

How big can the device be?
Unfortunately, for those of us who have to design embedded systems, the marketing hype of battery manufacturers far exceeds the actual improvements in energy densities. In spite of what the little pink bunny would have you believe, no significant improvements have been made in the energy density of commonly available batteries in many years. All batteries are limited to a maximum amount of energy per unit volume. We will discuss battery selection in more detail later. For now, just remember that the bigger the battery compartment, the longer the battery will last.

How long does the device have to run?
Be sure and come up with a model for usage that includes a practical estimate for the percentage of time that the device will be operating in the various power modes, including off. A good example of why this is important is a simple handheld device like a Palm. A Palm IIIx will run in active mode for about 24 hours on a pair of AAA batteries. If kept in active mode for the entire work day, the batteries would have to be replaced every two to three days. In most real life scenarios, the batteries on this device will last from two to four weeks, because the device spends the vast majority of its operating life in sleep mode.

How much power will the device require?
That's the $64,000 question! Work out a preliminary power budget as quickly as possible. Keep in mind that you absolutely, positively have forgotten something, so add a fudge factor. If you even mention a guess at battery life to your marketing department, that number will become the absolute minimum battery life for the product. If you add some fudge in the beginning, you have the opportunity to be a hero when the numbers turn out better than your first guess. Another hint: you will almost always get into trouble if your power estimate begins with the words, "This other device is similar, I am only adding/deleting."

What types of I/O will be required?
Optically isolated I/O and electromechanical relays are your enemy. Back-lighting and serial communications are not your friends. Limit the I/O and isolation to what is truly needed. Come up with clever ways to avoid having to keep LEDs and relays energized for long periods. Determine if displays can be turned off for extended periods.

How fast does it have to be?
Speed kills! As a general rule, if you double the speed, you double the power consumption. And here's a corollary that we often forget: if you double the bus width, you may also double the power consumption. Try to architect your system to run as slowly as practical in all operating modes. As with most embedded system designs, you will probably find that you cannot meet all of the initial criteria. A thorough understanding of the application is irreplaceable on such occasions. You, as the official techie on the scene, will be responsible for helping those you work with by recommending and explaining trade off opportunities.

Processor selection

Many processors claim to be low power, but which one is right for your design? Remember when you only had to worry about the availability of tools, cost, speed, and integration? In the realm of low-power designm you can kiss those simple times good-bye. While looking at the processor's data sheet, you need to ask several questions.

Does the processor have a static or dynamic core?
Processors that have dynamic cores generally don't respond well to reduced speed or stopped clocks. If the data sheet does not clearly state what type of core the processor is designed with, check the specification for f_osc(min). If it is 0, or there is no specification for t_cycle(max), you can most likely slow down the processor as much as you want.

How much power will the I/O and the bus consume?
Look at the leakage currents on the various I/O and bus pins that you are considering. These parameters will be listed in the data sheets as I_IL, I_IH, or input leakage current. Remember that different input pins can have different leakage currents, and that leakage can vary depending on the state of the pin.

Can the clock speed be changed on the fly?
Internal programmable phase locked loops (PLL) for clock generation make the job of controlling power consumption much easier. These allow the processor to dynamically change the speed of operation based on instantaneous demand for computing power.

What is the nominal supply current?
Look at I_DD, this seems obvious, so don't forget. On a processor designed for low power systems this will often be given in the form of a graph of current vs. operating frequency. There may also be specifications for various sleep and low power modes.

Is the sleep mode practical for your application?
Read everything you can about the sleep and low-power modes supported by the processor. Some of the nasty surprises you don't want to discover after you have committed to using a particular device include slow wake up times and power-down modes that turn off a function that is critical to your device waking up. (That low power mode won't do much good if it turns off the on-chip UART and you have to wake up based on receiving characters on the serial port.)

Power consumed by modern CMOS devices is almost always dominated by how fast the device is being clocked. Figure 1 is a simplified diagram of a CMOS totem pole output driving a typical CMOS input.

Figure 1 CMOS output and input equivalent circuit

Each time the gate is switched from ground to V_cc, the capacitor must be charged. When the gate switches from V_cc back to ground, the capacitor must be discharged. Since this energy does not get reused (it is dissipated as heat in the driving gate), every change in state causes a little loss in energy. This loss can be expressed as P = fV_ccC_L, where P is the power loss, and f is the frequency. As you can see, speed kills.

Table 1 Example power consumption as a function of bus size
	16-bit Bus	8-bit Bus
	Bus cap (μF)	Power (mW)	Bus cap (μF)	Power (mW)
Address Pins	238	4.8	252	5
Data Pins	320	6.4	160	32
	Total:	11.2		8.2

Because this equation applies to every signal on a bus, it is easy to see why wide external buses should be avoided in low-power designs. Load capacitance can vary between pins, but are generally in the range of 4pF for an input to 12pF for a bi-directional pin. Table 1 illustrates the different levels of power consumption of a microprocessor connected to a 1Mbit flash device and operating with a 4MHz bus cycle, based on bus size. Looking at these numbers, it is easy to see how using a processor that has internal memory can substantially reduce power consumption.

Low-power I/O

Now that you've selected a low-power processor and added peripherals with the lowest quiescent currents you could find, marketing still wants more battery life. Let's face it, everyone always wants more battery life. Fortunately, you can help the situation. Asking the following questions should help you ferret out some more battery life.

What pull-up values are really needed?
The days of using 4.7K pull-up resistors are gone. Even if you use 62KW pull-ups in a 3V system, each one will pull 48μA when the output is driven low. If you only use 10 of them, 480μA is consumed right there. Start thinking of pull-ups with values in the 1MW range. Consider input leakage current and V_IH (or V_IL for pull-downs) when calculating the maximum possible value.

What parts of the device can be turned off?
If possible, shut down circuits that are used infrequently, then resurrect them when needed. Choosing low power components is great. But if you can switch off power to portions of your circuit, you can even save the quiescent current. When evaluating areas where this may be performed, keep in mind:

• Duty cycle of use vs. inactivity
• Stabilization of V_cc when power is reapplied
• Overhead required to control power

Any of these areas may be a reason to keep power applied.

Is dead really dead?
Watch out for zombies. When you try to reduce power consumption by removing V_cc from sections of your design, some parts may try to come back to life on their own. Digital inputs tend to have a protection diode (see Figure 2), which internally connects input pins to V_cc. This diode prevents input voltages from getting more than a few tenths of a volt above V_cc. Consequently, the part will be powered by leaving an input high when you float V_cc.

Figure 2 CMOS input protection

Are all of the pull-up resistors required all of the time?
Consider removing power from pull-ups. If a signal associated with a pull-up is polled, there is a good chance that the pull-up is wasting power most of the time. This goes back to examining the use duty cycle and limiting quiescent currents.

Should you use a pull-down instead?
Look at the state you expect an input to be in most of the time. If it will be reliably low most of the time, consider using a pull-down resistor rather than a pull-up.

Do you really need that buffer?
Ask this question when looking at signal drive power. Components that overdrive signal lines tend to consume more power on transitions than parts with lower drive capabilities. Obviously, you want to avoid under-driving signals or using buffers unnecessarily. But if power consumption is a concern some power can be saved by spending time choosing parts with an appropriate drive capability.

Saving power means more than selecting low-power parts. Most techniques revolve around reducing the average quiescent current of the design. Remove power from circuits (including pull-ups) when they aren't being used. Increase the value of pull-up resistors. Watch out for current sneak paths through a protection diode. These are all tools in extending battery life and reducing power consumption.