What is Ultra-Low Power (ULP)?
Ultra Low Power (ULP) is an umbrella term encompassing energy saving hardware and software techniques. The primary objective is to reduce a microcontroller’s energy consumption as much as possible while still meeting the real-time system constraints.
On the extreme end of the spectrum, we find battery-powered devices such as a blood glucose monitor. These wonders of technology are powered off a coin cell. They sleep with a minuscule amount of energy dedicated to maintaining a Real-Time Clock (RTC). The primary microcontroller wakes up in response to a user’s input to perform the measurement, update the display, or interface with a PC to download the data.
ULP is increasingly important as powerful and highly configurable processors such as the STM32L562CEU6 featured in Figure 1 are available.
By definition, ULP is a recognition that energy consumption and battery life are just as important as the microcontroller’s performance.
Figure 1: Image of the STM32F767 Nucleo-144 board featuring the STM32F767ZIT6 Cortex-M7.
Tech Tip: There appears to be an inverse relationship between sleep current and processor complexity. The featured Cortex M7 is a highly complex device. As a rule of thumb, smaller 8-bit with 1/100 the performance has 1/10 the sleep current. However, there are exceptions, clever engineers are always improving the technology. Today, some of the mid-range 32-bit microcontrollers are on par with the 8-bit microcontrollers. An example is the featured STM32L562CEU6 series with an all-off 17 nA consumption.
What hardware is used for ULP?
Recall that the energy consumption of a logic gate is often dominated by the speed at which that gate operates. Since a microcontroller is a collection of logic gates, it follows that energy consumption is directly related to clock speed. As an example, a modern 32-bit ARM processor will consume considerable power when the core is running all-out at 216 MHz. That same core will run cool if shifted to a 32.768 RTC frequency. For even lower power consumption, we can turn off the main CPU and shift functionality into a peripheral. The dedicated 32.768 kHz RTC peripheral is a good example. Other examples include the watchdog timer, wake up on change interrupts, and Direct Memory Access (DMA).
Tech Tip: Current consumption is often described using a uA/MHz metric. This reinforces the idea that current consumption and clock speed are related. You may know if you have overclocked a processor. The higher clock speed, the greater the heat, with the potential to damage the processor.
A real-world example is the STMicroelectronics STM32F767ZIT6 as shown in Figure 1. When operating at 216 MHz at an elevated temperature with all peripherals enabled, the current can be as high as 258 mA. However, when in deep sleep, with everything except the RTC turned off, the current could be as low as 770 nA (ambient temperature 25 °C with a 1.7 VDC source).
Tech Tip: Sleep mode is not a simple on-off switch. Actual conditions are as varied as the number of peripherals on the chip. For example, the datasheet for the featured STM32F767ZIT6 requires over 12 pages to describe the different modes.
What software is used for ULP?
Changing clock speed and securing unused peripherals are an important part of ULP. However, these operations are not automatic. For true ULP, the hardware must be managed by the programmer. This requires considerable attention to the application to find the correct balance between performance and energy consumption.
Interrupt Service Routines can save energy
We can minimize energy consumption using Interrupt Service Routines (ISRs) to respond to the real events such a button press or a hardware timer overflow. Each ISR is triggered by an event, a small section of code is executed, the microcontroller then goes back to sleep. Taken to an extreme example, the code could look something like this:
// My ISRs
main(){
// Setup
while(1){
goToSleep();
}
}
In practice, the program will be more complex than suggested by the code snippet. However, our objective is still to maximize the sleep time.
Reduce clock speed to save energy
Most microcontrollers have robust clock selection logic that may be changed on the fly. We can save energy by throttling the clock speed to match the workload. In some cases, we need the high-speed clock, in others the watchdog or RTC may be sufficient.
Code simplification can save energy
Personally, I’m tempted to make everything a type double for code simplicity. We know this is wrong as the floating-point computational overhead is not warranted. Neither is the overhead required to shuffle the unnecessary bits to and from memory.
Instead, we should use the atomic width of the microcontroller whenever possible with uint32_t for the 32-bit machines and uint8_t for the 8-bit machine.
We should also consider the balance between nice-to-have and need-to-have calculations. This is often an artifact of debugging, where all the intermediate and final calculations are neatly stored just in case we need them in the future. Eliminating the nice-to-have calculations or the use of post processing could save energy.
I say this with the caution, “don’t be clever.” Code simplification can be taken too far, making the program difficult to understand and troubleshoot. An extreme example is the use of assembler.
Turn off unnecessary peripherals to save energy
This is a simple idea. Just like turning off the lights when you leave the room, turn off peripherals if you are not using them. It takes more programming finesse, but little things like placing a receiver into a low-power mode with an ISR wakeup are preferable to simply turning on the RX and TX sections.
Parting thoughts
This article is but a drop in the ocean when it comes to reduced energy consumption in microcontrollers. Books have been written on this topic.
Let’s continue the conversation. Please leave your suggestions and comments in the space below.
Best Wishes,
APDahlen
Related Information
Please follow these links to related and useful information:
About this author
Aaron Dahlen, LCDR USCG (Ret.), serves as an application engineer at DigiKey. He has a unique electronics and automation foundation built over a 27-year military career as a technician and engineer which was further enhanced by 12 years of teaching (interwoven). With an MSEE degree from Minnesota State University, Mankato, Dahlen has taught in an ABET-accredited EE program, served as the program coordinator for an EET program, and taught component-level repair to military electronics technicians. Dahlen has returned to his Northern Minnesota home and thoroughly enjoys researching and writing articles such as this.