Design Article
Embedded MCUs get smarter as energy efficiency takes centre stage
Jo Stein Haugen, Energy Micro
11/27/2012 1:32 PM EST
Energy efficiency is increasingly being recognized as a key performance attribute of many electronic systems – and of embedded designs in particular. In products ranging from smart meters to wireless sensor nodes and from mobile health monitors to intruder alarms, designers need to take every step possible to limit energy consumption.
The detailed operational and design requirements of such applications may vary, but they share a common feature: they need to operate reliably over a period of years or even decades while using the limited energy resources available from batteries or an energy harvesting system. At the heart of designers’ efforts to achieve this are a new generation of microcontrollers (MCUs) specifically designed with energy efficiency in mind.
It is worth considering in more detail the scale of the design challenge involved. Many of these microcontrollers must deliver real-time (or close-to real-time) performance throughout a service life that is spent predominantly in a low-power sleep mode that inherently reduces their speed of response to external events. A device such as a smart meter will often be buried or otherwise difficult to access, requiring 10 to 20 years of operation on a single battery (Figure 1).
As a result, energy budgets in such applications are aggressively trimmed. Given the current state of battery technology, it is not unusual to see an energy requirement for the lifetime average current draw to be between 5µA and 20µA. If a system designer budgets 20% of the available battery capacity for data collection and ‘housekeeping’ functions, 20% for receiving commands, and 30% for transmitting data, then the remaining 30% must support the system’s idle mode. This may sound generous, but the meter will likely spend in excess of 99% of its life in some kind of sleep state, whose efficiency becomes absolutely crucial in reaching the design targets.
Figure 1. Smart meters need to operate for many years on a single battery.
This is why sleep modes are one of the most important features of a low-power MCU, and a feature that we will revisit later. But first, it is worth considering what factors makes a ‘good’ energy saving MCU.
In the past there has been a somewhat casual assumption that because of their lower active power consumption, 8- or 16-bit solutions must be the best choice for low-energy applications. But the fact is that a modern 32-bit CPU core like the ARM Cortex-M3 delivers a processing power of 1.25 DMIPS/MHz; that is, it can perform a given task in around one quarter of the time required by older 16-bit CPU cores.
Since energy is ‘power times time’, using the 32-bit Cortex-M3 in preference to a less powerful alternative can prove more energy efficient: particularly if the designer opts for an MCU such as Energy Micro’s Tiny Gecko, that even in active mode consumes only 150µA/MHz. In short, ‘low power’ does not necessarily mean ‘low energy’.
Figure 2. Designers demand compact and low-energy solutions.
As we have observed, however, an energy efficient processor stands and falls on its sleep modes – and the designer’s ability to choose the right mode of operation for the job. In a power-constrained application, subsystems such as displays and RF and PHY-layer transceivers will be designed to spend only as much time as is absolutely necessary in their active state: MCU functions will therefore represent the only “low-hanging fruit” for power optimisation.
Most modern MCUs have more than one low-power mode (these will typically be something like: “Sleep/Standby”; “Deep-Sleep”; and “Off”). The specific CPU, memory, and I/O functionality available will vary from microcontroller to microcontroller, but the general principles involved remain the same.
Although it may appear that it would make sense to use the deepest possible sleep mode in every case, there is in fact a trade-off involved: the deeper the sleep, the longer the wake-up overhead. The overhead consists of hysteresis and propagation delays in the wake-up circuitry, start-up and stabilisation of the power supply and re-starting the CPU clock. The device then needs to restore its registers and other internal configurations, before doing the same for system memory. Only when these processes are completed can the MCU service the event that triggered the wake-up process.
This trade-off has two implications: first, if the MCU is in an overly deep sleep mode, it may not be able to wake up in time to deal with an external event; second, during the wake-up phase the device doesn’t do any useful work. So waking too frequently from a deep sleep mode in order to perform a small amount of processing could conceivably burn more power than staying in a “higher” activity state with less time wasted on the wake-up process.
If there is a need to deal with unpredictable events it is much more difficult to reduce power consumption than for scheduled events such as real-time clock interrupts, or the time-slotted communications processes common in ZigBee and other mesh protocols, that require the processor to check for messages from other network nodes at a certain time.
Unfortunately, most applications involve events of the less predictable type, and require the MCU to respond in real time - or at least almost real time. Examples include threshold/alarm conditions, power interruptions, and wireless protocols that can transmit and receive at random intervals. In such situations, failure to wake within an appropriate timeframe may mean losing critical data or failing to respond to a user command. In the worst case, there may be a risk of system damage if an alarm condition is not dealt with in a timely fashion.
The task for the designer is therefore to find the lowest-power sleep mode that provides adequate response to anticipated (if unscheduled) events. Energy Micro’s EFM32 Gecko family of energy-optimized 32-bit MCUs provides a good example of the options available. Although the Gecko architecture is optimized to perform beyond the basic requirements of each mode, most MCUs used for these types of applications have similar operating states and characteristics (Figure 3).
Figure 3. The EFM32 family’s energy mode transitions
(most alternative architectures combine EM2 and
EM3 in a single ‘deep sleep’ mode).
At the lowest level, most MCUs have a mode designated as “off” or shut-down mode, that preserves the minimum functionality needed to trigger wake-up from an external stimulus: in our example of the Gecko series, this is designated EM4. In this mode, the entire device is powered down, other than the interrupt monitoring circuitry on the reset pin and GPIO pin wake up. The EFM32 draws around 20nA of current in this mode, although a typical 32-bit MCU would require nearer 1.5µA.
Restarting from such an “off” mode is essentially a device reset, a process that for the EFM32 takes around 160µs. Main memory contents will have been lost and must be re-loaded. Some processors include a small (512byte in the case of the EFM32) block of memory whose content is preserved for use on start-up.
The detailed operational and design requirements of such applications may vary, but they share a common feature: they need to operate reliably over a period of years or even decades while using the limited energy resources available from batteries or an energy harvesting system. At the heart of designers’ efforts to achieve this are a new generation of microcontrollers (MCUs) specifically designed with energy efficiency in mind.
It is worth considering in more detail the scale of the design challenge involved. Many of these microcontrollers must deliver real-time (or close-to real-time) performance throughout a service life that is spent predominantly in a low-power sleep mode that inherently reduces their speed of response to external events. A device such as a smart meter will often be buried or otherwise difficult to access, requiring 10 to 20 years of operation on a single battery (Figure 1).
As a result, energy budgets in such applications are aggressively trimmed. Given the current state of battery technology, it is not unusual to see an energy requirement for the lifetime average current draw to be between 5µA and 20µA. If a system designer budgets 20% of the available battery capacity for data collection and ‘housekeeping’ functions, 20% for receiving commands, and 30% for transmitting data, then the remaining 30% must support the system’s idle mode. This may sound generous, but the meter will likely spend in excess of 99% of its life in some kind of sleep state, whose efficiency becomes absolutely crucial in reaching the design targets.
Figure 1. Smart meters need to operate for many years on a single battery.
This is why sleep modes are one of the most important features of a low-power MCU, and a feature that we will revisit later. But first, it is worth considering what factors makes a ‘good’ energy saving MCU.
In the past there has been a somewhat casual assumption that because of their lower active power consumption, 8- or 16-bit solutions must be the best choice for low-energy applications. But the fact is that a modern 32-bit CPU core like the ARM Cortex-M3 delivers a processing power of 1.25 DMIPS/MHz; that is, it can perform a given task in around one quarter of the time required by older 16-bit CPU cores.
Since energy is ‘power times time’, using the 32-bit Cortex-M3 in preference to a less powerful alternative can prove more energy efficient: particularly if the designer opts for an MCU such as Energy Micro’s Tiny Gecko, that even in active mode consumes only 150µA/MHz. In short, ‘low power’ does not necessarily mean ‘low energy’.
Figure 2. Designers demand compact and low-energy solutions.
As we have observed, however, an energy efficient processor stands and falls on its sleep modes – and the designer’s ability to choose the right mode of operation for the job. In a power-constrained application, subsystems such as displays and RF and PHY-layer transceivers will be designed to spend only as much time as is absolutely necessary in their active state: MCU functions will therefore represent the only “low-hanging fruit” for power optimisation.
Most modern MCUs have more than one low-power mode (these will typically be something like: “Sleep/Standby”; “Deep-Sleep”; and “Off”). The specific CPU, memory, and I/O functionality available will vary from microcontroller to microcontroller, but the general principles involved remain the same.
Although it may appear that it would make sense to use the deepest possible sleep mode in every case, there is in fact a trade-off involved: the deeper the sleep, the longer the wake-up overhead. The overhead consists of hysteresis and propagation delays in the wake-up circuitry, start-up and stabilisation of the power supply and re-starting the CPU clock. The device then needs to restore its registers and other internal configurations, before doing the same for system memory. Only when these processes are completed can the MCU service the event that triggered the wake-up process.
This trade-off has two implications: first, if the MCU is in an overly deep sleep mode, it may not be able to wake up in time to deal with an external event; second, during the wake-up phase the device doesn’t do any useful work. So waking too frequently from a deep sleep mode in order to perform a small amount of processing could conceivably burn more power than staying in a “higher” activity state with less time wasted on the wake-up process.
If there is a need to deal with unpredictable events it is much more difficult to reduce power consumption than for scheduled events such as real-time clock interrupts, or the time-slotted communications processes common in ZigBee and other mesh protocols, that require the processor to check for messages from other network nodes at a certain time.
Unfortunately, most applications involve events of the less predictable type, and require the MCU to respond in real time - or at least almost real time. Examples include threshold/alarm conditions, power interruptions, and wireless protocols that can transmit and receive at random intervals. In such situations, failure to wake within an appropriate timeframe may mean losing critical data or failing to respond to a user command. In the worst case, there may be a risk of system damage if an alarm condition is not dealt with in a timely fashion.
The task for the designer is therefore to find the lowest-power sleep mode that provides adequate response to anticipated (if unscheduled) events. Energy Micro’s EFM32 Gecko family of energy-optimized 32-bit MCUs provides a good example of the options available. Although the Gecko architecture is optimized to perform beyond the basic requirements of each mode, most MCUs used for these types of applications have similar operating states and characteristics (Figure 3).
Figure 3. The EFM32 family’s energy mode transitions
(most alternative architectures combine EM2 and
EM3 in a single ‘deep sleep’ mode).
At the lowest level, most MCUs have a mode designated as “off” or shut-down mode, that preserves the minimum functionality needed to trigger wake-up from an external stimulus: in our example of the Gecko series, this is designated EM4. In this mode, the entire device is powered down, other than the interrupt monitoring circuitry on the reset pin and GPIO pin wake up. The EFM32 draws around 20nA of current in this mode, although a typical 32-bit MCU would require nearer 1.5µA.
Restarting from such an “off” mode is essentially a device reset, a process that for the EFM32 takes around 160µs. Main memory contents will have been lost and must be re-loaded. Some processors include a small (512byte in the case of the EFM32) block of memory whose content is preserved for use on start-up.
|
|
|
|
|
Navigate to related information
vediappan
11/27/2012 9:32 PM EST
excellent message
Sign in to Reply