Power Management in Embedded Systems – Colin Walls
The importance of power management in today’s embedded designs has been steadily growing as an increasing number of battery powered devices are developed. Often power optimizations are left to the very end of the project cycle, almost as an afterthought. In this presentation we will discuss design considerations that should be made when starting a new power sensitive embedded design, which include choosing the hardware with desired capabilities, defining a hardware architecture that will allow software to dynamically control power consumption, defining appropriate power usage profiles, making the appropriate choice of an operating system and drivers, choosing measurable power goals and providing these goals to the software development team to track throughout the development process.
2024: Domino Containers - The Next Step. News from the Domino Container commu...
Power Management in Embedded Systems
1. Power Management
in Embedded
Systems
Colin Walls
colin_walls@mentor.com
mentor.com/embedded
Android is a trademark of Google Inc. Use of this trademark is subject to Google Permissions.
Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.
5. Introduction
Importance of power steadily growing
Mainly complex battery-powered devices
Demand for connectivity
Power optimization often done late
Needs to be considered from the outset
6. Introduction
Choose hardware with right capabilities
Allow software to manage power
Choose OS and drivers
Define power usage profiles
Choose measurable goals
Use goals throughout development process
7. Introduction
• Choose appropriate
hardware
• Consider usage
• Select operating
system
• Address driver/BSP
issues
• Application code
has least influence
on power
9. Hardware choice
Biggest influence on power consumption
– Defines the very best case power saving
CPU features
– Turn off blocks; e.g. Peripherals
– Dynamic Voltage and Frequency Scaling (DVFS)
– Defines operating points
– Low power modes
Need to look at wider design to ensure compatibility
with above
11. Use cases
Function that a device performs
– With or without user interaction
Hypothetical example:
– Medical device
– Battery powered
– LCD display
– Monitors vital signs
– Uploads data via Wi-Fi
12. Use cases for example
1. Device takes a complete measurement
2. Device uploads a set of measured data
3. User checks his/her own vitals using a built in display
4. Device is idle awaiting the next measurement
13. Use cases for example
How much functionality needed for each use case?
– Hence which drivers [hardware blocks] need to be enabled
per use case?
Estimated energy for each use case:
– Estimated power consumption
– Estimated time in use case
Applying use case expected frequency as scaling
factor leads to energy breakdown showing battery
charge usage over time period
14. Use cases for example
Use Case Average Current Duration Frequency per Total time ENERGY USED
(mA) (s) day (s/day) (mAh/day)
Vitals
Measurement 158 1 288 288 13
Data Upload 250 3 288 864 60
User Vitals
Check 320 30 15 450 40
Idle (Hibernate) 1 84798 24
TOTAL 136
Determine early whether estimated
battery life is achievable
15. Use cases for example
Data Upload is highest use of energy
Maybe measure and upload every 5 minutes is too
costly
Perhaps measure every 5 minutes, but upload every
30 minutes
– Also upload if there is a major change in vitals
User Vitals Check is second biggest
– Assumes 30 second display timeout
– Maybe it could be shorter
– Most other hardware shut down in this use case
17. Operating system
Significant impact on power saving
Must support low power features
– DVFS
– Idle/sleep modes
Native power framework most efficient
– BSP must be written to address power issues
– Each driver has well defined power states
18. Power framework
= Hardware power management
= Application Software
= RTOS Power Mgmt Framework
20. BSP and drivers
Define power requirements for each driver. Specify:
– Which power states is supports
– ON, STANDBY, SLEEP, OFF
– What operating points will the driver be used at. For
example:
– While ON it must work at 200MHz and 100MHz
– SLEEP may result in 1MHz clock
– DVFS participation
– DMA transfer notification
22. Hibernate/suspend
Some hardware facilitates very low power consumption
modes
– Suspend: all hardware switched off, except for RAM, the
contents of which are protected
– Hibernate: RAM contents are stored in non-volatile
memory and everything switched off
23. Hibernate/suspend
Cost to enter/exit these modes
– Power
– Time – device responsiveness
Depends on how much of the system is ON when
mode is entered
– Need to save state and reinitialize
Hibernate also has cost of storing RAM, which varies
with the amount of RAM in use
– Also potentially reduces system lifetime
24. Hibernate/suspend
Does power benefit offset costs?
For example device, depends on:
– Measurement interval
– How often wake up is required
Adjusting measurement interval might make suspend
or hibernate efficient or expensive
26. Application development
Last layer of software
Badly written code can very adversely affect power
performance
An OS with built-in power features [a framework]
simplifies matters
– Application code writer is then less concerned with details
27. Application development
Application consists of a number of independent
tasks/threads
Each task [or group of tasks] registers its power needs:
– Which peripherals are used
– Minimum operating point
OS takes care of power management along with
context switch
29. Measurement and testing
Power should be measured from day #1
Possible by planning:
– Setting power requirements for drivers
– Defining use cases
– Mapping use cases to applications
All software engineers should be equipped to measure
power
30. Measurement and testing
Meeting power requirements should be regarded as
part of code functionality
For example:
– A Wi-Fi driver may work well with all wireless networks
– Must be able to be turned off and reduce power to [near]
zero
– Must turn back on and be fully functional
– Functionality must be repeatable [say, 100,000 times]
31. Measurement and testing
Drivers should have power functionality thoroughly
tested:
– Properly enable/disable hardware
– Participate in DVFS
– Inform the OS of DMA requirements
32. Power Consumption at Various
OPs
Operating Point Hibernate 0
voltage
(1.5V) Standby 38
OP#0 1 MHz 200
OP#1 63 MHz 230
OP#2 297 MHz 370
OP#3 454 MHz 470
0 100 200 300 400 500
SOC Current Consumption
(mA)
i.MX28 Board
33. Impact on Battery Life …
mAh Percentage mAh Battery
(Board) Usage per (hrs)
hr
OP #3 470 10% 47
OP #2 370 5% 19
OP #1 230 10% 23
OP #0 200 15% 30
Standby 38 20% 8
Hibernate 0 40% 0
Total 126 19
mAh Battery
(Board) (hrs)
Nucleus Power Management Framework
OP #3 470
Total 5
No Power Management
34. Final optimizations
The approach discussed should yield power
performance on spec.
There may be room for more optimization
Do final review of use cases
Possible changes:
– Different operating parameters
– New use cases
36. Conclusions
Power will continue to be a challenge for embedded
developers
– No longer a “hardware issue”
Support for new power saving hardware features is
essential
With complex software, it is not possible to ignore up-
front power planning
– Power optimization at the end is impractical
37. Thank you
Colin Walls
colin_walls@mentor.com
http://blogs.mentor.com/colinwalls
mentor.com/embedded
Android is a trademark of Google Inc. Use of this trademark is subject to Google Permissions.
Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.
