1. 课程导入

在嵌入式产品从“能用”走向“好用、耐用、可量产”的过程中，功耗往往是最容易被低估、却最难在后期补救的一项系统指标。无论是电池供电的传感器节点、可穿戴设备，还是需要长期待机的工业网关，用户对续航的期待都在持续提高。RT-Thread 作为一款成熟的国产实时操作系统，提供了线程、设备、组件与电源管理等多层能力，但“用了 RT-Thread 就自动省电”并不成立。低功耗是一项系统工程，需要从需求、硬件、驱动、内核调度、应用行为到测试验证形成闭环。

一、为什么低功耗是系统工程问题

很多初学者把低功耗理解为“让 MCU 进入睡眠模式”。实际项目中，功耗由多个层次共同决定：电源拓扑与器件静态电流、时钟树与分频、外设是否常开、GPIO 是否存在漏电流、RTOS 的 tick 与线程调度是否频繁唤醒 CPU、应用是否存在轮询与忙等、通信协议是否合理休眠。任何一层处理不当，都可能让整机功耗比预期高出一个数量级。

因此，低功耗工程的核心不是某个 API，而是“能量预算 + 状态迁移 + 唤醒源管理”的系统方法。我们需要先明确平均电流目标，再倒推各模块的占空比与工作电流，最后通过测量验证。RT-Thread 的电源管理框架（PM）正是把“何时可以睡、睡多深、谁来唤醒”这件事从应用逻辑中抽象出来，形成可配置、可裁剪、可验证的机制。

二、核心概念与整体知识框架

本课程围绕 RT-Thread 低功耗工程展开，涉及以下关键概念：

• 运行模式与睡眠模式：运行、空闲、浅睡、深睡、待机、关机等状态，对应不同的功耗与唤醒时间。
• 动态电压频率调节（DVFS）：根据负载调整主频与电压，降低动态功耗。
• Tickless 机制：取消周期性 tick，让系统在无任务时长时间睡眠，减少无谓唤醒。
• 电源管理框架（PM）：RT-Thread 提供的 PM 组件，管理设备与系统的低功耗状态迁移。
• 唤醒源：中断、RTC、GPIO、通信接口等能够把系统从低功耗状态唤醒的事件。
• 能量预算：以平均电流和占空比为核心，评估整机续航。

下图给出本课程的整体知识框架：从需求与能量预算出发，经过硬件与驱动、内核与 PM、应用与通信，最终落到测量与验证，形成闭环。

三、方法流程：从目标到验证

低功耗工程推荐按以下流程推进，避免“先写功能、再补省电”的被动局面：

1. 定义能量预算：根据电池容量与目标续航，计算允许的平均电流。例如 2000mAh 电池、目标 1 年续航，平均电流需低于约 0.23mA。
2. 拆分工作场景：列出采集、计算、通信、待机等状态，估算各状态电流与持续时间。
3. 选择低功耗模式：确定使用浅睡、深睡还是待机，并明确唤醒时间约束。
4. 配置 RT-Thread PM 与 Tickless：使能相关宏，注册设备，设置空闲阈值。
5. 优化应用行为：用事件驱动替代轮询，合并通信，减少唤醒次数。
6. 测量与迭代：用功耗仪抓取电流波形，定位异常唤醒与漏电。

下面是一段 RT-Thread 中使能 PM 与 Tickless 的典型配置片段，实际工程中需结合 BSP 与芯片手册调整：

/* rtconfig.h 关键配置 */
#define RT_USING_PM
#define RT_USING_PM_DEEP
#define RT_USING_PM_STANDBY
#define RT_USING_PM_IDLE
#define RT_USING_PM_TIMER
#define RT_USING_PM_DEVICE

/* 空闲线程中触发低功耗判断 */
rt_pm_request(PM_SLEEP_MODE_DEEP);
rt_pm_release(PM_SLEEP_MODE_DEEP);

四、典型场景与误区复盘

以一个 LoRa 温湿度节点为例：每 5 分钟采集一次并上报，其余时间应处于深睡。若未启用 Tickless，系统每秒被 tick 唤醒，平均电流可能从几十微安升到几百微安；若 GPIO 未配置为模拟输入或上拉，传感器与上拉电阻会持续耗电；若通信模块未进入休眠，整机功耗可能直接翻倍。这些都不是 RT-Thread 本身的问题，而是系统配置与使用方式的问题。

五、学习目标