Understanding the Real Energy Consumption of Embedded Microcontrollers

Microcontrollers are used in numerous low-power and/or battery-powered applications, ranging from smart meters to consumer medical devices to industrial devices that remotely transmit temperature, vibration, humidity and other parametric data. Battery lifetime in these applications is a critical parameter – the microcontroller plays a pivotal role in determining this length of time.

Many factors come into play for microcontroller selection. Dominating factors, such as the right peripheral mix and memory profile, are very quantitative details in the data sheet. However, it is ambiguous how the data sheet numbers translate to battery life and microcontroller performance. For an accurate comparison, an engineer builds prototypes using multiple vendors’ devices, but this method is very time consuming, so the only practical choice is to rely on the data sheet numbers and hope that it somehow correlates to the application. Often this approach means that, late in the design process, a change must be made to add a larger or more sophisticated battery.

Most battery applications spend much of their time asleep, waking up to perform their functions and then going back to sleep. For these applications, battery life depends on three major aspects of the microcontroller:

• The “do-nothing” state of the microcontroller, often with many different forms.
• Start-up time, that being how long it takes the microcontroller to go from the do-nothing state to running the application state.
• The application runtime.

The power consumption of the do-nothing state and start-up state is more or less a given for a particular microcontroller regardless of the application, but the power consumption of the application is unique. To reasonably compare different devices, we need a benchmark algorithm that represents a “typical” microcontroller application and exercises most of the architectural features and memory options.

In the following study, we used the EEMBC® CoreMark™ benchmark to create a reasonable methodology for comparing the power consumption of different microcontrollers. As you will see, the “intuitive” choice for low power did not necessarily yield the longest battery life.

CoreMark refresher

In the July 8, 2011 edition of TechZone’s Microcontroller Solutions Magazine, we spoke about CoreMark, but here is a quick refresher. Since 2009, the CoreMark benchmark has been downloaded almost 7,000 times (as of this writing). The developers took specific care to address the pitfalls that beset older benchmarks: workloads that scarcely resembled real code; compilers that might optimize out parts of the code; and the possibility of other manipulations that might distort any meaningful results. CoreMark has proven itself to be a reliable indicator of performance. The CoreMark benchmark mirrors real-world computing by careful use of three basic data structures. A linked list exercises pointer operations; matrix operations demonstrate tight optimized loops; and state machines test less-structured, hard-to-predict branching.

The program consists primarily of a main loop where the bulk of the work is done. We will refer to each excursion of the loop as a single iteration. After the loop has finished iterating, a cyclical redundancy check (CRC), also part of the timed portion of the benchmark, is run to confirm that nothing went awry during execution. This benchmark has characteristics that make it very attractive for comparing the performance – or, in this case, energy consumption – across a range of widely differing microcontrollers.

Using CoreMark to compare current

Again, our mission here is to present a methodology and not to compare devices, so therefore the actual data is irrelevant and the exact names of the devices remain anonymous (contact the author if you are interested in specific details).

• 8-bit microcontroller
• 16-bit microcontroller
• 32-bit microcontroller

The data sheet value for “typical” power consumption is usually accompanied by footnotes indicating a test setup that deviates from what will be seen in-situ in a real user application. These notes include turning off all internal oscillators and driving the device from an external oscillator. In addition, all peripherals are off; the core and the memories are the only active components. Part of the reason for this is because it is virtually impossible to devise a standard usage profile, especially related to memory and peripheral usage. However, the data sheets do not specify the code running on the core while power measurements are made. Some indicate a CRC algorithm or briefly describe the code; others specify a “while (1)” loop.

Initially when we compared the microcontrollers’ power consumption, we looked at the current drawn while running EEMBC’s CoreMark benchmark and then compared that value with the data sheet numbers. We collected our test data at room temperature and aligned with data sheet notes. In all cases, the devices were executing from FLASH. Because we matched all of the known testing conditions (except the code), we could isolate the code’s impact in determining the reliability of the measured numbers.

CoreMark and data sheet comparisons

The following graphs show the devices’ behavior across frequency as reported in the data sheet and as measured while running the CoreMark benchmark. In all cases, the CoreMark current is higher than the reported data sheet numbers, sometimes by a wide margin. Table 1 shows the ratio of CoreMark-measured current to data sheet current.

Figure 1: Comparing datasheet and CoreMark generated values of current versus frequency for a common 8-bit microcontroller.

 

Figure 2: Comparing datasheet and CoreMark generated values of current versus frequency for a common 32-bit microcontroller.

Table 1: CoreMark to data sheet ratio demonstrates that the difference can sometimes be almost 2.5 times larger for real-world code execution.

Energy: Calculating the area under the curve

Using CoreMark provides a good workload to demonstrate performance differences between microcontrollers, but extra steps are required to determine the amount of energy the core requires to perform the algorithm. If two microcontrollers draw the same current at a given frequency, but one completes its work faster than the other, then the faster microcontroller uses less energy to do its work. Note that the data sheet values only show current drawn and do not reflect microcontroller efficiency and energy consumption.

A 32-bit microcontroller may be able to run an application two to three times faster than an 8- or 16-bit microcontroller, but how does that correlate to battery life? Battery life is determined by the rate at which energy is removed (i.e. the power), and is reflected by the area under the curve of power versus time, as shown in Figure 3. The assumption is that the microcontroller can enter sleep mode when not executing.

Figure 3: Area under the power curve determines energy.

