低功耗设计概览¶

本指南的内容与适用对象¶

本指南介绍 SF32 器件的低功耗设计实践，包括功耗模式、真正消耗电池电量的因素，以及如何组织固件，使系统尽可能长时间停留在低功耗状态。功耗取决于系统整体：蓝牙（Bluetooth）、图形、音频和 AI 的设计选择都会影响续航，本指南将这些因素放在一起分析。

思澈科技（SiFli）的 SDK 文档针对包括 SF32LB52x 在内的特定目标，介绍了基于 RT-Thread 的 **PM（Power Management，电源管理）**中间件。不同器件的可用模式和唤醒行为可能不同，请查阅目标器件对应的 SDK 文档和配置。在 SDK 将蓝牙控制器工作分配给独立处理器的型号上，射频事件可能由该处理器处理，使主应用 CPU 无需为每个事件唤醒。主应用 CPU 能否保持睡眠，取决于目标型号的任务分配、唤醒源和核间通信；请在目标器件上验证，详见蓝牙处理器架构。

当续航目标需要转化为有实测依据的固件和硬件决策时，请使用本文。本文面向需要统筹已连接待机、显示、音频、传感器、AI 和响应速度的工程师。低功耗设计不能只靠调用一次睡眠 API。

首先定义产品功耗预算¶

编写电源管理代码之前，先明确产品需要达到的功耗目标：

• 目标续航时间（小时、天或周）和电池容量。
• 预期占空比——设备每天有多少时间处于活动、已连接但空闲，以及完全睡眠状态？
• 哪些事件必须唤醒系统，响应速度要求如何？
• 哪些子系统必须持续运行，例如已连接的蓝牙链路、常亮显示或语音触发；哪些可以完全由事件驱动？
• 如果与产品功耗策略相关，还应明确充电行为和预期充电循环次数。

这些目标应尽早驱动系统架构决策，包括芯片和显示类型选择，以及持续监听语音或常亮显示等功能是否能纳入功耗预算。

功耗模式与 PM 框架¶

下表是系统状态的概念性归纳，并非 SF32 硬件模式或 SDK 枚举值的完整清单。具体支持哪些模式、唤醒源和数据保持行为，应查阅所选器件和 SDK 的文档：

实际工作负载会让系统在不同状态间切换。已配置的唤醒源会使 CPU 或子系统退出低功耗状态；具体的唤醒和时钟恢复流程因器件而异。工作完成后，负责的驱动或任务应释放所有仍在阻止睡眠的 PM 请求，让已配置的策略选择符合条件的低功耗状态。下图仅作示意：曲线展示状态间的相对转换，并非某一器件的实际电流值或时序。

图：短时工作负载中的功耗模式转换示意

低功耗模式的选择与阻止睡眠是两回事。思澈科技（SiFli）的 SF32LB52x PM 中间件参考文档和 SF32LB55x 低功耗开发指南均说明，调用 rt_pm_request(PM_SLEEP_MODE_IDLE) 会阻止系统进入 LIGHT、DEEP 和 STANDBY，直到调用匹配的 rt_pm_release(PM_SLEEP_MODE_IDLE)；该请求不会直接选择更深的模式。

实际开发时，应查阅目标系列对应的思澈科技（SiFli）官方低功耗开发指南：SF32LB52x、SF32LB55x、SF32LB56x或 SF32LB58x。可用模式、进入条件、唤醒源和状态保持行为取决于芯片系列、开发板和 SDK 配置。SF32LB52x 低功耗开发指南中的一个休眠（Hibernate）唤醒引脚示例明确标注适用于 58x/56x/52x/57x；SDK 通用 HAL PMU API 参考则列出 HAL_PMU_EnablePinWakeup() 在 SF32LB57x 上使用的索引范围为 0 至 13。这些资料仅能证明该唤醒引脚配置，不能据此认定 52x 的 RT-Thread 模式支持情况、PM 策略阈值或状态保持行为也适用于 57x。设计前应查阅目标 SDK 和器件文档，确认这些具体行为。一般而言，只有当空闲时长和其他进入条件均满足时，已配置策略才可能选择符合条件的更深状态。PM 请求若未及时释放，系统可能停留在比预期更浅的状态。

