Power debugging is beginning to appear as a concept in the embedded industry, but what do we mean? In this article we will take a look at what is driving this need in embedded systems, and the way to optimize software to minimize an application’s power consumption.
Today, many embedded systems are powered by battery or via a signal cable. We see them in almost any market segment; medical, consumer electronics, home automation and many more. A common design goal for all these systems is that the power consumption must be low. Convenience, environmental awareness and costs are all contributing factors in choosing products that do not require us to constantly change the battery.
The design goals of low power consumption and a long battery lifetime have traditionally been the domain of hardware developers. As more battery-powered applications become controlled by a microcontroller, the hardware manufacturers present products with functionality and characteristics that contribute to lower power consumption and hence longer battery lifetime.
But in an active system, power consumption does not only depend on the design of the hardware, but also of how it is used. Of course, how it is used is determined by the system software.
The software developers’ domain on the other hand has always been to develop applications that are as efficient as possible and use as little memory as possible. In low-power systems power consumption is a third dimension that needs to be taken into account. However, the lack of proper tools has prevented power consumption to become an integrated part of the software development process.
Recently an innovative technology that achieves just what has been missing, integrating the system's power consumption in the development of software for embedded systems, has been announced by IAR Systems. The term used to describe this approach is what is called 'power debugging'.
How does power debugging work?
By correlating a system's momentary power consumption with its software, a dynamic analysis tool that shows how the software affects and steers the power consumption is obtained. This is the fundamental approach for how to provide insight into how power consumption can be minimized.
In embedded systems, peripheral devices often account for much of the power consumption. As software controls how they are used, regardless of whether they are integrated into the microcontroller or not, it also controls the system's power consumption. By exercising better control of the hardware, system power consumption can be reduced. Because of this it is also important to consider the whole system and not just the processor when correlating power consumption to the software. In other words, there is more to be done to minimize power consumption than simply trying to spend as much time as possible in an inactive CPU state.
The technology for power debugging is based on the ability to sample the power consumption and correlate each sample with the program's instruction sequence and hence with the source code. One difficulty is to achieve high precision with sampling. Ideally you could sample the power consumption with the same frequency the system clock uses, but system capacity will reduce the reliability of such measurements. Simply put, the measured power consumption will be ‘smeared’ in relation to what is actually being consumed by the CPU and peripherals.
In practice this is not a problem though. As from the software developer's perspective it is more interesting to correlate the power consumption with the source code and various events in the program execution than with individual instructions, so the resolution needed is much lower than one sample per instruction. For example, it is more interesting to see how a particular function call affects power consumption than to see instruction by instruction how power consumption changes.With power profiling we denote measuring the power consumption of certain sections of the software, for example at function call level. In this way, regions in the application where optimizations for power consumption should be done can be exposed. Typically it is not explicit flaws in the source code that is exposed, but rather opportunities to tune how the hardware is utilized.
Sometimes, however, it may involve what might be described as pure bugs. When it comes to power consumption, it is not always the case that they will be detected even if they are triggered. The system can appear to be fully functional and behave as expected in tests, but the power consumption can be much higher than it should.Let’s take an example to illustrate the difficulty in identifying how a system unnecessarily consumes energy.
Figure 1 shows a schematic diagram of the power consumption of an event driven system where the system at t0 is in an inactive mode and the current is i0. At t1 the system is activated whereby the current rises to i1, which is the system's power consumption in active mode with peripherals turned off. When the system is activated, however, at least one peripheral device is used, causing the current to rise to i2. At t2 the execution becomes suspended by an interrupt that is handled with high priority.
Peripheral devices that were already active are not turned off, although the thread with higher priority is not using them. Instead, more peripheral devices are activated by the new thread, resulting in an increase in current i3 between t2 and t3 where control is handed back to the thread with lower priority.
Fig 1: Power consumption of an event driven system.
The functionality of the system could be excellent and it can be optimized in terms of execution speed and code size. But in the power domain more optimizations can be done. The shadowed area represents the energy that could have been saved if the peripherals that are not used between t2 and t3 had been turned off, or if the priorities of the two threads could have been changed.
Using power debugging would have made it easy to discover the extraordinary increase in power consumption that occurs when the interrupt hits and identify it as abnormal. A closer examination of the system state could then identify that unused peripheral devices were activated and consuming power. Naturally there would have to be a review of whether it is worth to spend extra clock cycles to turn on and off peripherals in a situation like the example describes.
Power debugging is a new area in software development, but given the large volume of systems designed for low power and the potential to further extend battery lifetime of these systems, it is nevertheless a very valuable step for the embedded industry. IAR Systems continues to develop technology and tools for power debugging.
Tomas Hedqvist is Global Account Manager at IAR Systems