Smart embedded MCUs help attain energy efficiency
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.
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.
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 16bit solutions must be the best choice for low-energy applications. But the fact is that a modern 32bit 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 16bit CPU cores.
Since energy is 'power times time', using the 32bit Cortex-M3 in preference to a less powerful alternative can prove more energy efficient: particularly if the designer opts for an MCU that even in active mode consumes only 150µA/MHz. In short, 'low power' does not necessarily mean 'low energy'.
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, sub-systems 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.
|Related Articles||Editor's Choice|