The advent of inexpensive, energy-efficient embedded processors and smart-object technologies has fueled the growth of intelligent distributed networks for applications for smart buildings, the Smart Grid, and environmental monitoring. The same technologies also are being used to add intelligence to existing products such as utility meters and health-monitoring and portable medical equipment.
While the operational and design requirements vary widely, all of these applications must operate reliably for years using the limited energy resources available from their batteries or energy harvesting systems.
Many of these applications such as smart wireless water and gas meters, which may be buried or otherwise difficult to access, present significant design challenges. To achieve service lives of 10 to 20 years, they use batteries with specialized low-leakage chemistries that can cost $0.75/Wh or more.
As a result, the meter’s energy budget must be aggressively trimmed to maintain pricing that’s competitive in the global marketplace. Even when a system is accessible, like the condition-monitoring system for a shipping container, it isn’t realistic to expect it to be maintained more than a few times during a 20-year service life, if at all.
Therefore, microcontroller power budgets averaged over the device’s lifetime of 5 to 20 µA are common. A typical design might have an energy budget that allocates 20% of the available capacity to transmit activities, 30% for receiving commands, and 20% for data collection and system maintenance.
This leaves a mere 30% of the battery’s capacity to support the system’s idle mode. At first glance, this may seem a high proportion of the total battery life dedicated to doing no useful work. The problem is that the device will spend more than 99.9% of its life in this mode.
The Path To A Solution
If a power-constrained application is properly implemented, most energy-intensive subsystems such as radio-frequency (RF) transceivers and displays will be designed to spend only as much time in their active state as they need to. A wireless sensor node will have a tight transmit and receive window. The system will attempt to send and receive only at predefined times to minimize the energy needed to listen for incoming packets.
Similarly, most sensor inputs only need to be sampled at intermittent intervals. So, it’s likely that the MCU will be idling for much of its time in between these events. The key to low-power design is not to simply let the MCU run in an idle loop but to put it into an appropriate sleep mode.
Time is the enemy in any battery-powered application. Even apparently small power consumption values become significant over long periods. During periods of activity, CV²f provides the power consumption of any logic, where C is the total capacitance of the circuit paths within the device, V is the supply voltage, and f is the operating frequency.
The situation is slightly complicated by the widespread use of clock gating in most modern processor cores, which limits switching activity in unused logic by temporarily disabling the clock signal to those circuits. However, the formula provides a good approximation to active power consumption. The fewer transistors that are powered during a given period, the lower the power consumption will be.
Multiple Low-Power Modes
Most modern MCUs have more than one low-power mode, ranging from a light sleep or standby mode through deep-sleep to off. Each has a progressively lower level of CPU, memory, and I/O functionality as more peripheral blocks are switched off (Fig. 1).
The specific functionality of each idle, sleep, and deep-sleep mode varies from processor to processor, but the principles remain basically the same. Generally, the deeper the sleep, the less power the MCU consumes.
To provide an example of the difference in power, an Energy Micro EFM32 Tiny Gecko consumes 12.6 mW while running fully active at a clock frequency of 28 MHz and a supply voltage of 3 V. In its lowest-power mode, the same device consumes 60 nW—orders of magnitude lower.
However, the power savings available from lower-energy sleep modes come at a price. Waking from a deeper-sleep mode takes more time due to the time it requires for certain types of circuitry to restart (see “Wakeup Time Versus Power Consumption: Evaluating The Tradeoff”).
For example, analogue circuits such as phase-locked loops (PLLs) that are used to generate the clock used by the processor core and other peripherals are best powered down when the blocks they drive are expected to be inactive. PLLs call for a constant current to maintain a lock. But, when starting up, it takes time before the circuit is ready to provide a stable clock signal.
When a processor core is fully powered down, its software state must be saved to memory—either battery-backed SRAM or flash. Restoration will take a number of memory cycles as this state data is fetched from the backup memory.
A lighter sleep mode may keep the PLLs running and the core registers powered, albeit at a lower voltage to allow them to “drowse” with a lower power draw than during normal operation. Therefore, the length of this wakeup period is an important consideration in selecting a particular sleep mode, both from the points of view of power consumption and effectiveness of operation.
Power Versus Response Time
One of the primary ways to optimize a low-power embedded design is to find the lowest sleep mode that provides an adequate response to real-time events. A good example is a battery-powered module that monitors the conditions experienced by a GPS-enabled cargo-shipping container during transport (Fig. 2).
The first step is to list all the alarm/alert conditions generated by the application and identify the one that can tolerate the shortest time before it is serviced. The container monitor is typically equipped with a GPS receiver, temperature sensors, contact switches to detect tampering, and accelerometers to measure the bumps, jolts, and shocks that occur along the way. It is also usually equipped with one or more radio interfaces, according to the application’s requirements.
Under normal circumstances, the MCU will remain in sleep mode most of the time, emerging for a few milliseconds every 10 or 15 minutes to record temperature conditions. Activity from the tamper detect switches does require attention in real time, but the window of timely response to that event is measured in hundreds of milliseconds or even seconds.
The processor must, however, be able to wake up and begin measuring shock and vibration levels within a millisecond or less of the time its accelerometer inputs exceed a pre-programmed threshold level.
For each standby, sleep, and deep-sleep mode, the next step is to add up all the delays involved between the time the alert or alarm condition is generated and the time the MCU is ready to begin attending to it. Continuing with the example of the shipping container monitor, it is safe to assume that the accelerometer sense/comparator circuitry has little or no delay.
Depending on the sleep mode it’s in, though, the MCU will experience delays ranging from a few microseconds to hundreds of milliseconds before it can begin paying attention to the alarm event that woke it up.
Adding the execute time of the code required to service the alert or alarm condition provides the total delay between a critical event and the time the MCU responds. The length of this part of the application code will vary widely from application to application. It will also depend on whether the MCU must go through an interrupt service routine (ISR) or jump directly to the code that deals with the event at hand.
At that point, the designer can compare these needs with the maximum time of recovery from each sleep mode and identify the lowest-power mode that falls within the application’s maximum tolerable delay.
It is also essential to verify that the sleep mode selected has the resources required. For example, if the application requires an RTC, it cannot go below deep sleep, because the RTC will often be disabled in extreme low-energy modes.
Armed with this information, it is possible to accurately predict how well a given MCU will perform over its lifetime on a single battery charge and to make an intelligent choice on which architecture to use.
Designers often need to perform detailed analysis to evaluate the interactions between response time and the savings achievable from different sleep modes. Tools like the energyAware Profiler in Energy Micro’s Simplicity Studio provide an effective and inexpensive way of assessing how these interactions will play out.
The energyAware Battery Estimator provides a full simulation of total system energy usage that account for actual battery source, MCU energy modes, peripherals employed, and external circuit components (see the figure).
In simulation mode, system battery voltage output is displayed against time (years) in graph format, with the battery capacity rating (mAh), average MCU current consumption (µA), and estimated system operating time (years) shown numerically alongside.
An intuitive GUI allows the setup of a complete system simulation, its energy modes, their related operating times and associated peripheral functions, and external component current consumption.
Battery Estimator can model the performance of the seven most popular battery cell types, arranged in single-cell or user-defined multiple cell series-connected or parallel-connected configurations. The tool allows the selection and analysis of all five energy modes of the EFM32 Gecko MCU used with the complete range of low-power peripheral functions available as well as high-frequency and low-frequency clocks. The facility to factor in the current consumption from any external power hungry components, such as LCDs or speakers, further increases the accuracy of the battery life prediction.