Optimizing software and peripheral usage are crucial for energy saving
There is an ever-growing number of embedded systems applications where energy saving and efficiency are at the top of developers’ priorities. These priorities can be due to government regulations, a requirement to increase battery life, or simply a need to lower electricity usage.
To accommodate this trend, a growing number of “ultra-low-power” microcontrollers have become available. However, tools that provide developers with detailed monitoring of their systems’ energy consumption have not accompanied them, at least until very recently.
Having a low-power MCU by itself does not mean you will have lower energy consumption: the trick is to optimize your software, not just in terms of functionality but also with respect to energy efficiency. Having full control of the hardware surrounding the MCU and optimizing the overall software and peripheral usage are crucial factors for reducing system energy consumption. Software is not often seen as an energy drain, but every clock cycle consumes energy and minimizing these reduces consumption.
Energy-friendly embedded systems development can be seen as a three-stage cycle: hardware debugging, software functional debugging, and software energy debugging.
Energy-friendly software development
The major concerns when developing MCU software are typically related to reducing memory usage and having the smallest possible code size. To achieve energy friendliness, aiming to spend the longest time in sleep mode is a very typical scenario, but it is not the only way to save energy. Energy-efficient MCUs often have other functions that enable even lower energy consumption. In addition to using the sleep modes available on these MCUs, efficient use of the other functions is the real secret to saving energy.
As the development process moves forward, the code gets larger and optimizing for energy efficiency becomes a more complex task. Identifying errors, such as avoidable wait cycles that could be replaced by interrupt service routines, or peripheral misusage, becomes increasingly difficult. If these “energy bugs” are not spotted and solved during the development stage, it is virtually impossible to detect them in field or lab tests.
The most common way to track how much energy a system draws is by sampling the current over a certain period, followed by averaging and extrapolating to longer time periods. This kind of measurement can be done using a multimeter or oscilloscope but it is usually not possible to relate the results to code routines.
On the other hand, a logic analyzer can be used to keep track of the routines but usually cannot relate that to the energy consumption. To estimate battery life, the results obtained with extrapolation should not be too far away from a real-case usage scenario, but when the goal is optimizing the code for energy efficiency this approach is of limited use.
A more productive approach
It’s now possible to make significant saving in development time and effort by addressing the energy-debugging problem with software and hardware tools that display graphical, real-time energy consumption information and allow correlation between current and the actual code running at any given moment. You can monitor energy using a current sensor on the power rail.
On a timer tick, you sample the current, do an A/D conversion, and then communicate the information via a USB port – together with voltage and timing. In addition, the MCU sends program counter (PC) samples so that the code can be corelated with the current on a host computer.
A 1,000-fold reduction
One example of available tools is the Advanced Energy Monitoring (AEM) system that is part of Energy Micro’s EFM32 Gecko MCU starter kits and development kits. Real-time information about current consumption is shown on an LCD display (if using the DVK) or can be displayed using the company’s energyAware Profiler by connecting any of the kits to a PC via USB. A typical energyAware Profiler display is shown in Fig. 1 . The tool displays a current vs. time graphical representation.
The example demonstrates how to use the energy profiling, together with features from the EFM32 MCU, to cut energy use. In Fig. 2 the LEUART module is used. It enables UART communication to a baud rate of up to 9,600 while keeping energy consumption to a minimum.
A common way of getting data from the reception buffer is to poll it until you get valid data and then read the buffer. By doing this, the MCU must be in a run mode, which results in relatively high-current use.
The profile for such a loop, shown in Fig. 2a, is a constant current consumption of 3.33 mA. By clicking on the graph, the function causing the drain is highlighted.
void pollLEUARTRx(void)
{while ( !( LEUART0 -> STATUS & LEUART_STATUS_RXDATAV ) );}
The highlighted code line is the polling loop, which checks if the buffer has received any data. The profiler shows each function and how much each contributes to total energy consumption. In this case, the only function in the code is pollLEUARTRx(), which accounts for all the energy consumption (see Fig. 3 ).
A common workaround to avoid polling the RX buffer is to enable RX interrupts and set the MCU in sleep mode. If that is done, it is easy to see that the energy savings are significant. As we shut off the processor, the current drops to 1.40 mA (see Fig. 2b). Now, when the LEUART receives data, it wakes up and transmits it back through the TX buffer.
When the interrupt is triggered, the current spikes to around 2.5 mA and the profiler pinpoints the interrupt routines (see Fig. 4a ). However, the current stays on this peak for a long time and by clicking on the graph it is possible to detect another common mistake when using UART communication.
void pollLEUARTTX(void)
{while ( !( LEUART0 -> STATUS & LEUART_STATUS_TXC) );}
After sending the data, the user sets a while loop waiting for the transmission to finish. This will of course keep the processor in running mode longer than necessary. The loop can be replaced by an interrupt that wakes up the processor once the transmission is finished. By doing this, the current consumption will again be reduced (see Fig. 4b ).
Now the processor goes into sleep mode between each received byte, lowering the current. The byte transmission is done without processor intervention so it is not necessary to poll the buffer to know when the transmission is finished. Replacing the loop with an interrupt routine is a much more elegant and energy-friendly solution, as shown with the different profiles of the two approaches.
Deep sleep
The LEUART module on the EFM32 MCUs can be functional in a deep-sleep mode. In this mode, the high-frequency oscillators are shut down, but low frequency oscillators (RC or crystal) are still running and clocking the LEUART. If we repeat the above example putting the EFM32 in deep-sleep mode, the energy consumption drops to microampere levels.
To be able to visualize these current numbers, the profiler scale is switched from linear to logarithmic. The current is now 1 µA in deep-sleep mode and spikes to 80 µA when receiving the frame (see Fig. 4c ). The enhancement in energy saving from the first approach to this final configuration is a factor of over 1,000. ■
BY TIAGO MONTE
Energy Micro, Oslo, Norway
www.energymicro.com
Fig. 1. Energy debugging is simplified because the effect of code changes can be monitored in real time. Energy debuggingFig. 2. LEUART RX polling in run mode (a). LEUART RX interrupt triggered in sleep mode (b). Fig. 4. LEUART RX Interrupt with LEUART TX polling (a), EFM32 in sleep mode between received bytes (b), and EFM32 in deep-sleep mode (c). Fig. 3. Function energy consumption. Energy debugging
Advertisement
Learn more about Energy Micro
