首页 | 新闻 | 新品 | 文库 | 方案 | 视频 | 下载 | 商城 | 开发板 | 数据中心 | 座谈新版 | 培训 | 工具 | 博客 | 论坛 | 百科 | GEC | 活动 | 主题月 | 电子展
返回列表 回复 发帖

嵌入式系统电源的管理和功耗的控制更新

嵌入式系统电源的管理和功耗的控制更新

2硬件组成嵌入式系统中,为了支持动态电源和功耗的管理,对硬件和CPU有着特定的需求,而不同的CPU和外设为了满足这些需求,也有自己不同的实现方式。个人所接触的硬件种类有限,所以,这里主要以Monahans系列CPU为核心的系统为例,大致列一下所涉及到的硬件及相关功能特性。

2.1CPU首先当然是CPU

为了支持变频操作,CPU需要提供系统和总线频率的动态调整功能。
为了保证某些外设在系统总线频率改变时的正常工作,应该提供具体外设时钟的可变控制。
能够提供低功耗模式的状态控制和切换能力
能够提供相应的硬件唤醒机制,保证系统能从休眠状态恢复到正常工作状态。

Monahans系列的CPU还提供了一套硬件功能模块,用于监控CPU的各种核心操作。例如Cache的命中,内存控制器的请求数量统计等等,一方面可以用来为软件性能调试提供参考数据,另一方面,也可以作为系统硬件状态的一种监控手段,为动态电源管理提供信息来源。

2.2电源管理芯片由于CPU在低功耗模式下通常会工作在更低的核心电压下,所以要求电源管理芯片能对系统提供可以动态调整的输出电压。通过降低核心电压的手段降低系统的整体功耗。

2.3内存对于外部内存SDRAM来说,为了保证系统在休眠时不丢失信息,通常要求内存能够在无需CPU内存控制器的参与下,工作在自刷新模式。

2.4其它外设对于外设来说,理想的要求当然是能够受控或自动将自己致于尽可能低的功耗状态。

3软件框架
X86架构的PC中,BIOS在很大程度上承担了核心的电源管理功能,所以APMACPI或多或少在一定程度上都依赖于BIOS所提供的功能。

ARM架构的嵌入系统中,因为通常不会有BIOS,加上具体的CPU和外设千差万别,所以动态电源管理的软件实现框架也不尽相同。不过就我接触到的平台而言,基本上都会在PM的基础上实现休眠等相关的电源管理策略,而动态调频等功能,则各有各的实现方式,有基于DPM实现的,也有自己实现一套框架的。

3.1基于Monahans的电源管理框架基于Monahans系列CPU所提供的功能,我们在MarvellBSP所提供的相关代码的基础上所实现的动态电源管理的软件框架。



3.1.1Power Mode Management这部分代码基于PM实现,主要负责低功耗模式的进入退出相关过程的控制,它定义并实现了几种不同程度的低功耗模式,并负责完成对外设驱动的Suspend / Resume函数的调用。
3.1.2DVFM动态电压频率调整模块主要负责变频操作相关过程的控制,它定义和维护了一系列的操作点,用来描述和控制CPU核心频率,电压,各种总线频率等参数。同时它还负责维护和调用外设驱动向其注册的DVFM_notifier函数,在其完成变频操作前后,给外设提供一个机会执行相应的应对措施。
3.1.3Device Drivers设备驱动需要实现自己的DVFM_notifer函数,用来处理变频操作给自己带来的影响。或者用来通知DVFM禁止变频操作的执行。
此外,一些设备驱动还要为电源管理状态切换的决策提供输入信息,例如RTC闹钟等可能做为系统唤醒的唤醒源,而像键盘,触摸屏等的操作则标志着用户交互行为的发生等等。
3.1.4Workload Profiler系统负载采样模块同样是为电源管理状态的切换决策提供输入信息,这部分代码主要用来控制Monahans中性能监控相关硬件模块的工作。采样硬件活动信息,以监控例如内存总线的负载等。同时,在系统IDLE进程中,也利用对Idle的时间的统计等手段,为动态电源管理系统提供一个近似的CPU负载信息。
3.1.5Policy MakerPolicy Maker工作在用户层空间,它负责采集内核中上述各模块的相关信息并进行调度控制。它在用户空间实现了一套电源管理策略。作为Daemon进程,它为其它用户层代码提供一个统一的接口,用来通知其它应用程序电源状态的变化,以及接受并处理各种用户限制条件(例如播放视频时禁止熄灭背光等等)以正确进行系统状态的切换。

3.2动态电源管理策略的制定3.2.1电源管理的决策依据电源管理的决策依据,不外乎会有几个来源:

  • 系统硬件的工作状态
  • 上层应用程序的工作状态
  • 用户的交互情况

从系统硬件的角度来说,大致会包括:CPU和系统总线的负载情况,输入输出类设备的工作情况:例如是否存在大量的内存操作,是否有网络数据交互等,另外还包括电池是否处于低电量状态,是否在使用某些特殊的硬件设备等等。

上层应用程序的工作状态,可能包括:是否存在视频应用,是否允许关闭背光,是否对CPU速度有限制要求,是否允许系统进入睡眠状态等等。

而用户的交互情况,包括用户是否有键盘或其它IO设备输入等行为。

应该说,上述的几类决策来源往往不会是完全独立相互无关的,例如视频类应用的存在通常会使CPU处于一个较高的负载水平,大量的用户交互也可能让IO设备处于忙碌状态等等。所以,有时候,在进行电源管理决策时,可以合并一些信息来源,或者由一类情况的数据来涵盖另一类情况的发生可能。
3.2.2从用户的角度划分系统状态CPU和硬件的角度,设备可能处在不同的频点和不同的低功耗状态。
而从用户的角度,外在的表现大体可以划分为:

  • 系统正常工作状态:各类设备可以正常使用,背光全亮
  • 背光变暗状态:一段时间没有交互,系统可能自动调暗背光,提醒用户状态的变化。
  • 背光熄灭状态:背光熄灭,但是部分功能可能保持正常工作状态,如MP3的播放等。
  • 休眠状态:所有功能关闭,但是可以快速唤醒
  • 关机状态

因此,在Policy Maker中,需要根据实际情况维护系统的当前状态,并根据一定的顺序进行状态切换,例如按照CPU等占用情况进行变频控制,根据应用和用户的交互控制背光状态等,以求最大限度的兼顾系统的易用性和功耗。
返回列表