Assessing real-world MCU energy efficiency

The age of the Internet of Things (IoT) will see the development and deployment of billions of intelligent nodes tasked with monitoring, evaluating, controlling and reporting on every aspect of modern life. These IoT nodes will be essential in the way we interact with our environments and in the way our environments adapt to fit our needs and help us through our daily lives. The nodes that make up the IoT must provide an “always on” service combined with a “deploy and forget” solution. They will be expected to monitor constantly and respond immediately to any relevant events, while operating under very constrained energy budgets.

Running on small form-factor batteries, the nodes must be able to operate for years on the same battery, and where energy harvesting is possible, the nodes must keep operating even when there is little ambient energy available to harvest. This means ultra-low energy operation will be a key parameter for the IoT nodes, and great care must be taken to select components that minimize the real-world current consumption of the node.

Almost Always Off
IoT nodes and similar applications must provide the illusion of being “always on,” but they must be designed to be “almost always off” to maximize their lifetime from a limited power supply.

An IoT node is built from a number of different semiconductor components. Sensors gather information from the environment, such as temperature and humidity, and also gather user input. One or more communication interfaces, such as USB or a Bluetooth Smart radio link, can allow the node to communicate with the cloud (the Internet) or other nodes, such as the user’s smart phone. Actuators enable the node to alter its environment and also give feedback to end users through LCD displays or audio alerts.

For any node, a level of determinism is expected. A touchscreen must respond to user input immediately. A radio interface must adhere to the timing requirements of the radio protocol, which in some cases can be very strict. A heart rate sensor must never miss a beat. In all cases, functionality must appear continuous to the user or to any other device communicating with the node.

Taking sensors as an example, minimizing current consumption is based on two factors: how much current the sensor consumes while active and how often it must remain active. The required duty cycle will vary based on the type of sensor used in the node. A heart rate sensor could require sampling at 50 Hz to get a good reading of your pulse, while a temperature sensor in a smart thermostat might only have to be sampled once every second because of the slower dynamics of the temperature in a home.

The duty cycle can also vary depending on what state the application is in. A smart watch, for example, might turn off almost all of its sensors if it is experiencing inactivity, only sampling an accelerometer once a second to determine if activity is present. Whenever activity is detected, the smart watch springs to life, increasing sample rate significantly to more accurately track the activity.

In all cases, significant energy savings are achieved by duty-cycling the components in an application, making sure they are only on when they are strictly needed. There is, however, one component that is rarely turned all the way off: the microcontroller (MCU), as seen in Figure 1. This device is responsible for controlling all the other components in an application, and it also makes sure they are off or in a low-power state when they are not needed. Given that the MCU also integrates a host of functions that must be orchestrated, it follows that the MCU must be specifically architected for low-energy operation to enable the MCU to keep full control of the application while consuming as little energy as possible.


Figure 1. The MCU is the heart of an application, controlling all other devices, from RF to energy management to sensor interfaces.

Next page >

Minimizing MCU current consumption is all about making the MCU sleep as much as possible while still allowing it to carry out its tasks. The difference in current consumption between an MCU in active mode and deep sleep can easily be more than three orders of magnitude, ranging from single to double-digit milliamps in active mode, as shown in Figure 2, to below one microamp in sleep modes for the most energy-efficient MCUs.

To put this into perspective, many smart watches today have batteries with close to 200 mAh capacity. The batteries are generally quite small to fit inside space-constrained watch casings. Looking at the MCU alone, if it consumed 10 mA on average, as shown in Figure 2, the battery would last for 20 hours, but if the MCU went to a deep-sleep mode between activity, it could drastically reduce its average current consumption. State-of-the-art MCUs have useful sleep modes going down to 1 µA and below, and if we are able to reduce average current to 100 µA through proper duty-cycling, the battery would last about 8 days, as shown in Figure 3. The other components of an application will contribute to battery lifetime, but the current consumption can never be better than what the MCU is able to provide.


Figure 2. If attention is not given to MCU current consumption, the contribution of the MCU alone can often be tens of milliamps, drastically reducing the lifetime of a battery-powered application.