SF32 产品的主要耗电来源¶

不同子系统具有不同的功耗特征：

没有一种优化能够同时解决所有问题。实际产品需要分别降低各子系统的能耗，再验证组合效果，因为所有子系统都参与决定“系统究竟能睡眠多深”。

面向睡眠的固件设计¶

最大的功耗收益通常来自固件结构，而不是复杂的底层技巧：

• 优先使用中断和事件，而不是轮询。 即使无事可做，轮询循环仍会使 CPU 保持活动。
• 批量处理工作。 在延迟（latency）要求允许的情况下，累积传感器样本、蓝牙事件或音频块后再统一处理，避免每项数据都单独唤醒系统。
• 及时释放阻止睡眠的 PM 请求。 驱动或任务持有阻止系统进入更深低功耗状态的 PM 请求时，应在不再需要阻止睡眠后及时释放对应请求。请求未释放可能使系统停留在比预期更浅的状态。
• 在框架允许的情况下，采用事件驱动的 UI 和音频链路，而不是由定时器轮询。
• 审计定时器。 周期定时器会安排后续工作，可能唤醒系统，也可能缩短 PM 策略可用的空闲时长。多个看似无害的定时器叠加后，可能减少系统处于较深低功耗状态的时间。

从已验证的功耗示例开始¶

估算产品续航之前，应选择能够确定当前最不确定的功耗边界的 SDK 示例。低功耗 SDK 示例按场景梳理了官方的 PM、GPIO、处理器、蓝牙、显示、GUI、屏幕刷新和抬腕亮屏项目，并说明在将示例结果作为产品验证依据前，哪些供电连接、开发板、配置、唤醒源、外部电路和工作负载假设必须重新验证。

蓝牙功耗调优¶

连接和广播参数是调节蓝牙功耗的主要手段，完整说明参阅蓝牙概览：

• 对大部分时间空闲的链路，提高连接间隔和从机延迟。
• 将 TX 功率降低到仍能满足通信距离要求的最低水平。
• 产品从首次发现转入等待重连后，应降低广播频率。
• 在所选 SDK 将蓝牙控制器事件交由独立处理器处理的器件上，如果没有应用任务、唤醒源或核间消息需要主应用 CPU，它可能在连接事件之间睡眠。若每个蓝牙回调都会唤醒主应用 CPU，就会削弱这一收益；请确认目标器件的处理器和任务分配。

如需按场景分别测量仅运行经典蓝牙、仅运行 BLE，以及经典蓝牙与 BLE 双模并行运行时的实际功耗，请参阅蓝牙功耗测量与分析。

显示与背光功耗¶

显示屏和背光通常是可穿戴或手持产品中最大的单项耗电来源：

• 在面板和 UI 支持的情况下，使用局部刷新和脏区域更新，而不是全屏重绘，详见显示控制器：局部刷新。
• 设备无操作时，应降低显示亮度或在适用时关闭背光；屏幕变暗或被遮挡后停止动画。
• 常亮显示产品应结合实测常亮能耗和用户体验要求，比较 EPD、JDI/Memory-in-Pixel、AMOLED、TFT 等面板。应选择符合功耗预算的面板和工作策略，而不是简单地让普通活动显示模式持续运行。
• 将“常亮显示”作为独立的功耗预算项目，因为它会从根本上改变产品对“空闲状态”的定义。

AI 与传感器功耗调优¶

端侧推理和传感器采样必须有计划地调度，不能持续无条件运行：

• 只在获得新的有效数据时运行推理，不能无视输入活动而使用固定定时器。
• 如果器件和 SDK 支持，应将轻量级常开感知任务放到低功耗处理器上，避免每个样本都唤醒主应用 CPU。
• 测量每次推理或每个样本的能耗，而不只是延迟。只有当更快的操作能使系统更早返回睡眠时，才会真正省电。

精度、延迟与功耗之间的详细权衡请参阅 AI 概览。

内存与时钟注意事项¶

代码执行位置会同时影响性能和功耗。在实现并启用相应缓存特性的 SF32 器件上，指令与数据缓存可以减少系统等待 Flash 或 PSRAM 访问的时间；活动时间缩短后，通常可用于睡眠的时间也会增加。有关缓存与存储器系统注意事项，详见 STAR-MC1。

