Rasmus Christian Larsen, Support & Training Manager at Energy Micro explores how to optimise MCU code for low energy operation – Once you’ve selected the right low power microcontroller, how important is your application code in achieving energy saving and efficiency goals? And how do you go about optimising it for ultra low power operation?
Answering such questions has always been difficult, since correlating current consumption with software code has traditionally been a somewhat inexact and cumbersome task.
Software has never really been identified as an ‘energy drain’, but energy is being consumed on every clock cycle, so it really deserves closer attention, particularly in today’s battery-driven, energy sensitive applications. We need to go much further than just maximising the amount of time a microcontroller spends in a sleep mode and limiting code size to reduce memory usage.
Working progress in embedded development
Consider a simple while loop which would have been better replaced with an interrupt service routine, it’s the kind of basic oversight that causes a processor to stay active instead of entering a sleep mode. Identifying such energy bugs in field or burn-in tests is just too late and costly. We need for embedded system development to become a three phase cycle; of hardware debugging, software functionality debugging and software energy debugging. Having full control of the hardware surrounding the microcontroller and the overall software and peripheral usage inside are crucial factors in reducing a system’s total energy consumption and maximising battery lifetime.
Traditionally, measurements of a hardware setup made by an oscilloscope or multimeter and entered into spreadsheets can be extrapolated to provide a reasonable estimation of an application’s battery life expectancy. The approach though presents no real correlation between current consumption and code. Equally, while a logic analyser can be employed as more of a code view tool, it again lacks the correlation. Use all the equipment together of course and the picture becomes a little clearer but setup time, accuracy and its repeatability are not insignificant issues.
There is potentially three things that are actually needed to produce energy optimised MCU designs quickly and economically: the right microcontroller, development kits that can reliably measure a prototype’s current consumption and supporting software tools that can clearly show the correlation between the current being consumed and the code that’s running. With all these elements in place, no special equipment setup is required and accurate measurements can be obtained in a way that significantly reduces design cycle time.
Dressing the challenges of ultra low power embedded systems
To addresses the challenge of ultra low power embedded system design Energy Micro has developed a microcontroller solution: The ARM Cortex-M3 based EFM32 Gecko microcontroller. This device is a purpose designed solution for energy sensitive applications. It is characterised by low active power consumption, ultra low standby current and fast wake-up and task execution times. It provides a selection of low energy peripherals functions that can operate autonomously of the processor core enabling it to stay asleep for longer. A range of low energy operating modes are available, from a 20nA EM4 ‘shut off’ mode through to a 160µA/MHz ‘run mode’.
An advanced energy monitoring (AEM) system on the development kit enables developers to keep track of their application’s current consumption in real time using an on-board LCD. The AEM system samples current flowing through the MCU power rail and immediately displays it along with voltage and time data. Energy consumption is simply the area below the current trace.
The dynamic range of the onboard AEM system is from a minimum of 100nA to a maximum of 50mA and so is able to detect changes in current consumption in even the most energy sensitive applications. Note that it measures not only the current drawn by the MCU but also the current drawn by other prototype system components, as long as they are supplied from the power rail monitored by the AEM.
The MCU can also be set to output program counter samples through the ARM core’s standard serial wire output (SWO) pin. This information can be sent along with the development kit’s AEM current, voltage and timing data over USB to a Windows based software tool called the energyAware Profiler. Uploaded with the MCU’s code object file (*.out) (the Profiler software then has all the information it needs to directly correlate energy consumption with code and thereby implement ‘energy debugging’.
There are three main windows to the software tool: a code listing, a function listing and a current graph. By clicking on any point on the current graph, the corresponding portion of code giving rise to that current consumption is highlighted in the code listing. By default, shown on a logarithmic scale, the current graph can also be shown on a linear scale for greater detail. The function listing details the energy that each function consumes and the percentage of total system energy consumption for, which it accounts.
As well as showing the code associated with the current graph at a certain point in time, the code listing will also display a further data line revealing which function is running, the last PC sample, current, voltage and at what point in time the code was executed. Average current can also be calculated by highlighting a portion of the current graph. It is also possible to enable IRQ (interrupt request) pinpointing that shows a listing of different IRQs in different colours for easier identification.
Energy conscious
Until now, the energy footprint of a product was not really known until the very end of the design cycle, by which time optimisation of the code for energy efficiency was really impractical. As result, an oversized battery was often required, meaning an increase in product size, cost and complexity. A move to energy debugging tools enable designers to identify and remove energy bugs at the early stages of a design process without penalising development time.
