Choosing low-power microcontrollers by the numbers -

Choosing low-power microcontrollers by the numbers

Comparing and selecting low-power microcontrollers (MCUs) based on claimed current consumption specifications can be a difficult and confusing task. In most cases, developers selecting an MCU will initially look at the first page of a datasheet to get information about a device, including peripherals, operating speed, package information, number of GPIOs, and power characteristics. This approach works well to determine the overall functionality of a device but is not as useful when trying to gauge low-power characteristics.

To get a full view of low-power operation, developers must take into consideration current consumption, state retention, wake-up time, wake-up sources, and peripherals that are capable of operating while in low-power mode. It is also important to consider any additional functionality or peripherals that can reduce total system power and available evaluation tools that can make an engineer’s job easier.

MCU vendors will usually list the lowest power achievable on the first page of the datasheet. Although the device may be capable of achieving the specification in the datasheet, the actual operating mode may not be practical and useful in a real-world application. Some of the non-advertised features of the lowest power mode may include a very slow wake time, no state or RAM retention, or a reduced operating voltage range. To get around the variety of low-power specifications, developers must identify a common operating mode. This common operating mode must consist of two sections: electrical specifications and low-power functionality.

Comparing electrical specifications
The electrical specifications are available in the datasheet, but determining which specifications are relevant may require some digging. Usually the electrical specifications are organized by vendor-specific power mode. This makes assessment slightly more difficult, as it requires knowledge and familiarity with the functionality of each power mode. In general, it is beneficial to define a set of operating conditions and then map them to a power mode. For example, the developer might define the following set of operating conditions:

  • Sleep mode current consumption with state and RAM retention
  • All other peripherals disabled
  • Sleep mode current consumption with RTC running with state and RAM retention
  • RTC enabled and running all other peripherals disabled.
  • Wake time
  • Supply voltage range

Once the operating conditions are clearly defined, it should be easy to determine the applicable vendor-specific power mode.

Additional low power functionality
The second section, low-power functionality, is not as easy to locate in the vendor’s documentation and may be spread across the datasheet and reference manual. Examples of low-power functionality include:

  • Available wake sources
  • How code resumes execution
  • Peripherals capable of operating in sleep mode.

Once the common operating mode has been clearly defined, developers can begin to examine the documentation in more detail.

While going through this exercise of compiling data, keep in mind thatthere may be some MCU-specific features that can further optimize anapplication for ultra-low power. Optimizations may reduce BOM costs,provide longer product life or provide greater design flexibility. Forexample, an on-chip dc-dc converter can efficiently provide power to thesystem and decrease power consumption. This can enable the use ofsmaller batteries, which will decrease the overall BOM costs, or providepower budget flexibility. A variety of wake sources can provide designflexibility and allow the MCU to stay in the lowest power mode as longas possible, further reducing the average current consumption of theapplication.

Allowing firmware to scale the internal supplyvoltage is another optimization knob available to the developer. If anMCU is operating at a slow frequency, it may be possible to decrease thesupply voltage and save power. Selective clock gating allows hardwareblocks to be disconnected from the active circuits, preventing inactiveperipherals from consuming power. These types of features are notcomprehended by supply current specifications that are commonly used torank low-power MCUs, but are critical to achieving the lowest overallsystem power consumption.

Reducing complexity using tools
AsMCUs become more and more configurable to achieve the lowest powerconsumption, they also can become more complex. To cope with thisincreased complexity, developers should take a close look at theevaluation platforms available for an MCU and the overall ease ofimplementing a solution. For example, the development board and softwaretools used to program the MCU should be intuitive and easy-to-use.Hardware that is difficult to understand or use is not likely to lead toan easy firmware development process.

From a firmwareperspective, MCU vendors should supply firmware examples that canrecreate specifications from the data sheet. If advertised currentconsumption specifications cannot be recreated on an evaluationplatform, it is likely that it will be just as difficult (if notimpossible) to configure the MCU to achieve these numbers on customhardware. Giving customers a variety of code examples that can be usedas a starting point for their code development can reduce time-to-marketand help engineers learn to use a device.

Graphicalconfiguration tools can aid in development and help the developer gain adeeper understanding of an MCU. When developing low-power applications,it is helpful to know where the total consumed power is going. Thisinformation is useful because it highlights what aspect of a designneeds to be further optimized and can also help the developer understandthe overall architecture of the device. Ideally, low-powerconfiguration tools could give tips on further reducing power as well ashighlight any configuration errors that were detected throughout theconfiguration process.

For example, the Power Estimator utilitywithin Silicon Labs’ AppBuilder graphical configuration tool providesPower Tips that give configuration guidance and a power-budget pie chartshowing how much power is consumed and which peripherals are consumingthe power. As configuration changes are made, the pie chartautomatically updates.

Figure 1: A power estimator enables developers to optimize for lowest current consumption

Evaluatingand selecting an MCU for a low-power application requires more than aquick scan of the first page of the datasheet. Determining which MCUprovides the lowest overall system power requires developers to know thedevice’s supply current specifications, as well as any system-leveloptimizations that can reduce the overall supply current.

Unfortunately,each MCU vendor specifies operating conditions differently and in somecases advertises a low-power number that is available in an unusablemode. Using a common operating mode to compare MCUs will preventdevelopers from being misled by vendor claims of ultra-low-poweroperation.

Once the electrical characteristics of a device areunderstood and quantified, developers should take a look at theevaluation platform and software tools available. These considerationsare crucial in getting an engineering team up and running quickly andshould be included in the final MCU selection process.

Evan Schulz is a microcontroller product manager at Silicon Labs, focusing on thecompany’s 32-bit MCU portfolio. Previously serving as an applicationsengineer in the company’s MCU group, Mr. Schulz joined Silicon Labs in2008 as an associate applications engineer. He holds a bachelor’s degreein Electrical Engineering from The University of Texas at Austin.

4 thoughts on “Choosing low-power microcontrollers by the numbers

  1. Evan,
    very nice article! It is great that Silabs provides a tool that outputs that much detailed information. I was wondering how accurate the power estimator might be? A couple years back, when I asked our design team about power estimates, the answer was

    Log in to Reply
  2. Hi, thanks for this good article, however some points are missing. The performance of the full platform for instance and not talking about the core itself. Despite the battle of the numbers that vendros are playing the efficiency of the core will clearly r

    Log in to Reply
  3. … for instance a MSP430 is a 0.6coremark/MHZ performance while a STM32L1 is a 2.95coremark/MHz reducing by 4 the time spent in active mode.
    Also I have seen last week that the STM32L1 of STMicro has now a little brother named STM32L0 based on cortex M0+.

    Log in to Reply

Leave a Reply

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