Page 1
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.
Colin Walls
[email protected]
Power Management in Embedded
Systems
Page 2
Agenda
Introduction
Hardware choice
Use cases
Operating system
BSP and drivers
Hibernate/suspend
Application development
Measurement and testing
Conclusions
Page 3
Agenda
Introduction
Hardware choice
Use cases
Operating system
BSP and drivers
Hibernate/suspend
Application development
Measurement and testing
Conclusions
Page 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
Page 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
Page 7
Introduction
• Choose appropriate hardware
• Consider usage
• Select operating system
• Address driver/BSP issues
• Application code has least influence on power
Page 8
Agenda
Introduction
Hardware choice
Use cases
Operating system
BSP and drivers
Hibernate/suspend
Application development
Measurement and testing
Conclusions
Page 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
Page 10
Agenda
Introduction
Hardware choice
Use cases
Operating system
BSP and drivers
Hibernate/suspend
Application development
Measurement and testing
Conclusions
Page 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
Page 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
Page 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
Page 14
Use cases for example
Determine early whether estimated battery life is achievable
Use Case Average Current (mA)
Duration (s)
Frequency per day
Total time (s/day)
ENERGY USED (mAh/day)
Vitals Measurement 158 1 288 288 13Data Upload 250 3 288 864 60User Vitals Check 320 30 15 450 40Idle (Hibernate) 1 84798 24TOTAL 136
Page 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
Page 16
Agenda
Introduction
Hardware choice
Use cases
Operating system
BSP and drivers
Hibernate/suspend
Application development
Measurement and testing
Conclusions
Page 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
Page 18
Power framework
= Hardware power management
= RTOS Power Mgmt Framework
= Application Software
Page 19
Agenda
Introduction
Hardware choice
Use cases
Operating system
BSP and drivers
Hibernate/suspend
Application development
Measurement and testing
Conclusions
Page 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
Page 21
Agenda
Introduction
Hardware choice
Use cases
Operating system
BSP and drivers
Hibernate/suspend
Application development
Measurement and testing
Conclusions
Page 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
Page 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
Page 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
Page 25
Agenda
Introduction
Hardware choice
Use cases
Operating system
BSP and drivers
Hibernate/suspend
Application development
Measurement and testing
Conclusions
Page 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
Page 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
Page 28
Agenda
Introduction
Hardware choice
Use cases
Operating system
BSP and drivers
Hibernate/suspend
Application development
Measurement and testing
Conclusions
Page 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
Page 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]
Page 31
Measurement and testing
Drivers should have power functionality thoroughly tested:
– Properly enable/disable hardware
– Participate in DVFS
– Inform the OS of DMA requirements
Page 32
Power Consumption at Various OPs
SOC Current Consumption(mA)
i.MX28 Board
Operating Point voltage (1.5V)
470
370
230
200
OP#3 454 MHz
OP#2 297 MHz
OP#1 63 MHz
OP#0 1 MHz
38Standby
0Hibernate
0 100 200 300 400 500
Page 33
Impact on Battery Life …
mAh(Board)
PercentageUsage per
hr
mAh Battery (hrs)
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
Nucleus Power Management Framework
mAh(Board)
Battery (hrs)
OP #3 470
Total 5
No Power Management
Page 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
Page 35
Agenda
Introduction
Hardware choice
Use cases
Operating system
BSP and drivers
Hibernate/suspend
Application development
Measurement and testing
Conclusions
Page 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
Page 37
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.
Colin Walls
[email protected]
http://blogs.mentor.com/colinwalls
Thank you