除 CPU 本身之外，还需注意：

• 外部 PSRAM 和 Flash 具有各自的活动与待机功耗特性。尤其当大型缓冲区必须在睡眠期间保持有效时，应查阅数据手册中的数据保持和访问功耗。
• 时钟源选择，包括晶振或内部振荡器，以及哪些 PLL 或时钟域保持活动，会同时影响唤醒延迟和睡眠功耗。
• 在低负载阶段降低 CPU 频率可能有帮助，但必须确认延长的活动时间不会抵消收益。应测量实际能耗，而不只是瞬时电流。

硬件与射频功耗注意事项¶

固件策略只能在硬件允许的范围内发挥作用：

• PMIC/LDO 在产品实际负载电流下的效率，比在无关负载点测得的最高效率更重要。
• 射频布局和天线调谐会决定达到可靠通信距离所需的 TX 功率。不良射频设计迫使固件提高 TX 功率，从而缩短续航。详见蓝牙处理器架构：射频与时钟注意事项。
• 晶振精度既影响射频时序裕量，也影响固件设置监督超时和唤醒裕量时所需的保守程度。
• 设计中应保留生产测试和校准接口；功耗和射频调优通常会延续到首版硬件之后。

案例：抬腕唤醒¶

抬腕亮屏是可穿戴产品的常见场景，但具体实现取决于传感器、开发板和 SDK。思澈科技（SiFli）的 SF32LB52x 抬腕亮屏示例面向 sf32lb52-lchspi-ulp 开发板，使用 LSM6DSL 加速度计/陀螺仪，每 200 ms 采集一次加速度数据以识别抬腕和放腕动作。设备在无操作 10 秒后进入睡眠，识别到抬腕动作后唤醒并点亮屏幕。这是针对特定开发板的实现，不能据此推断其他目标也使用传感器中断或具有相同的 PM 行为。如果目标传感器支持运动或阈值中断，固件可将其配置为唤醒源，以避免应用 CPU 持续轮询；否则，应将传感器采样和 CPU 唤醒纳入功耗预算。实际使用前，请确认目标器件的传感器、开发板、唤醒源和 PM 配置。

功耗预算工作表¶

调优固件之前，应先将产品目标转换为数字。一张简单的工作表通常已经足够：

对于互斥的运行状态，估算 average current = state current x duty cycle（平均电流 = 状态电流 × 该状态的时间占比），再将各状态的贡献相加。若多个负载同时运行，应计入对应场景的总功耗，避免把重叠状态重复计算。这有助于尽早发现设计问题：即使睡眠电流达到 20 μA，也无法弥补背光长时间保持高亮或推理循环持续按固定间隔运行造成的续航损失。

功耗分析：建模、测量、迭代¶

功耗分析将预算转化为可重复执行的工程闭环。先定义有代表性的产品场景，在相关供电边界记录电压和电流，并纳入各负载的持续时间与发生频率。按时间计算能耗，再将各电源轨的测量结果折算为电池侧能耗，同时计入电源转换损耗；不能直接相加不同电压电源轨上的电流。这样可以估算电池侧平均电流、每日耗电量和续航，并按功耗贡献排序，找出应优先测量和优化的场景。

flowchart LR
    A["定义有代表性的产品场景"] --> B["设定电流、电压、时长和发生频率假设"]
    B --> C["计算单次事件和每日能耗"]
    C --> D["与电池预算对照并按能耗大小排序"]
    D --> E["在目标硬件上测量优先场景"]
    E --> F["用实测电流和时长更新模型"]
    F --> B

功耗模型给出的是估算结果，而非实测数据。Nordic 的 Online Power Profiler for Bluetooth LE 也采用相同思路：它基于实测数据建立模型，但输出仍是预期值，并不是对某个具体产品的实际测量。实际电流会受到芯片个体差异、电路板设计、电池电压、温度、射频条件、固件时序和使用场景的影响。

对每个场景，都应记录会显著影响能耗的假设：

