The recent emergence of wearable and other ultra low power applications such as remote IoT endpoints has often lead the power consumption replacing processing power as the key selection criterion in many embedded applications. Most microcontroller (MCU) manufacturers have at one time or another claimed to be producing the ‘world’s lowest power’ device. But in the real world, with widely varying applications, meaningful direct comparisons between low power microcontrollers are elusive.
One of the reasons that claims to be the world’s lowest power are often overstated is that different devices have different strengths. Some have really low power sleep modes, while some reduce the active power consumption. Some might have multiple sleep modes with different levels of power consumption that use different subsets of the device’s features, switching the rest off to save power. As we will show though, just looking at the datasheet figures can be both confusing and not may not necessarily give an accurate insight into the actual power consumption that will be achieved in practice.
Before we dive into the detail of the MCU world, it would be instructive to look at the generic sources of power consumption in an MCU.
The basics of power consumption in CMOS circuits
Power consumption can be calculated from the equation
Ptotal = Pactive+Pquiescent
The active current being that consumed as a result of the MCU processing information or otherwise executing code and the quiescent current that is present even when the device is not active. The latter is largely a result of the various leakage currents that are inherent in any silicon device using PN junctions to operate. Good process technology will, of course, minimise this, but never completely irradiate it. Let’s now take a look at the contribution from the various sources of current/power drain within a device.
At its most basic level, the vast majority of MCUs use CMOS technology and a CMOS gate consist of two transistors in series between the power supply as shown below.
A logic 1 occurs when the ‘high side’ transistor is ‘on’, and the ‘low side’ transistor is off and a logic 0 occurs when the situation is reversed. Only a small leakage current is consumed when the gate is in either a 1 or a 0 position - assuming the load circuit connected to the gate is not pulling a high current which is generally the case for internal gates, but may not be true for I/O pins of course, but there is a period during the transition between the logic states when both transistors can briefly be on and a switching current spike occurs. Additionally, of course, there is the current required to charge the capacitance of the load that is being driven, but again in an internal system, this should be very low as designers spend a significant amount of time optimising chip layout, and logic cell design. Current consumption in an MCU typically scales linearly with frequency and for this reason, is often quoted as mA/Mhz.
A necessary corollary of the switching speed’s contribution to the power drain of an MCU is its gate count, particularly of the circuitry being used in a particular application. All other things being equal, the more gates that are being switched the more current will be consumed by the device. This partially explains why 32bit MCUs will typically consume more active power than an 8 bit MCU, there’s just more gates that are switching during any given active operation.
Another area that will affect the current consumption of a device is its operating voltage. This will have a consequence on both the quiescent current and the active current of the MCU, for a given application, the lower the supply voltage, the lower the power drain you will achieve. The figure below shows the current drain for an STM8L101 MCU in Active wait mode. It can be clearly seen that the current draw increased with operating voltage. It’s worth remembering that active power Pactive is proportional to the square of the voltage times the frequency.
1. Typical current consumption measured with code executed from Flash
Typical power consumptions in datasheets are normally quoted at room temperature but significant increases in the standby or sleeps currents can be encountered when the MCU is operating at higher temperatures, and this must be factored in when sleep mode power consumption is a key design parameter. Usually, these variations can be obtained from the device manufacturer’s datasheets, or by request. This places a requirement on the engineer to understand the markets in which the end equipment is likely to be used. An IoT sensor used in Jeddah is likely to see a different battery life compared to a unit installed in the more benign environment encountered in say London.
To illustrate this effect, below is a characterisation from the NXP MKL02Z32VFM4, MCU, a very low power 32bit MCU in stop (in active mode).
As we can see from the above, the stop current can vary by an order of magnitude over the extremes of the devices operating temperature although it is always a very creditable figure for a powerful processor.
A similar effect can be seen in the active current of an STM8 L101. It’s worth remembering that current scales linearly with temperature in general.
In conclusion, we can see that all other things being equal the current consumption of a circuit will be largely proportional to the frequency of switching and the number of gates that are switching, but that operating temperature and voltage also have the potential to play a significant part in the engineer’s design calculations.
Now that we have looked at the basic elements of the power consumption of a device, we can turn our attention to the application-specific mechanisms that can drive current consumption. This divides into two discrete areas.
- The operating regime under which the MCU is working
- The internal functionality of the MCU
How an MCU is being used will largely dominate the power it draws from the power source. Any comparison of MCUs in a low power design will need to consider how long the microcontroller will be in any of the many operating states available to the device. So, for example, something like a PIR sensor application the MCU might spend the vast majority of its time in the standby mode, only waking up when a trigger is activated or to send an infrequent ‘I’m alive signal’. In this case, the sleep mode current drain will be the primary determinant of current consumption. This will be a complete contrast to say an industrial process sensor system which spends most of its time awake, and where active current will set the benchmark. Later in this article, we’ll look at a semi real-world system to reinforce this.
Internal functionality of the MCU
Let’s now turn our attention to the internal functionality of the MCU and how its design can affect the power consumption of the device. Most modern MCUs have multiple low power modes and they are called by a bewildering variety of different names. Similarly, there will often be multiple options for the active modes as well. We’ll now look at them in turn.
In active mode, the power consumed by the device is the product of the supply voltage and the current consumed. The current consumed depends on switching frequency of the CMOS gates, the operating temperature and the supply voltage, so it’s usually quoted as a per-MHz value, at a certain supply voltage and operating temperature range. Like most things in the MCU world though, there will be complications. Many MCUs will have variable clocking modes allowing the user to chose what frequency is being used, what clock source is used (eg internal RC oscillator, off-chip crystal etc), and what peripherals are powered up or not. It takes some care when designing a system to ensure you are selecting the appropriate mode. Luckily some MCU manufacturers do offer power supply calculators for simplifying the process.
As an example of the flexibility offered by chip designers, TI’s popular MSP430 series of low power MCUs offers several active modes. For the MSP430FR6879/68791/6877, these modes consume between 375 and 100µA/MHz at 3.0Vcc, depending on whether FRAM or SRAM needs to be used.
As we have already noted, the power consumed is proportional to the square of the supply voltage, so we need to pay particular attention to the supply voltage conditions quoted on the datasheet. Devices will appear to consume less power at the lower end of their range – for battery-powered portable devices this may be 1.8V, but when the batteries are fully charged, they supply the full 3V and the current consumption may not be as attractive. Some devices, such as Silicon Labs', EFM8 Busy Bee series have a built-in LDO (low drop-out) voltage regulator which maintains the voltage supplied to the rest of the device at a lower level, even when the batteries are fully charged. However, life is never that easy, and the designer needs to remember that an LDO will have a quiescent and operating current associated with its operation and hence the engineer will need to ensure that what they gain from having the LDO at high battery voltage, isn’t lost at lower voltages due to LDO operation.
Manufacturers will typically quote the current consumption of their lowest power mode as ‘sleep mode’, but for different devices that can mean many different things. Many have several different modes (perhaps ‘sleep’, ‘deep sleep’, ‘standby’, etc.), which switch off more and more parts of the device. So, what needs to be checked is that the sleep modes of different devices being compared all offer enough functionality for your application while in that mode (for example, is memory retention required? What about the real time clock?).
For example, Microchip’s nanoWatt XLP (eXtreme Low Power) series boasts very low 9nA power consumption in its deepest sleep mode, but if brown-out reset is required, it consumes 45nA. If a watchdog timer is needed, that increases to 200nA, while a mode that runs a real time clock/calendar consumes 400nA.
The STM8L 101 series of 8-bit low power MCUs from STMicroelectronics is another low power MCU. It consumes 350nA in its lowest power mode but this includes the on-chip regulator that is standard on the family. As usual, there are several modes to choose from: wait, active-halt and halt. In wait mode, the CPU is stopped but the peripherals are kept running while the device is waiting for an external event. In active-halt mode, the CPU is stopped, but auto-wakeup and the independent watchdog are kept running (if they are enabled). In halt mode, the CPU and peripheral clocks are completely stopped.
It might seem obvious that to get the lowest power consumption, the engineer would arrange to switch off all active peripherals, but is this always the case? Again, the answer to this depends on the application that is being designed. When making this decision, it should be remembered that waking an MCU from deep sleep often involves starting up the main oscillator and waiting for the crystal oscillator to stabilise, which can take some time. This is ‘wasted power’ and means that if the algorithm required frequent wakeup sessions to scan peripherals, it is better to use another mode and avoid the wake mode.
Although not strictly direct MCU current consumption the designer should ensure that they follow the manufacturers’ instructions for minimising power by ensuring I/O ports are set appropriately, peripherals are de-powered, clocking to unused areas or the device are stopped and so on. Failure to do this could give very unexpectedly high figures. A final point to consider is the new generation of MCUs that offer autonomous peripherals that operate in sleep modes. If these fit the design requirements, significant savings in active CPU power consumption can be made.
Aside from the power consumed in the different modes, the power consumed when the device is in neither state, that is, during transition from one to another, may also be significant. Energy expended while the device is waking up is wasted. The time it takes to transition between the modes should, therefore, be noted; devices with a fast wake-up time, which spend minimal time in transition, are desirable. For example, for the ST8L101 series mentioned above, the supply current during wake-up time from active-halt mode is 2µA, and the wake-up time from active-halt mode to run mode is 4µs. However, this time does not factor in the start-up time for the crystal, and this can be significantly larger than the time for the CPU to begin program execution.
In summary, the power consumption of the device must be examined for all the operating modes you will be using, as well as how much power is used when transitioning between these modes. To compare devices for a real-world application, consider which of the device’s low power modes meets the required functionality and how long the device will spend in each mode.
An example application
To try and illustrate all of this, let’s set up a hypothetical (and quite extreme) system that is designed to measure water pressure in a mains distribution system. The unit is battery-powered and sealed and is expected to last for years from a single primary battery. To save power the unit is set to wake every few minutes to take a pressure reading and store it in memory, it will transfer its data to a central receiving station every 24 hours. To simplify the analysis, we will just look at the MCUs contribution to the power budget, and we will develop a spreadsheet that allows us to vary the parameters to show their effect on power consumption. The sketch below (figures 1 and 2) shows a simplified representation of the operation.
For this analysis, we are going to base the operation on the Arizona Microchip PIC16LF183xx family of devices, which have their XLP technology and hence are a very suitable device for this kind of ultra-low-power application. The device has multiple low power and oscillator modes to minimise current drain and wakeup times,
Figure 1, system operating regime
Figure 2, system power consumption
The first activity is a low power mode, the MCU is largely asleep, all peripherals are inactive with the exception of a timer that is running from a crystal oscillator, and the interrupt management circuitry. From the datasheet, we can see the power consumption in sleep mode is as follows.
Sleep mode current + Timer 1 current = 30nA + 400nA = 430nA
For ease of calculation, we have assumed that the temperature is kept relatively constant due to its contact with water. Hence, we are using typical values and some reasonable assumptions for peripheral usage and wake up times for crystals etc, to make the number manageable, although for a real application the analysis would, of course, be much more detailed.
This is in effect the wake-up state when the MCU transitions from sleep mode to active mode. It is not quoted in the datasheet, but a good assumption is that it is equivalent in power consumption to active mode (in the worst case). From the datasheet, we expect a current drain of ~1.2mA lasting for roughly 20 milliseconds.
This is the active mode, when the processor is running at its chosen operating speed, taking pressure readings, storing data etc, and then returns to sleep mode. During this state, the MCU will decide whether it is time to communicate with the home base. During this state, the expected current drain is again 1.2mA and will last roughly 40mS.
State 4 communications state
Here the processor sends its data via a nominated communications channel and so will need to be in active mode, with multiple peripherals powered up. The assumed current drain is 3mA and activity lasts 2 seconds.
Having calculated the individual power consumptions, we can now show the contributions of each state to the overall power consumption of the system and by varying the operating regime we can show the effect of the design parameters on power consumption. This can be easily demonstrated by setting up a spreadsheet to cover the various modes. For clarity, the power consumption is normalised to milliamp - hours of battery capacity needed per year of operation. Remember though that this includes only the MCU portion of the power, other components will, of course, have their own contribution.
The power consumption comes out as follows for a 5-minute sample period.
Fig 3. Estimated power drain 1 sample every 5 minutes
If we move to a sample rate of one every 30 minutes this changes as follows
Fig 4, Estimated power drain 1 sample every 30 minutes
What we can see from this is that for an MCU with very low sleep consumption, the contribution to the power budget is negligible. However, the time awake and the wake up period are the major contributors and the frequency of activation can be crucial. Although this is quite an artificial example, as it does not include the power consumed by the rest of the circuitry in the system, it does illustrate nicely that the operating regime can be as important as the MCUs performance in defining the power consumption of a system. If the quiescent current rose to 10uA then for the slower sample rate its contribution would be on a par with the sampling activity.
This result throws up a further interesting topic of the number-crunching ability of the MCU. The results for this particular application would indicate that having a fast MCU that can execute the regular sampling code quickly, and get back to sleep as fast as possible would be advantageous in terms of battery life, and possibly allow the use of a smaller capacity and hence cheaper primary cell. The days when the automatic choice for a low power application was always an 8bit MCU may be over as new very low power 32bit MCUs enter the market. Again, this statement needs to be qualified by the prism of the application requirement, there are definitely applications where the low gate count of 8 bit MCUs and their consequent low sleep and active currents will be the defining requirement for the design.
The above result also points to the need for careful coding of the software that is running the sample taking and storage routines. This is particularly true if the code is written in a high-level language, and calls for close benchmarking and optimisation of the code plus knowledge of the runtime aspects of the compiler. For instance, declaring key variables as static will ensure that time (and hence power) is not wasted in making working copies being made at power up and down. Arising from this it’s also worth mentioning the performance of third party software; the modern trend is for products such as communications stacks to be bought in, rather than coded in-house, this obviously saves time, cost and potential IP violations, but does come at the cost that code is potentially opaque to the users and hence it is often difficult to easily evaluate its power consumption effects.
So, which is the lowest power MCU?
The aim of this article is to demonstrate that the answer to this question is ‘it depends on what you are designing, simply inspecting the headline sleeps modes current consumptions and comparing these is not likely to give you the lowest power design. MCU X, for instance, might have the lowest power sleep mode, but does not have the ability to run its timers in this mode, which is crucial to the design requirements, or the active current of MCU Y is lowest, but its wakeup time is slow, so its overall current consumption is higher in the regime it's being used in.
The simple fact is that the lowest power MCU is the one that is most optimal in the application that it's being used and this can only be evaluated by a detailed inspection of the datasheets and preferably modelling the application with the quoted power drains for a variety of devices. Add to this the fact that the design compromises and decisions of the engineer will have a significant effect on the power consumption achieved in reality. All designs, of course, being a compromise between technical optimisation and cost in the final analysis.
There are however some useful guidelines that can be followed.
- Evaluate the trade-offs between active and sleep modes. Where possible, model the effect of a faster processor against a slower one that has a lower sleep current to ensure that the right decision path is being followed.
- Use an evaluation board to check out real measurements versus the datasheet values. It is worth remembering that worst-case figures are often quoted such that only a small proportion of devices will fail a test, whereas typical values are batch measured results. The engineer needs to make a reasoned estimate to ensure that they are neither over specifying their power consumption or underestimating it.
- Use a spreadsheet or power consumption calculator from the MCU manufacturer to model your system, and use the EEMBC website to gain valuable insights into real-life power drains.
- Do make sure you understand your operating temperature variations and model the effect of these on your power consumption estimates.
- Evaluate the coding tools you are using; is the chosen C compiler costing you dear in power-hungry time spent in the active mode? Is the ‘comms stack that you are using going to rob you of crucial mAhrs of battery life?
- Make sure that your external circuitry is in an appropriate state so that your leakage currents are minimised, and chose the external components wisely.
- MCUs with autonomous peripherals can reduce power consumption by offloading activity that would normally need CPU intervention, allowing the device to remain in sleep mode for as long as possible.
- When comparing MCUs, ensure that you are comparing apples with apples, for instance, does the sleep current of one device include an on-chip LDO, while another will need an external part.