This is the first article from a series of five, presenting good practices and suggestions on how to design Embedded Systems for Low Power.
The articles will be published at a rate of one per week. Feedback is welcomed.
1. Power Debugging
Power debugging is a method that measures how much power is being consumed when your application is running, and correlates it with the program’s execution flow. Because it is software that controls the hardware power consumption, there is much to gain also for you as a software developer by being aware of how your code affects power consumption.
By coupling the source code to the power consumption, you can test and tune your application to optimize the power consumption. The technology for power debugging is based on the ability to sample the power consumption and correlate each power sample with the program’s instruction sequence and hence with the source code. The key to accuracy is a good correlation between the instruction trace and the power samples, and this is only achieved when there is a close integration between the current measurement and the trace probe. In many cases, the target can be powered through the debug probe. In addition to handling the debug communication between the target and the host debugger, the probe can then also sample the current it is feeding to the target. It measures the voltage drop across a small resistor in series with the supply power to the device. The voltage drop is measured by a differential amplifier and then sampled by an AD converter. In this case the integration is very close and the accuracy should be good.
Another difficulty is to achieve high precision sampling. Ideally you would want to sample the power consumption for individual instructions, but the physical limitations of the target system and even the device itself makes this more or less impossible. A microcontroller running at 100 MHz should need be sampled at the same frequency, but the system capacitance makes it meaningless to sample any faster than at approximately 40 kHz. When sampling the power consumed by the entire system including off-chip peripherals and circuitry with all its combined capacitances, the meaningful sample rate will be even lower than that.
In practice this is not a problem though. As it is almost always more interesting to correlate the power consumption with various events in the program execution than with individual instructions, the resolution needed is much lower than one sample per instruction. Even though it would be interesting to see how much power the microcontroller consumes when executing individual instructions, your goal is most likely to make the battery last for as long as possible, and the battery powers the system, not just the microcontroller!
There are several development systems vendors, providing tools for power debugging; by using these tools, the power samples are visualized together with the interrupt activity on a shared timeline, giving you a quick understanding of how events and power consumption correlate also in complex execution flows. Usually, the Timeline window is correlated to the source code, so by selecting something in the Timeline window the corresponding line of source code will be highlighted.
In practice and in a task-oriented system it is probably more interesting to see how a particular function affects power consumption than to see statement by statement how the power consumption changes. A tool called Function profiler will help you find the functions where most time is spent during execution for a given stimulus. This can reveal functions that consume disproportionately much power.
In upcoming articles we will look at more hands-on examples illustrating the difficulty in identifying how a system unnecessarily consumes energy, and where the system can be optimized for power. Typically it is not explicit flaws in the source code that is exposed, but rather opportunities to adjust how the hardware is used. Some examples, however, involve what might be described as pure bugs.