• 哪些子系统处于活动状态，MCU 实际进入了哪个功耗模式？
• 电池输入端或各稳压电源轨上的电流是多少？
• 该项工作持续多久，在典型的一天内会发生多少次？
• 哪些电流尖峰符合预期，哪些意味着存在非预期工作或未能进入睡眠？

先用模型找出占用预算最大的项目，再在硬件上验证这些场景，然后才能做出续航宣称。智能手表功耗建模与分析通过每日使用模型演示了这一方法；功耗测量与验证则给出了可重复执行的采集流程。

PM 管理责任与唤醒源审查¶

可靠的低功耗设计必须明确每个唤醒源和每个 PM 投票（vote）的责任方。设计评审应跟踪以下项目：

调试期间，应记录已配置的 PM 策略、所有阻止系统进入更深模式的有效请求，以及目标 SDK 或日志报告的最近一次低功耗模式。如果系统进入的状态比预期浅，这些信息通常比单独的电流读数更有诊断价值。

实际功耗测量¶

不要猜测，应直接测量。基本功耗验证环境包括：

• 在电池或电源与电路板之间接入电流探头或串联式功耗分析仪。
• 使用符合真实产品行为的测试场景，包括已连接空闲、UI 交互、音频播放、AI 推理突发任务和最坏组合负载。
• 在功耗轨迹旁记录或标记固件状态（活动/空闲/睡眠），从而将电流尖峰对应到具体代码路径。

思澈科技（SiFli）的 SDK 文档针对部分芯片和开发板提供功耗表征示例，涉及 AMOLED 和 JDI 显示、GPIO、BLE/经典蓝牙以及 CoreMark 类 CPU 负载等场景。请查阅目标芯片对应的 SDK 文档和开发板说明，确认示例是否适用及其配置方法；这些示例可用于参考测量流程和判断电流量级是否合理，但不能替代产品实测或作为功耗保证。

功耗验证矩阵¶

使用可重复的测试场景，才能跨固件版本比较优化效果。至少应测量：

应记录固件版本、电路板版本、电池或电源电压、温度、天线和外壳配置，以及测试脚本。缺少这些元数据时，功耗数值难以比较，也容易被误读。

高功耗问题排查¶

常见错误¶

• 将功耗优化视为最后的打磨工作，而不是从项目第一天开始的设计约束。
• 轮询传感器、蓝牙状态或定时器，而不使用中断和事件。
• 所需工作完成后仍保留 PM 投票。
• 对小范围 UI 变化进行全屏重绘。
• 忽略射频布局质量，再通过提高固件 TX 功率进行补偿。
• 只测量瞬时电流，而不分析真实使用场景下的总能耗。
• 只在台架上验证功耗，从不使用真实天线和电池在最终外壳中测量。

启动调试检查清单¶

• 定义目标续航、占空比和必要唤醒源。
• 确定哪些子系统必须持续活动，哪些可以完全由事件驱动。
• 确认每个驱动和任务在使用后及时释放其 PM 投票。
• 根据产品实际使用模式调节蓝牙广播和连接参数。
• 确认显示链路在支持时采用局部刷新，背光策略符合产品行为。
• 审计所有周期定时器，移除或合并不必要的定时器。
• 建立电流测量环境，分别验证活动、空闲和睡眠状态。
• 测试适用的最坏组合负载，包括蓝牙、显示、音频和 AI，并确认仍符合功耗预算。
• 每次重大固件变更后重新验证功耗，而不能只在项目结束时测量。

要点¶

• 功耗是系统属性：蓝牙、显示、音频、AI 和内存设计共同决定设备能够进入多深的睡眠，以及睡眠频率。
• 已配置的 PM 策略会从符合条件的低功耗状态中进行选择；未释放且阻止更深睡眠的请求会使系统停留在比预期更浅的状态。
• 在几乎所有功耗敏感场景中，事件和中断驱动设计都优于轮询。
• 对联网可穿戴产品而言，蓝牙连接参数和显示刷新策略通常是两个最大的调节手段。
• 应在最终外壳内的真实硬件上，以真实组合负载测量总能耗；台架测量和单独的子系统测量都可能低估实际产品功耗。

如需根据电压估算电池剩余电量百分比，请参阅电池电量估算。

最后更新: 2026-10-21