Design considerations for power-sensitive embedded devices
Application Development
Application is the last tier of software that can limit overall system power performance. Badly written application can completely decimate power efficiency.
This is another area where having an operating system with built-in power features can help tremendously. In such an OS, one or more applications can be written, each running as one or more threads, concentrating solely on its own task at hand and reporting to the OS its power needs.
Using our hypothetical medical device, one such independent application can be written to collect all the vitals data. That application would simply indicate to the OS what peripheral device drivers are needed to complete its task, what minimum operating point is required, etc.
Once the application completes its task it simply lets the OS know that it no longer requires those resources. It also relinquishes the CPU by using blocking calls and/or using sleep APIs to allow the OS to schedule another task and/or switch the CPU to an idle or other low power mode.
A separate application that uploads the data would take the exact same approach, informing the OS only about its own requirements and yielding the CPU when not needed. The OS will in turn consider all running applications and their needs, turning on what is needed only when needed and set the appropriate operating point in order to minimize the system power consumption.
Very little, if any, communication between the two application writers is required; the OS power framework is all they need to know about. This also has an added benefit of application code reusability on other designs using the same operating system.
Measurement, Tracking and Testing
Power should be measured from the very first day of code development. What makes this possible is the up-front planning by setting power requirements for individual drivers, clearly defining the use cases, and mapping those use cases to each application in the system.
Both application and BSP code developers should be equipped to measure power and should consider meeting power requirement as part of the code functionality. A Wi-Fi driver, for example, that works great with all wireless networks is not complete if it cannot be turned off in such a way as to disable all the hardware and reduce its power consumption to almost nothing while disabled.
That same driver should also be able to turn back on and be just as functional as the first time it was on. Subsequently, it should be able to perform this on/off cycle 100,000 times and more with the same results.
This may seem obvious, but a lot of developers get caught on this. All drivers should have their power functionality tested thoroughly to ensure they properly enable/disable hardware, participate in DVFS transitions, and inform the OS of the DMA transaction if required.
Final Optimizations
When using the aforementioned approach, once you get to code complete, your power performance should already be meeting your system requirements. However, there may be room for more optimization. Making your device last longer can allow for smaller battery size or accommodate more feature functionality.
Measuring the power for each planned use case and applying the energy usage analysis mentioned earlier can guide you to assess where the “biggest bang for the money” is as far as applying optimization efforts. The optimization can also include changing operating parameters by adjusting or even creating new use cases.
Summary
Power will continue to challenge embedded developers. As hardware vendors offer more tantalizing power saving features it becomes crucial that the software fully utilize them. As systems become more complex, it becomes increasingly and prohibitively impractical to ignore the proper up-front planning for system power consumption while hoping to power optimize on the back-end of the development process.
Adam Kaiser is a Nucleus RTOS architect for the Mentor Embedded team at Mentor Graphics. He has extensive expertise in embedded power management and is responsible for architecture of the Nucleus Power Management Framework. Prior to joining Mentor Graphics, Adam worked as a software architect for Texas Instruments (OMAP) and for Microsoft (Windows Mobile) where he worked closely with various mobile phone and other embedded device manufacturers focusing on power management.
Loading comments... Write a comment