| Maximizing battery life in next-gen handhelds |
by Nathan Tennies & Andrew Girson (Dec. 9, 2002)
Maximizing battery life requires intentional software design and knowledge of how a handheld will be used. This comprehensive technical overview hones in on the things to keep in mind when your engineering team is designing its next-generation device.
Battery life is obviously one of the most important parts of the user’s experience with a handheld device, yet too often it is dictated primarily by other decisions made earlier in the design process: the processor selected, the physical dimensions of the handheld, the display selected, the peripherals included, the planned cost of the unit, etc. In the end, the embedded engineering team is left to maximize the battery life of a device without making significant changes to the hardware selected or the parts budget for the device.
Despite this, battery life is frequently misunderstood or misrepresented. In fact, so many variables come into play that embedded engineers cannot effectively estimate battery life simply by looking at the hardware; how the software running on the device is written and the way in which the device is used must also be taken into account.
In addition, to maximize battery life, you have to understand which parameters affect power consumption and which tools are at your disposal. Some of these parameters are obvious, others less so. You have a great deal of control over the power consumption of your device designs, and while it may be obvious that hardware design plays a key role in power consumption, software is just as important.
The Big Sleep
Increasingly, the microprocessors used in handhelds and other low-power embedded devices support special operating modes designed to conserve power while maintaining the usability of the device. In fact, in some cases, these modes can be—and should be—employed without the user of the handheld ever knowing that they have been invoked. Taking full advantage of these low-power hardware features, however, requires software intentionally designed to support them.
A great example of this is Sleep mode, which turns off the processor’s core and peripherals but continues to power external interrupts and important internal registers, such as the real-time clock. While operating systems targeted at the handheld market usually support Sleep mode, minimizing power consumption in Sleep mode requires conscientious work on the part of both electrical and software engineers.
When the handheld’s operating system determines that Sleep mode should be entered—as a result of the user pressing the device’s power button or after a period of inactivity—it calls power management functions in the drivers and kernel which you can use to place the device into the lowest-possible power state. While this can mean something as simple as turning off power to a peripheral, there are other techniques as well that may not be obvious at first glance.
For instance, you should consider how your peripherals and I/O pins will act in Sleep mode. If you configure an I/O pin as an output and it is pulled up to Vcc, leaving this pin programmed to a logic zero when going into Sleep mode will cause current to flow through the pull-up resistor in Sleep mode, wasting power. Most handheld CPUs allow you to designate whether their I/O pins are inputs or outputs, and whether outputs should be set to a low or a high logic level, allowing you to properly configure these pins for minimum power consumption when entering Sleep mode.
Since a handheld device can spend hours, days, or even weeks in the off state without changing the batteries, how you configure the device in Sleep mode is critical. Although even Sleep mode causes the processor to continue to consume some power after the user “turns it off”, these simple steps can mean the difference between a handheld that has a shelf life of days or a shelf life of weeks.
You’re Blocking
Another power-saving mode with good operating system support is Idle mode, which shuts down the instruction processing portion of the processor’s core while continuing to power the rest of the chip (peripherals continue to be serviced, DRAM is maintained, all interrupts continue to be enabled). When an interrupt occurs, the processor leaves Idle mode and picks up executing instructions where it left off.
One of the most important features of Idle mode is that it has very low overhead. Unlike Sleep mode, which usually requires extensive shutdown and boot code support, Idle mode can be entered and exited almost instantly. On the other hand, because so much of the processor remains powered in Idle mode, it can’t compare with Sleep mode in terms of a power saving mode. As a result, Idle mode is usually incorporated into embedded software in a very specific way.
Modern multithreaded operating systems provide software engineers with functions that can be used to block execution of a thread pending an external event (such as an interrupt), an internal event (such as the change in the state of a mutex), or a timeout. If all threads running on a device make use of these functions, the operating system will be able to detect periods—perhaps very short periods—in which all threads are blocked. It is in these periods that Idle mode can be entered without any loss in performance.
What isn’t obvious is that Idle mode is often constantly in use on most handheld devices, even while they are being used. For instance, an application receiving regular serial data from a GPS peripheral may receive many small chunks of data before it is processed; even at high serial rates, several milliseconds may pass between chunks in which the receiving thread can block and Idle mode could be employed, assuming all other threads in the sysem were also blocked. Even an operating system with a 1 millisecond multitasking timer might still find several opportunities to place the processor into Idle within a single timeslice.
Saving power in such small quantities may not seem worthwhile until you realize that all these small periods in Idle mode add up, effectively reducing the average power consumption of your handheld even while it is in use. In fact, it’s possible to see average power consumption on some devices reduced by half using this technique alone. How much of the time your processor spends in Idle mode, however, depends on how you write your software.
For instance, a single thread in any running task that watches for a hardware state change using a polling loop—rather than using an operating system function to block the thread pending an interrupt—will prevent the processor from ever entering Idle mode, not to mention injuring overall performance on the device. The first challenge, then, is for embedded software engineers to design drivers and applications that allow the processor to enter Idle mode as often as possible by making intelligent use of multithreading and the thread-blocking features provided by the operating system.
Peripherals Matter
When it comes to making the most of Idle mode, the second challenge for embedded software engineers is to allow the processor, once placed in Idle mode, to stay there as long as possible. One of the best ways to do this is using direct memory access (DMA), a technique that all software device driver developers should use, but that many often ignore. Because DMA does not rely on executing instructions, Idle mode can still be employed while data is being sent to and received from peripherals.
In fact, with handheld devices, DMA gives you a double-whammy: not only can you reduce your computational bandwidth requirements by using DMA instead of interrupts for data transfers, but the resulting reduction in bandwidth requirements also decreases power consumption; fewer interrupts means more time in Idle. The challenge with DMA is that you may have to develop a technique—such as a DMA resource manager—to share a limited number of DMA channels between multiple peripherals.
Another technique is avoiding the generation of unnecessary interrupts. Remember that most CPUs that support Idle mode are brought out of it by an interrupt. This makes sense when the interrupt is something relevant, like a key press. But a stray interrupt that is not properly disabled can cause an unintended exiting of Idle mode, which usually causes the operating system’s task scheduler to be run again. Even if it has little impact on performance, it can have a noticeable impact on power consumption by reducing the amount of time spent in Idle mode.
One of the best examples of this technique involves the multitasking timeslice timer itself. An operating system that uses a simple 1 millisecond multitasking timer will wake itself out of Idle mode 1000 times every second even if all threads are blocked. While you wouldn’t want to disable the timer completely—some threads may be blocking for a specific period of time rather than waiting on an event—a better approach supported by some operating systems is to employ a variable timeslice timer. In this case, when entering Idle mode, the operating system determines the earliest time that any thread is scheduled to run, and the embedded developer can use this information to adjust the multitasking timer accordingly.
Balancing Performance and Battery Life
Another area to consider, especially with the latest CPUs, is the software-based dynamic adjustment of core voltage and clock frequency at run-time. If you can accurately measure CPU computational bandwidth, and you find that you are using less than 100% of it, you can decrease the clock frequency and the core voltage. In many cases, reducing the clock frequency will result in a corresponding increase in the amount of time that it takes the CPU to complete a task. But, as long as the CPU computational bandwidth stays below 100%, the perceptible change in performance to the user may be negligible.
For example, if your handheld device is being used in an application that makes external measurements several times per second and updates the display, such a task might require 20% of the CPU’s bandwidth at 200MHz. At 100MHz and a lower core voltage, the task might require 40% of the computational bandwidth, but to the user, the display still gets updated in the same manner and at the same rate. Since the voltage is reduced and power consumption varies with the square of the voltage, the overall power consumption is reduced with little or no perceived performance degradation.
And, in some cases when computational bandwidth reaches 100%, you may still wish to reduce clock frequency, because the performance bottleneck is not the CPU. For example, if you are transferring a large file to a plug-in Flash card, the Flash card’s write cycle typically dictates the speed of writing. In this case, the Flash card’s device driver often will be in a loop waiting for the card to report a ready signal for the next buffer of data. It typically will not yield to the operating system, since the delays between ready signal activation are short and varied in length. In this case, whether the CPU is operating at 200MHz or 100MHz, the bulk of the time is spent waiting for the Flash card, and the CPU computational bandwidth is close to 100%. There’s just no point in processing wait loops at 200MHz, when 100MHz will get the job done just as quickly and with reduced power consumption (see sidebar “Power and Plug-Ins: Peripherals Make a Difference”).
This Flash card example brings up an important point. Avoid spinning in loops waiting for an event, whenever possible, whether it’s in application software or device drivers. If you are waiting for some external event to signal you, and that event might take more than a few hundred microseconds or so, your thread should yield to the operating system so that it can schedule other threads or put the CPU into its Idle mode.
What Next?
There are many other examples, too. For instance, you could adjust CPU performance to keep total power consumption below a certain threshold? Batteries discharge in a non-linear fashion that is dependent on the power consumption, so an increase in the device’s current draw reduces battery life by a greater proportion, especially in applications with a high current draw relative to the battery’s capacity. Reducing a CPU’s clock frequency may extend the time it takes to finish tasks, but keeping power consumption below a certain threshold can extend battery life.
Or what about adjusting performance based on physical location? The coming wave of location-aware handhelds could increase or decrease performance based on entering or leaving a certain perimeter where increased or decreased activity is expected.
Related to this is wireless connectivity (Figure 1). Some IEEE 802.11b wireless PCMCIA cards have a power management mode that causes them to listen for wireless data at specified intervals instead of doing so at all times. The reduction in power consumption while in this power management mode can be substantial, while the performance difference is often negligible.
Figure 1: This graph shows the increase in power consumption when a PCMCIA-based IEEE802.11b wireless card is inserted into a handheld device. The card is inserted and removed twice during a 50 second interval. Instantaneous measurements are made once per second and graphed without averaging.(Also, see “Power and Plug-Ins: Peripherals Make a Difference” for additional information).
All of these examples merely serve to illustrate the simple fact that a conscientious software developer taking a holistic approach can always find new ways to conserve extra milliwatts here and there.
Power and Plug-Ins: Peripherals Make a Difference
To get a better handle on some of the issues discussed in the main article, you can perform measurements of power and energy consumption under different operational scenarios for your handheld device. Perhaps the simplest way to do this is to insert a standard voltmeter and an ammeter at the battery interface with the main board. As these meters typically provide measurements 1-2 times per second, this approach can give you a good measure of average power consumption. Instantaneous power consumption measurements require using an oscilloscope or similar instrument. For boards that have smart battery circuitry, you may be able to measure instantaneous voltage and current in-circuit and correlate it directly with run-time activities.
To demonstrate how these measurements might work, we used a voltmeter and an ammeter to perform some measurements on one of our company’s StrongARM-based handheld platforms. Because these measurements were averaged, they are not intended to provide detailed power and energy consumption measurements but rather are intended to demonstrate some of the general issues associated with quantifying and understanding power consumption and performance.
The first experiment involved transferring large data files between a PCMCIA-based ATA-Flash card and the device’s DRAM-based file system. All tests were completed using Microsoft’s Windows CE 3.0 operating system, and the results are generally going to be applicable with other operating systems as well.
In the file transfer experiment, an 8MB data file was moved from the Flash card to the DRAM-based file system, and then was moved back to the Flash card. The test was done at different CPU speeds (note that core voltage was not varied in these experiments).
First, let’s analyze the Flash-to-DRAM transfer as shown in Table 1. In this case, performance is largely driven by the CPU’s speed, because the CPU must pull the data from the card and then use the file system software drivers to determine where to put it in DRAM. So, as CPU speed decreases, we see an increase in the time required to perform the task. And, while power consumption drops with the reduced CPU speed, the total energy consumption – which is the true measure used for battery life – increases because of the increase in time required to perform the task. So, in this scenario, it generally makes more sense to run the CPU at a higher speed and get the task done faster.
Table 1: The time and energy required to transfer a large file from an ATA-Flash card to a DRAM-based file system is related to core clock frequency.
But, as detailed in Table 2, when the transfer is turned around, the resulting numbers paint a very different picture. In the transfer from DRAM to Flash, the speed of transfer is no longer determined by the CPU. Now, the bottleneck is the Flash card itself, because it must endure write cycle delays as the data is burned into the card’s on-board Flash memories. In this scenario, while the transfer at high clock speed takes about the same amount of time as the transfer at low clock speed, the total energy consumption is about 13% higher for the higher clock speed. In this case, it makes more sense to slow the CPU clock during the transfer.
Table 2: The time required to transfer a large file from a DRAM-based file system to an ATA-Flash card is less dependent on core clock frequency, but energy requirements increase at the higher core clock frequency.
There are other examples as well. Consider the situation when using an IEEE 802.11b PCMCIA card. Some of these cards have a power saving mode, but typically it is not enabled by default. Table 3 shows measurements of power consumption when enabling and disabling the power management mode of the card. The difference is rather large, but does it result in a significant degradation in performance? We generally found that the difference in performance was small, if non-existent when browsing the web on the handheld. A complex web page with graphics loaded in about 6 seconds whether power management was enabled or not. In this case, power management mode makes a lot of sense. Of course, there may be applications in which power management mode does not make sense, such as when desiring a quick response at startup or for short bursts of data.
Table 3: The handheld platform with an IEEE 802.11b PCMCIA card plugged in but without power management enabled consumes a great deal more power than when power management is enabled.
It really depends on your application environment. You can adjust power consumption based on CPU bandwidth usage, internal and plug-in peripheral activities, or many other parameters. That’s why it’s so important to understand the variables and apply them appropriately.
About the authors: Nathan Tennies is director of software engineering and Andrew Girson is chief executive officer of Inhand Electronics Inc. The Rockville, Md.-based company provides hardware and software reference platforms for developers of next-generation handheld devices.
Download the presentation in pdf fomat here.
Copyright (c) 2002 InHand Electronics. All rights reserved. Reproduced by WindowsForDevices.com under license.
(Click here for further information)
|
|
|
news feed