每个系统要正常运行都有赖于cpu 的性能, 系统软件, 中间件一集各种系统策略等等, 智能手机也是一样。这篇文章主要探讨了给智能手机选择合适的cpu, 以及在手机电源管理中的动态电源管理(dpm) 和自适应电压调整(avs) 技术。最后, 我还对手机软件设计进行一点优化工作, 实现了软件的节能设计。

关键词: linux;嵌入式系统;智能手机

引言

　　智能手机中包含了很多耗能设备, 诸如mp3、mpeg- 4、wi-fi、数码相机、3d 游戏等等。在手机电池容量还没有实现质的飞跃的前提下, 我们不得不考虑手机电源节能的问题。我主要通过了以下四个方面来阐述在基于linux 平台上的智能手机的解决方案。

cpu 的选择

　　尽管现在有了各种在不过多加重功耗负担的前提下提高性能的技术, 但用一个芯片来处理这么多各种各样的任务, 恐怕已经不是一个很好的选择了。一是因为这些功能对芯片处理功能的要求可能各不相同, 二是因为一个负担着如此众多任务的芯片势必需要很高的速度, 降低功耗变得很困难。

　　在这种情况下, 多cpu 系统(mpcore)成为一个必然的趋势。多cpu 系统的一个明显的优势是: 针对不同的任务处理需要, 不同的cpu 可以各尽其职, 将自身的优势充分发挥, 由此带给手机最优化的性能表现。另一个优势显然还是体现在对功耗的控制上: 假如用单cpu 来完成所有的功能, 不可避免地需要一个很高的cpu 速度, 从而造成很高的功耗。用一颗高速cpu 来完成这样的任务, 无疑是大牛拉小车, 同时浪费很多能源。多cpu 系统可以根据不同的任务需要合理地启动、停止相应的cpu 来完成任务,不需要的时候处于停歇状态, 实现最大限度地控制功耗。

　　 既然我们选择了多cpu 的架构, 那么接下来cpu 的性能就是我们要考虑的第二大问题。一般的情况下, 我们是在cpu 的性能( performance) 和功耗( power consumption) 方面进行比较和选择。通常可以采用每执行1m次指令所消耗的能量来进行衡量, 即watt/mips。

　　我们把cpu 的功率消耗分为两大部分: 内核消耗功率pcore和外部接口控制器消耗功率pi/o, 总的功率等于两者之和, 即ppcore+pi/o。对于pcore, 关键在于其供电电压和时钟频率的高低; 对于pi/o 来讲, 除了留意各个专门i/o 控制器的功耗外, 还必须关注地址和数据总线宽度。

　　在数字集成电路设计中, cmos 电路的静态功耗很低, 与其动态功耗相比基本可以忽略不计。cmos 电路动态功耗的计算公式如下:
　　pd=ct*v2*f, 其中pd 是cmos 芯片的动态功耗, c是cmos芯片的负载电容, v 是cmos 芯片的工作电压, f 是cmos 芯片的工作频率。

　　由上可见, 当cpu 确定后, 我可以通过降低频率和电压来减少系统的功耗。
在cpu 的选择方面, 我们推荐采用intel 的xscale 芯片, 以及ibm的powerpc405g 芯片。

动态电源管理(dpm)

　　系统不可能始终处于满负荷状态, 因为系统的工作量随时都在改变。动态电源管理(dpm) 通过选择性的将空闲的系统组件置于低能耗状态实现了系统整体能耗的最优化。

　　我们更为关注的是dpm在linux 框架结构下的实现。图1 展示了电源管理和嵌入式linux 堆栈之间的关系。

　　以下是一些于电源管理相关的接口以及api:

　　内核接口。在针对linux 的dpm 架构中, 内核中的dpm 子系统负责维持系统的电源状态, 并把dpm 系统的各个电源得到管理的元件联系在一起。dpm 子系统通过多个api 直接与设备驱动程序通信, 这些api 把驱动程序从完全运行状态转为各种电源得到管理的状态。策略管理器( 或应用软件自身) 通过多个api向dpm 子系统提供指导, 这些api 定义各种策略, 并在定义好的运行点之间转移整个系统。

　　驱动程序接口。启用了dpm 的设备驱动程序比默认驱动程序具有更多“状态”: 由外部事件通过各种状态来驱动它们, 或通过来自内核dpm 子系统的回调来驱动它们, 从而反映并遵循运行策略。驱动程序api 还允许驱动程序登记它们连接和管理的各个设备的基本运行特征, 从而实现更精细的策略决策。

　　用户程序api, 用户程序( 应用软件) 分为三类:
　　(1)可感知电源管理的应用软件; (2)可感知电源管理的“包装器”中的传统应用软件; (3)不带电源管理的传统应用软件。

　　可感知电源管理的应用软件能够充分利用来自策略管理器的api, 从而建立各自的基础约束, 并强制电源管理策略发生变化, 以便匹配各自的执行要求。不直接带有电源管理功能的传统应用软件可以“包装”到代码或补丁中, 从而实现相当的效果, 它们还可以按照默认行为来运行, 这取决于更宽范围的默认策略管理。
陈逸非,尹长青

