高性能与有限的电池能量在嵌入式系统中矛盾最为突出#xff0c;硬件低功耗设计与软件低功耗管理的联合应用成为了解决矛盾的有效手段。

嵌入式系统低功耗管理的目的在于满足用户对性能需求的前提下尽可能降低系统功耗以延长设备待机时间。

高性能与有限的电池能量在嵌入式系统中矛盾最为突出硬件低功耗设计与软件低功耗管理的联合应用成为了解决矛盾的有效手段。

MCU

比如主控时钟频率的调整工作电压的改变总线频率的调整甚至关闭外围设备工作时钟的关闭等。

有了硬件上的支持合理的软件设计就成为节能的关键一般可以把低功耗管理分为三个类别

处理器电源管理对CPU频率动态管理以及系统空闲时对工作模式的调整。

设备电源管理

随着物联网

的兴起产品对功耗的需求越来越强烈。

作为数据采集的传感器节点通常需要在电池供电时长期工作而作为联网的

SOC

在产品开发的起始阶段首先考虑是尽快完成产品的功能开发。

在产品功能逐步完善之后就需要加入电源管理

(Power

提供了电源管理组件。

电源管理组件的理念是尽量透明使得产品加入低功耗功能更加轻松。

基于模式来管理功耗空闲时动态调整工作模式支持多个等级的休眠。

对应用透明组件在底层自动完成电源管理。

支持运行模式下动态变频根据模式自动更新设备的频率配置确保在不同的运行模式都可以正常工作。

支持设备电源管理根据模式自动管理设备的挂起和恢复确保在不同的休眠模式下可以正确挂起和恢复。

支持可选的休眠时间补偿让依赖OS

工作原理

低功耗的本质是系统空闲时CPU停止工作中断或事件唤醒后继续工作。

在RTOS中通常包含一个IDLE任务该任务的优先级最低且一直保持就绪状态当高优先级任务未就绪时OS执行IDLE任务。

RTT的电源管理组件在IDLE任务中通过对CPU、时钟和设备等进行管理从而有效降低系统的功耗。

IDLE

在IDLE任务执行时它将判定系统是否可以进入到睡眠状态以节省功耗。

此时电源管理框架会根据系统定时器情况计算出下一个超时时间点并设置低功耗定时器让设备能够在这个时刻点唤醒并进行后续的工作。

当系统被低功耗定时器中断或其他唤醒中断源唤醒后系统也需要知道睡眠时间长度是多少并对OS

Tick

外设或应用通过投票机制对所需的功耗模式进行投票当系统空闲时根据投票数决策出合适的功耗模式调用抽象接口控制芯片进入低功耗状态从而降低系统功耗。

与应用不同某些外设可能在进入低功耗状态时执行特定操作退出低功耗时采取措施恢复此时可以通过注册PM设备来实现。

通过注册PM设备在进入低功耗状态之前会触发注册设备的suspend回调开发者可在回调里执行自己的操作类似地从低功耗状态退出时也会触发resume回调。

低功耗状态和模式

PM组件将系统划分为两种状态运行状态RUN和休眠状态SLEEP。

运行状态控制CPU的频率适用于变频场景休眠状态根据SOC特性实现休眠CPU以降低系统功耗。

API

休眠状态又分为六个模式呈现为金字塔的形式。

随着模式增加功耗逐级递减的特点。

下面是休眠状态下模式的定义开发者可根据具体的

SOC

的运行频率独立于休眠模式。

当前运行状态划分了四个等级高速、正常、中速、低速如下

组件里上层应用可以通过请求和释放休眠模式主动参与功耗管理。

应用可以根据场景请求不同的休眠模式并在处理完毕后释放只要有任意一个应用或设备请求高等级的功耗模式就不会切换到比它更低的模式。

因此休眠模式的请求和释放的操作通常成对出现可用于对某个阶段进行保护如外设的

DMA

共用一部分时钟那外设的时钟就会受到影响在进入新的休眠模式大部分时钟源会被停止如果外设不支持休眠的冻结功能那么从休眠唤醒的时候外设的时钟就需要重新配置外设。

所以

设备。

使得设备在切换到新的运行模式或者新的休眠模式都能正常的工作。

该功能需要底层驱动实现相关的接口并注册为对模式变化敏感的设备。

首先应用设置进出休眠状态的回调函数然后调用rt_pm_request请求休眠模式触发休眠操作PM

组件调用

实现的的休眠模式系统进入休眠状态如果使能时间补偿休眠之前会先启动低功耗定时器。

此时

CPU

停止工作等待事件或者中断唤醒。

当系统被唤醒后由于全局中断为关闭状态系统继续从该处执行获取睡眠时间补偿系统的心跳依次唤醒设备通知应用从休眠模式退出。

如此一个周期执行完毕退出等待系统下次空闲。

调用该函数会将对应的模式计数加1并锁住该模式。

此时如果请求更低级别的功耗模式将无法进入只有释放解锁先前请求的模式后系统才能进入更低的模式向更高的功耗模式请求则不受此影响。

该函数需要和

rt_pm_release

绝大部分的嵌入式系统都包含一些I/O输入/输出设备例如仪器上的数据显示屏、工业设备上的串口通信数据采集设备上用于保存数据的Flash或SD卡以及网络设备的以太网接口等都是嵌入式系统中容易找到的I/O设备例子。

I/O设备模型框架

RTT提供了一套简单的I/O设备模型框架它位于硬件和应用程序之间共分成三层从上到下分别是I/O设备管理层设备驱动框架层设备驱动层。

应用程序通过I/O设备管理接口获得正确的设备驱动然后通过这个设备驱动与底层I/O硬件设备进行数据交互。

I/O设备管理层实现了对设备驱动程序的封装。

应用通常图中的“I/O设备管理层”提供的标准接口访问底层设备设备驱动程序的升级、更替不会对上层应用产生影响。

这种方式使得设备的硬件操作相关的代码能够独立于应用程序而存在双方只需关注各自的功能实现从而降低了代码的耦合性、复杂性提高了系统的可靠性。

设备驱动框架层是对同类硬件设备驱动的抽象将不同厂家的同类硬件设备驱动中相同的部分抽取出来将不同部分留出接口由驱动程序实现。

设备驱动层是一组驱使硬件设备工作的程序实现访问硬件设备的功能。

它负责创建和注册I/O设备对于操作逻辑简单设备可以不经过设备驱动框架层直接将设备注册到I/O设备管理器中。

设备驱动根据设备模型定义创建出具备硬件访问能力的设备实例将该设备通过rt_device_register()接口注册到I/O设备管理器中。

应用程序通过rt_device_find()接口查找到设备然后使用I/O设备管理接口来访问硬件。

对于另一些设备如看门狗等则会将创建的设备实例先注册到对应的设备驱动框架中再由设备驱动框架层向I/O设备管理层进行注册。

看门狗设备驱动层根据看门狗设备模型定义创建出具备硬件访问能力的看门狗设备实例并将该看门狗通过rt_hw_watchdog_register()接口注册到看门狗设备驱动框架中。

看门狗设备驱动通过rt_device_register()接口将看门狗设备注册到I/O设备管理器中。

应用程序通过I/O设备管理接口来访问看门狗设备硬件。

I/O设备模型

RTT的设备模型是建立在内核对象模型基础之上的设备被认为是一类对象被纳入对象管理器的范畴。

每个设备对象都是由基对象派生而来每个具体设备都可以继承其父类对象的属性并派生出私有属性。

struct

其中字符设备、块设备是常用的设备类型它们的分类依据是设备数据与系统之间的传输处理方式。

字符模式设备允许非结构的数据传输通常数据传输采用串口的形式每次一个字节。

这个数据块是硬件强制性的数据块可能使用某类数据接口或某些强制性的传输协议否则就可能发生错误。

驱动层负责创建设备实例并注册到I/O设备管理器中可以通过静态声明的方式创建设备实例也可以通过下面的接口进行动态创建

rt_device_t

attach_size);调用该接口时系统会从动态内存堆中分配一个设备控制块大小为struct

rt_device和attach_size的和设备的类型由参数

type

(RT_DEVICE_FLAG_ACTIVATED)。

如果设备控制块中的

flag

标志已经设置成激活状态那么再运行初始化接口时会立刻返回而不会重新进行初始化。

open打开设备。

有些设备并不是系统一启动就已经打开开始运行或者设备需要进行数据收发但如果上层应用还未准备好设备也不应默认已经使能并开始接收数据。

所以建议在写底层驱动程序时在调用

open

接口时才使能设备。

close关闭设备。

在打开设备时设备控制块会维护一个打开计数在打开设备时进行

操作在关闭设备时进行

是读取数据的偏移量但是有些设备并不一定需要指定偏移量例如串口设备设备驱动应忽略这个参数。

而对于块设备来说pos

size

rt_size_t即读到的字节数或块数目。

正常情况下应该会返回参数中

size

rt_size_t即真实写入数据的字节数或块数目。

正常情况下应该会返回参数中

size

命令控制设备。

命令往往是由底层各类设备驱动自定义实现。

例如参数

RT_DEVICE_CTRL_BLK_GETGEOME意思是获取块设备的大小信息。