Figure 3. Duty-cycling the MCU core is the easiest way to improve energy efficiency, potentially giving significant energy savings. Duty-cycling is limited by what the MCU can handle autonomously while the core is sleeping.

Based on the energy savings possible from the deeper sleep modes of an MCU, it is obvious that an application would want to stay asleep as much as possible. The only problem is that every time the MCU must perform a function that the deep-sleep mode does not support, the MCU has to wake up to its high-power mode, consuming multiple milliamps. A true low-power MCU combines ultra-low-energy sleep modes, with the ability to perform application functions in these modes, or at least wake up quickly to the higher power modes so it can return quickly to the sleep modes.

The most energy-efficient MCUs are able to sustain the deepest sleep modes for long periods of time by providing the functionality the application needs in that mode as well as the ability to automatically duty-cycle other MCU functions without fully waking the MCU. MCUs with this capability enable the best battery lifetime as shown in Figure 4.


Figure 4. Keeping an MCU mostly in sleep mode (consuming 1
µA) can extend battery life beyond 20 years.

A growing number of MCU manufacturers claim to offer ultra-low-power operation, but the key to energy efficiency is, as we have seen, how well an application is able to leverage the MCU’s low-energy modes. An excellent sleep current is not useful if the application must stay in active mode to perform all of its duties. Unfortunately, there is currently no simple way of determining the optimal low-energy solution for a specific application, especially not by simply comparing MCU datasheets, as these often specify the functionality and performance of the various power modes of an MCU in very different ways.

The need for objective low-energy MCU benchmarking has attracted the attention of independent organizations intent on providing some resolution, such as EEMBC, which has recently released the first phase of its ultra-low power benchmark, ULPBench. However, while Phase 1 of the ULPBench primarily addresses power used by the CPU core in active mode and the real-time clock (RTC) in sleep mode, the ultra-low power MCUs expected to dominate in the IoT will be those offering a lot more functionality while the MCU is sleeping. Extensive support of autonomous peripherals enables the MCU to stay in the deepest sleep modes for extended periods of time while still supporting the application. Some of these aspects are planned to be added to the ULPBench benchmark in Phase 2, which will focus on some common peripheral usages in sleep modes.

When selecting an MCU based on ultra-low-power specifications, it’s important to heed the differences in the level of functionality offered in various modes when evaluating MCUs based only on a manufacturer’s data sheet. The data sheet often presents best-case figures based on configurations less likely to be viable in real-world applications.

Designing for Ultra-Low Energy
Many of the MCUs targeting the IoT are based on the same CPU technology,the ARM Cortex-M processors. These come in various forms, ranging fromthe Cortex-M0+, optimized for cost and power efficiency for simplerapplications, to the Cortex-M4, which is excellent for complex,high-performance applications requiring floating point and DSPoperations.

The ARM CPUs provide a starting point in terms of code size,performance and efficiency, but when it comes to the MCU’s actualcurrent consumption in active or deep sleep modes, many ultra-low-powercapabilities are entirely up to the MCU vendor. Active currentconsumption can be heavily influenced by process technology choices,caching, and the overall architecture of the MCU. MCU sleep current andthe peripheral functionality available while the CPU is sleeping areentirely up to the MCU’s design and architecture.

As signaled by the EEMBC’s Working Group for Phase 2 of the ULPBenchbenchmark, peripherals play a significant role in delivering ultra-lowenergy operation. In most applications, a certain amount offunctionality must be maintained at all times. A flow meter application,for example, might require monitoring rotation. For a control panel, itmight be registering the proximity of a finger. To achieve the lowestpossible application current consumption, an MCU must minimize thecurrent consumption of sensors and other components by duty-cycling themwhenever possible, as well as minimizing its own current consumption byproviding this functionality in deep-sleep modes with the CPU and otherhigh-activity peripherals turned off.

Sleep modes typically influence clocks, memory and peripherals, allof which can be turned off using clock- or power-gating in variouscombinations to provide incremental energy savings. The trade-off ofthis approach is normally response time. Simply turning off the CPU bygating the CPU clock can reduce current consumption significantly whilestill enabling an almost instantaneous wake-up. Using this technique,current consumption can go from multiple milliamps down to well below amilliamp, depending on the MCU and its clock frequency. The MCU canstill have all of its other functionality available as long as theperipherals are sufficiently autonomous, and there is a DMA engine orsimilar MCU feature that can feed peripherals with data.

