2. RT-Thread电源管理框架：PM组件架构解析
好，咱们进入正题。RT-Thread的电源管理，核心就是PM组件。说白了，它就是个“调度员”，负责告诉系统什么时候该睡，什么时候该醒，睡多深。
我个人习惯把PM组件想象成一个“三层小楼”：
- 顶层：应用层——你的业务代码，比如传感器采集、数据上报。
- 中间层：PM组件核心——负责策略决策，比如该不该休眠。
- 底层：驱动层——具体操作硬件寄存器，比如关时钟、降电压。
嗯，这里要注意，PM组件不是万能的。它只负责“协调”，真正干活的是驱动。我在项目中遇到过有人以为装了PM组件就能自动省电，结果发现外设根本没关——那功耗能降下来才怪。
2.1 电源管理核心数据结构
先看几个关键的数据结构。它们是PM组件的“骨架”。
2.1.1 请求结构体：rt_pm_request
每个外设或任务想“阻止系统休眠”，就得发一个请求。结构体长这样：
struct rt_pm_request {
rt_uint8_t type; // 请求类型：睡眠、运行、深度睡眠等
rt_uint8_t priority; // 优先级，数值越小越重要
void *data; // 私有数据，一般用不到
};
你想想看，为什么要有优先级？假设你的蓝牙模块正在传数据，突然来了个按键中断。按键处理优先级高，得先响应。PM组件会根据优先级决定“谁说了算”。
2.1.2 模式结构体：rt_pm_mode
这个结构体描述了一种电源模式。比如“轻度睡眠”和“深度睡眠”的区别：
struct rt_pm_mode {
rt_uint8_t mode; // 模式编号，0~N
rt_uint32_t latency; // 进入/退出该模式的延迟（us）
rt_uint32_t power; // 该模式下的功耗（uA）
};
我记得有一次调试，发现系统总是进入深度睡眠，但唤醒要花5ms。结果传感器数据全丢了。后来我加了个延迟检查——如果下次采样间隔小于10ms，就不进深度睡眠。这就是latency字段的用处。
2.1.3 设备结构体：rt_pm_device
每个支持电源管理的设备，都要注册一个这样的结构体：
struct rt_pm_device {
struct rt_device parent; // 继承自标准设备
const struct rt_pm_ops *ops; // 操作函数集
rt_uint8_t current_mode; // 当前电源模式
rt_uint32_t suspend_count; // 挂起计数，防止重复操作
};
这里有个坑：suspend_count 是干嘛的？防止你连续调用两次挂起，结果设备状态乱了。我曾经在某个项目里没处理好这个计数，导致设备挂起后无法唤醒——嗯，那次排查花了我整整一个下午。
2.2 核心API接口
API接口是PM组件的“门面”。你不需要知道底层怎么操作寄存器，只要调用这些函数就行。
2.2.1 请求与释放
| 函数 | 作用 |
|---|---|
rt_pm_request(rt_uint8_t mode) | 请求进入某种电源模式 |
rt_pm_release(rt_uint8_t mode) | 释放对某种模式的请求 |
rt_pm_request_all() | 请求所有模式（强制不休眠） |
rt_pm_release_all() | 释放所有请求 |
举个例子：你的传感器每10秒采集一次数据。采集期间不能休眠，采集完就可以睡了。
void sensor_task(void *parameter)
{
while (1) {
// 采集前：阻止系统进入深度睡眠
rt_pm_request(PM_SLEEP_MODE_DEEP);
sensor_read(); // 采集数据，耗时约50ms
// 采集完：允许系统进入深度睡眠
rt_pm_release(PM_SLEEP_MODE_DEEP);
rt_thread_mdelay(10000); // 等待10秒
}
}
你看，代码很简单。但要注意：rt_pm_request 和 rt_pm_release 必须成对出现。我见过有人只请求不释放，结果系统永远睡不了——电池半天就耗光了。
2.2.2 模式切换与通知
| 函数 | 作用 |
|---|---|
rt_pm_mode_change(rt_uint8_t mode) | 主动切换电源模式 |
rt_pm_notify(rt_uint8_t event, void *args) | 通知驱动层模式变化 |
rt_pm_notify 这个函数很关键。当PM组件决定切换模式时，它会调用所有注册设备的通知回调。比如从轻度睡眠切到深度睡眠，WiFi模块得先断开连接，再关电源。
核心逻辑：PM组件不会直接操作硬件。它通过通知机制，让每个设备自己决定“我该怎么睡”。这叫“职责分离”。
2.2.3 定时器与唤醒源
| 函数 | 作用 |
|---|---|
rt_pm_timer_start(rt_tick_t ticks) | 启动一个定时器，到期后唤醒系统 |
rt_pm_timer_stop(void) | 停止定时器 |
rt_pm_wakeup_set(rt_uint32_t pin) | 设置某个GPIO为唤醒源 |
rt_pm_wakeup_clear(rt_uint32_t pin) | 清除唤醒源设置 |
这里有个设计思路：尽量用定时器唤醒，而不是外部中断。为什么？因为外部中断需要保持GPIO模块供电，功耗高。定时器通常由RTC或低功耗定时器实现，功耗极低。
我的经验：在低功耗产品中，90%的唤醒应该由定时器触发。外部中断只用于“紧急事件”，比如按键、报警。我曾经优化过一个产品，把外部中断唤醒改成定时器轮询，续航从3天提升到了7天。
2.3 工作流程：从请求到休眠
咱们走一遍完整流程。假设系统当前在运行模式，突然所有任务都空闲了：
- 空闲线程检查：发现没有任务需要运行，调用
rt_pm_request(PM_SLEEP_MODE_LIGHT)。 - PM组件计算：检查所有请求，发现没有高优先级任务阻止休眠，决定进入轻度睡眠。
- 通知驱动：调用
rt_pm_notify(PM_EVENT_SLEEP, PM_SLEEP_MODE_LIGHT)，所有设备收到通知。 - 设备响应：比如UART关闭接收中断，定时器切换到低功耗模式。
- 进入休眠：CPU执行WFI指令，停止时钟。
- 唤醒：定时器到期或外部中断触发，CPU恢复运行。
- 恢复驱动：调用
rt_pm_notify(PM_EVENT_WAKEUP, PM_SLEEP_MODE_LIGHT)，设备恢复工作。
你可能会问：如果多个设备同时请求不同模式怎么办？PM组件会取“最严格”的那个。比如一个设备请求轻度睡眠，另一个请求深度睡眠——那就进轻度睡眠。因为轻度睡眠功耗更高，但唤醒更快，能保证所有设备的需求。
避坑指南：我曾经在一个项目里，两个驱动都调用了 rt_pm_request，但一个请求的是轻度睡眠，另一个请求的是深度睡眠。结果系统一直进轻度睡眠，功耗降不下来。排查了半天才发现，是某个驱动忘记释放请求了。所以，一定要在驱动初始化时明确请求模式，并在卸载时释放。
2.4 小结
PM组件的核心就三件事：请求管理、模式切换、设备通知。数据结构是骨架，API是血肉，工作流程是灵魂。你只要理解了这三个层次，就能驾驭RT-Thread的电源管理。
下一章，咱们会深入具体的低功耗模式配置，比如如何让STM32进入STOP模式，以及如何用RTC定时唤醒。到时候我会分享一些实际项目中的“骚操作”——嗯，保证让你眼前一亮。