　　每个系统要正常运行都有赖于cpu 的性能, 系统软件, 中间件一集各种系统策略等等, 智能手机也是一样。这篇文章主要探讨了给智能手机选择合适的cpu, 以及在手机电源管理中的动态电源管理(dpm) 和自适应电压调整(avs) 技术。最后, 我还对手机软件设计进行一点优化工作, 实现了软件的节能设计。

关键词: linux;嵌入式系统;智能手机

引言

　　智能手机中包含了很多耗能设备, 诸如mp3、mpeg- 4、wi-fi、数码相机、3d 游戏等等。在手机电池容量还没有实现质的飞跃的前提下, 我们不得不考虑手机电源节能的问题。我主要通过了以下四个方面来阐述在基于linux 平台上的智能手机的解决方案。

cpu 的选择

　　尽管现在有了各种在不过多加重功耗负担的前提下提高性能的技术, 但用一个芯片来处理这么多各种各样的任务, 恐怕已经不是一个很好的选择了。一是因为这些功能对芯片处理功能的要求可能各不相同, 二是因为一个负担着如此众多任务的芯片势必需要很高的速度, 降低功耗变得很困难。

　　在这种情况下, 多cpu 系统(mpcore)成为一个必然的趋势。多cpu 系统的一个明显的优势是: 针对不同的任务处理需要, 不同的cpu 可以各尽其职, 将自身的优势充分发挥, 由此带给手机最优化的性能表现。另一个优势显然还是体现在对功耗的控制上: 假如用单cpu 来完成所有的功能, 不可避免地需要一个很高的cpu 速度, 从而造成很高的功耗。用一颗高速cpu 来完成这样的任务, 无疑是大牛拉小车, 同时浪费很多能源。多cpu 系统可以根据不同的任务需要合理地启动、停止相应的cpu 来完成任务,不需要的时候处于停歇状态, 实现最大限度地控制功耗。

　　 既然我们选择了多cpu 的架构, 那么接下来cpu 的性能就是我们要考虑的第二大问题。一般的情况下, 我们是在cpu 的性能( performance) 和功耗( power consumption) 方面进行比较和选择。通常可以采用每执行1m次指令所消耗的能量来进行衡量, 即watt/mips。

　　我们把cpu 的功率消耗分为两大部分: 内核消耗功率pcore和外部接口控制器消耗功率pi/o, 总的功率等于两者之和, 即ppcore+pi/o。对于pcore, 关键在于其供电电压和时钟频率的高低; 对于pi/o 来讲, 除了留意各个专门i/o 控制器的功耗外, 还必须关注地址和数据总线宽度。

　　在数字集成电路设计中, cmos 电路的静态功耗很低, 与其动态功耗相比基本可以忽略不计。cmos 电路动态功耗的计算公式如下:
　　pd=ct*v2*f, 其中pd 是cmos 芯片的动态功耗, c是cmos芯片的负载电容, v 是cmos 芯片的工作电压, f 是cmos 芯片的工作频率。

　　由上可见, 当cpu 确定后, 我可以通过降低频率和电压来减少系统的功耗。
在cpu 的选择方面, 我们推荐采用intel 的xscale 芯片, 以及ibm的powerpc405g 芯片。

动态电源管理(dpm)

　　系统不可能始终处于满负荷状态, 因为系统的工作量随时都在改变。动态电源管理(dpm) 通过选择性的将空闲的系统组件置于低能耗状态实现了系统整体能耗的最优化。

　　我们更为关注的是dpm在linux 框架结构下的实现。图1 展示了电源管理和嵌入式linux 堆栈之间的关系。

　　以下是一些于电源管理相关的接口以及api:

　　内核接口。在针对linux 的dpm 架构中, 内核中的dpm 子系统负责维持系统的电源状态, 并把dpm 系统的各个电源得到管理的元件联系在一起。dpm 子系统通过多个api 直接与设备驱动程序通信, 这些api 把驱动程序从完全运行状态转为各种电源得到管理的状态。策略管理器( 或应用软件自身) 通过多个api向dpm 子系统提供指导, 这些api 定义各种策略, 并在定义好的运行点之间转移整个系统。

　　驱动程序接口。启用了dpm 的设备驱动程序比默认驱动程序具有更多“状态”: 由外部事件通过各种状态来驱动它们, 或通过来自内核dpm 子系统的回调来驱动它们, 从而反映并遵循运行策略。驱动程序api 还允许驱动程序登记它们连接和管理的各个设备的基本运行特征, 从而实现更精细的策略决策。

　　用户程序api, 用户程序( 应用软件) 分为三类:
　　(1)可感知电源管理的应用软件; (2)可感知电源管理的“包装器”中的传统应用软件; (3)不带电源管理的传统应用软件。

　　可感知电源管理的应用软件能够充分利用来自策略管理器的api, 从而建立各自的基础约束, 并强制电源管理策略发生变化, 以便匹配各自的执行要求。不直接带有电源管理功能的传统应用软件可以“包装”到代码或补丁中, 从而实现相当的效果, 它们还可以按照默认行为来运行, 这取决于更宽范围的默认策略管理。