To further minimize current consumption, power to the various MCUperipherals can be turned off, which can bring an MCU’s currentconsumption down to the range of single-digit microamps to hundreds ofnanoamps. There are multiple considerations in this approach. In oneextreme, all MCU functions can be turned off, allowing nearly zerocurrent consumption. In reality, this number will be a bit biggerbecause some components cannot be turned off, and power switches alsoleak. However, with all functionality turned off, the MCU is no longeruseful, and in a real-world application, this energy-mode can rarely beused, because it does not provide the functionality the applicationneeds. The deeper sleep modes of an MCU must balance the requirementsfor functionality with the resulting sleep currents. The MCUs thatachieve this in the best way are able to sleep the most and thus savethe most amount of energy.

Some MCU functions only indirectly contribute to the performance ofan application, but should still always be enabled in the deep sleepmodes. An example is the brown-out detector (BOD). The continuousoperation of the BOD is imperative to maintain reliable functionality orsafe shut-down in the event of an interruption in power. When a batteryor energy harvesting unit is used to supply the application withenergy, it is likely that the voltage might drop below the requirementsof the MCU during the lifetime of the application. This situation canalso occur in wired applications. Consider when a power outage causes aglitch in a wired supply. The supply might be lower than the requiredvoltage for a long enough time to corrupt the MCU, and without a BODturned on, the corrupted MCU will continue operating with undefinedbehavior. A BOD is critical in making sure the behavior of the MCU isalways well defined, even in the case of an unstable supply.

It is important to take the BOD current consumption into account whenevaluating the overall current consumption of an MCU. Not all MCUvendors list their energy mode current consumptions with the BODenabled. It is also important to take note of what types offunctionality are available in the deeper sleep modes. If the sleepmodes cannot support your application, it means the MCU will have tostay awake more often to provide this support, increasing applicationcurrent by multiple orders of magnitude.

Without access to comprehensive, independent and verifiable figuresfor energy consumption, developers must delve deeply into MCU datasheets to evaluate the energy consumption they would see in theirapplications, but even then the level of detail necessary may bemissing. For example, the sleep modes implemented by different MCUmanufacturers may not be directly comparable, making it difficult toevaluate energy efficiency fairly. Engineers may also make assumptionsbased on missing or omitted details about specific parts of the circuitthat are or are not affected in sleep mode. In that case, the onlyreliable solution is to measure consumption empirically under real-worldconditions. This effort becomes onerous if a developer is evaluatingmore than one MCU, which means benchmarks such as ULPBench will becomeinvaluable once they have evolved to a point where all features can beevaluated. Until benchmarks evolve to measure comprehensive system-levelpower consumption, developers who want to have confidence in the energyefficiency of their applications will need to conduct their ownresearch into low-power MCU features.

Ultra -Low Energy Techniques
Developing applications based on ultra-low-energy MCUs requires asharper focus on the following considerations: keeping operations asefficient and quick as possible when the core is active, and staying indeep-sleep modes as often and for as long as possible while stillmaintaining the application functionality. This equates to “almostalways off” from an energy consumption perspective, but still “alwayson” from a functional point of view. To be able to implement thisapproach, it is important to choose an MCU that provides functionalitysupporting these cases.

An MCU vendor can implement multiple techniques to improve activepower and efficiency. For example, by implementing local instructioncache, a CPU core can minimize its access to flash memory, which savesboth energy and time. An on-chip dc-dc converter can also be employed tomake operation from higher voltage sources such as a Lithium Polymerbattery more efficient. One of the bigger levers, however, is theprocess technology used to manufacture an MCU. For example, an MCU builton a 90 nm process can often reduce active power to less than one thirdof that of a 180 nm process.

