Power management has been a hot topic - or maybe that should read "a cool topic" - among embedded developers in recent years. Its importance is largely driven by the requirements to extend battery life for handheld devices, but environmental hazards, heat dissipation, etc., are raising concerns.
There are, effectively, three kinds of power saving procedures that embedded software might implement:
- Use dynamic voltage and frequency scaling (DVFS) to tune the CPU performance to the needs of the moment.
- Disable (power down) currently unused peripheral circuitry.
- Make use of the CPU's low power modes.
(1) and (2) are quite straightforward, but (3) needs some more careful consideration …
Superficially, it would seem obvious that, if the silicon vendor has provided a processor with low power modes and your design needs to be power efficient, you should make extensive use of them. Right? Well, maybe, but it all depends on the kind of application that you are developing.
Although many CPUs have multiple low-power modes, which have subtle nuances, there are broadly two possibilities (where the terminology is far from standardized):
- Suspend - The entire system is powered down, except the memory, which is kept alive to retain the data/code. This mode reduces power consumption very substantially.
- Hibernate - Everything is powered down, including the memory, the contents of which have been saved to flash memory. This mode cuts power consumption to almost zero.
Both of these modes can be very useful, but that usefulness comes at a cost. The nature and impact of that cost depends on the specific application, but it is manifested in two ways:
- Responsiveness - It takes time to enter/exit these modes. Hibernate is the slower but Suspend requires a finite time. This lag might affect the responsiveness of a device from a user's perspective; this might motivate the user to take steps to avoid the device going into a power saving state and, thus, render much of the power management design redundant. For a hard-real-time application, a device being in Suspend may result in it being unable to respond to an external event in a timely fashion.
- Power - Surprisingly, the use of these modes can result in more power being consumed! This can occur if the frequency with which the modes are used is too great. Some code is used to affect the entry/exit and that code execution uses energy. Utilizing these modes for short periods of time is a problem because the power saved while in the mode may not offset that used to enter/exit.
Overall, designing a system for low power requires a wholistic approach, driven by an analysis of use cases – distinct ways that the device operates – as each has its own power requirements. Most important of all, design for low power must start on Day One – it should not be an afterthought, implemented because design criteria have not been met.