A more efficient microcontroller will potentially yield a smaller area under the curve for a fixed period because more time can be spent in sleep mode. Marketing slides typically show a generic graph with equal peak currents for all bit widths (8, 16, or 32) and faster execution for wider bit widths (see Figure 4). In other words, they show the advantage of speed, but may disregard the disadvantage of higher current. This would overstate the energy efficiency of larger microcontrollers. Actual measurements standardized around the CoreMark benchmark can provide a more realistic picture of how microcontrollers perform.

Figure 4: Performance effects on average current.

Energy measurements

During the evaluation we performed, each device woke up from the sleeping state, performed the CoreMark benchmark, and then reentered the quiescent low-power mode. Most microcontrollers have many different power-down modes. In one example, it may be possible for the microcontroller to drop into a lower-power, state-retained condition where a low-power oscillator is left on. In this case, the microcontroller wakes itself up based on some interrupt and resumes executing the application from where it left off when it went to sleep. Other low-power modes have options that leave various portions of the microcontroller powered up.

The various modes trade off wake-up time for power consumption. In the lowest-power modes, an external source must wake-up the microcontroller. To perform an equitable evaluation, we chose the lowest-powered sleep state from which the microcontroller could wake. We included the wake-up time in the overall energy measurements.

Measuring the microcontroller’s current over time is a challenge – the dynamic range is large, going from microamperes to milliamperes in a short time period. A conventional current meter is too slow when auto-switching across this large a range. In addition, the current sampling time is too long to capture quick changes. Several companies have built suitable measurement devices; we used the Hitex’s PowerScale, which is fast responding and has a large dynamic range. We connected the PowerScale probe in series with the microcontroller’s power rails. In all cases, the microcontroller I/Os were inactive and we only measured the core and memories.

Modifying the duty cycle

In our measurements we wanted to modify the ratio of execution time to sleep time. Hence, we modified the CoreMark benchmark to allow measurement of a single iteration of the work loop. During a ten second period, we ran one iteration of the CoreMark work loop and then let the microcontroller sleep; we obtained from this a duty cycle of working time versus sleep time.

Each microcontroller was programmed to wake up to a given frequency, perform one iteration of the CoreMark benchmark, and then go back to sleep. The time awake was measured when the current began rising, and the sleep time started when the current reached its quiescent state. This made the duty cycle measurements directly proportional to the time it takes to complete the benchmark (including start-up and shut-down time).

We modified the duty cycle by adjusting the clock frequency. For instance, at 6 MHz, the benchmark loop would complete twice as quickly as it would at 3 MHz, leaving more sleep time and therefore reducing the duty cycle (see Table 2).

Table 2: Duty cycle comparison as a function of operating frequency (as percent).

Measurement results

Integrating the current over a ten second period gives the amount of charge consumed. Since the voltage is fixed, the per-iteration charge measurement is directly proportional to the per-iteration energy (see Figure 5). As an example, at 4 MHz, the 32-bit microcontroller is 3.5 times and 8.6 times as efficient as the 16- and 8-bit microcontrollers, respectively.

Figure 5: Per-iteration energy.

The effect of input voltage on energy

The input voltage affects the per-iteration energy based on the microcontroller’s semiconductor process, as well as whether or not it has a voltage regulator and, if so, the kind of regulator. For example, our testing demonstrated that a change in voltage resulted in much more dramatic power consumption change for the 16-bit microcontroller compared to the 32-bit microcontroller; however, the manufacturing process of the 16-bit microcontroller allows the device to operate over its full voltage range without a regulator; the 32-bit microcontroller requires an onboard regulator. The current consumption for a device without a voltage regulator will change much more than a device with a regulator. In our specific testing, the 32-bit microcontroller used a linear regulator at the front end of the digital logic; this provides a constant current as input voltage changes. If the device used a switching regulator instead, the device would draw constant power instead of constant current.

Single-Iteration versus repetitive energy

A single-iteration test focuses more on the sleep time rather than the awake time. We did this by running one benchmark iteration and letting the microcontroller go to sleep. This would be an accurate representation of an application that runs once and then waits a very long time before it runs again. We determined that if the sleep time is less than 75 seconds, the 32-bit microcontroller would use the least energy because it spends a big percentage of the period running code, and the 32-bit microcontroller was more efficient while running code. For sleep times longer than 75 seconds, the 16-bit microcontroller uses the least energy because it is more efficient while sleeping. The 8-bit consumed the least current when the sleep time exceeded 300 seconds.

If the application code iterates constantly instead of running just once, the energy profile looks much different. Figure 6 shows the energy profile for the three devices tested at selected frequencies. Over time, the energy accumulates linearly. In this type of application, 32-bit microcontrollers can complete the task much faster with lower currents.

Figure 6: Test results for repetitive execution of CoreMark.

But how long will my battery last?

The absolute battery life depends on the application, but we compared the three microcontrollers above when running a repetitive CoreMark workload. With all microcontrollers running at 6 MHz powered by a 240 mAhr CR2032 coin cell battery, the results are as follows:

• 32-bit microcontroller: 3.6 million iterations or 100 hours of life
• 16-bit microcontroller: 1.2 million iterations or 33 hours of life
• 8-bit microcontroller: 0.432 million iterations or 12 hours of life

Conclusion

With the increased ubiquity of battery-powered embedded devices, energy consumption has become a particularly critical device parameter. Getting this specification incorrect can result in the outright failure of a product in the market. Unfortunately, microcontroller data sheets provide little in the way of realistic power information. The characteristics that make the CoreMark benchmark attractive for performance measurements also make it a useful application for comparing the real-world power consumption of different microcontrollers. While an absolute battery life estimate requires testing with the actual target applications, the CoreMark benchmark can help make critical microcontroller decisions early in the design cycle, long before the target applications are ready.