Process node reductions pose their own challenges by increasingleakage, making it more difficult to implement deep-sleep modes in anenergy-efficient manner. An MCU can be manufactured in a very smallnode, e.g. 40 nm, to minimize active current consumption, but then sleepcurrent will be very high at those nodes. On the other hand, an MCUmanufactured on a mature process node, such as 180 nm, will provideexcellent sleep current, but active current will be relatively high. Itis important to make the right trade-off in selecting the optimalprocess node for a given MCU.

By default, when the core is in a deep-sleep mode, one or moreperipherals will still need to be active to maintain applicationfunctionality. This can includes monitoring key system parameters andstaying ready to respond with appropriate actions to events that mighthappen. As previously explained, the BOD is chief among theseperipherals and must consume as little current as possible. Otherperipherals are also required to make the sleep modes useful. In manyapplications, an RTC is needed for time-keeping. Applications also oftenneed to monitor sensors and capacitive touch buttons, wait for commandson a UART interface, and drive graphics to a low-power LCD display. Allof these functions must be able to run autonomously and handle acertain level of interactions on their own to minimize the CPU’s wake-uptime. To enable all of these functions, the MCU needs oscillators,regulators, bias-circuits and digital logic available while in deepsleep. In most cases, the MCU integrates these functions to minimizeapplication footprint and system cost, and these function blocks must beextremely energy efficient.

Asynchronous behavior is also important as it allows the MCU torespond quickly to external events even in deep-sleep modes. Normally,only lower frequency clocks are available in these modes, andperipherals dependent on a clock will thus be limited in response time.For some types of interactions, such as sampling external slow-movingsensors, this is not a problem. However, response time can be veryimportant for responding to application-critical events.

The flexibility and autonomy of peripheral interaction is importantfor both active and sleep modes. The more tasks that can be handledautonomously, the more the MCU core can go to lighter or deeper sleepmodes. Autonomy is also important from a response time and determinismpoint of view. From deep sleep modes, an MCU can wake up inmicroseconds, but while in the active modes, the MCU might be busyhandling high-priority interrupts, delaying response to lower-prioritysystem functions. Building autonomy into MCU peripherals and alsoallowing the peripherals to interact with each other without requiringCPU intervention can be critical to achieving battery-life goals as wellas functional goals such as responsiveness.

Conclusion
In the age of the IoT, the quest for ultra-low power operation is wellestablished and touches every aspect of embedded design. The IoT willsee billions of small battery-powered devices deployed, ranging fromwearable applications such as smart watches to nodes in a smart home orindustrial settings, and extending to smart cities where publicservices, energy distribution networks and traffic management are allautomated and fed with information from intelligent nodes. Even withfuture advances in remote power delivery and battery technologies, thesenodes must be designed with the utmost energy efficiency in mind.

The MCU is the heart of the intelligent node of the future. Theability to minimize energy consumption on the application level requiresultra-low sleep modes and active modes, as well as the ability toactually use these modes effectively along with the functional supportthe application needs all the way down to the deeper sleep modes. For agiven application, there can be multiple orders of magnitude ofdifference in MCU current consumption. However, these enormousdifferences can be difficult to fully understand by simply comparing keyspecifications in MCU datasheets.

Emerging ultra-low-power MCU benchmarks such as EEMBC’s new ULPBenchhelp in the decision process, enabling developers to go beyond trustingpower specs supplied by MCU vendors. Phase one of the benchmark focuseson the key specifications of the device, while the second phase of thebenchmark will focus more on application functionality and how thisfunctionality can be preserved while still consuming as little currentas possible. ULPBench is a great step forward in terms of providingdevelopers with a metric for MCU energy efficiency, which is critical inbuilding the IoT.

2 thoughts on “Assessing real-world MCU energy efficiency

  1. “HeHe, as someone who was working in radiopaging from back in the '70s, I can say with confidence that the quest for ultra-low power consumption and long battery life has been around a long time and will not go away.nMaking sure that Off really is Off. Ti

    Log in to Reply
  2. “Hi Gordon. My view on radio is that is very similar to any type of sensor / interface. There is an on-consumption, hopefully a zero off consumption, and then, depending on protocol and requirements, there is the possibility of duty-cycling. Improving the

    Log in to Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.