📚 课程目录第1章低功耗设计总览

1. 低功耗设计总览：STM32低功耗模式概述

做嵌入式开发这么多年，我见过太多产品因为功耗问题翻车。有的设备电池撑不过一周，有的发热严重到外壳变形。说白了，低功耗设计不是锦上添花，而是产品能不能活下去的关键。

这一章，我们先搭个框架。把STM32的几种低功耗模式搞清楚，再聊聊怎么测功耗，最后结合项目需求做个分析。嗯，这些都是后面实战的基础。

STM32的低功耗模式，说白了就是「用性能换功耗」。你让CPU睡得多深，省电就越多。但代价是唤醒时间变长，能用的外设变少。

我个人习惯把三种模式记成三个档位：

你想想看，从 mA 到 nA，差了整整一百万倍。选对模式，比你在代码里抠那几条指令省电多了。

这是最浅的睡眠。CPU 内核停了，但所有外设照常跑。我在项目中经常用它做「等待中断」的场景——比如等待串口数据到来，或者等待定时器溢出。唤醒几乎零延迟，适合频繁进出低功耗的场合。

我的习惯： 如果系统大部分时间在轮询等待，别硬等，进 Sleep。功耗能降 30%-50%，而且代码改动极小。

Stop 模式就狠一些了。CPU 停，系统时钟也停。但你可以选择保留 SRAM 和部分外设的时钟。唤醒需要外部中断或 RTC 闹钟。

我曾经在一个电池供电的传感器节点上用过 Stop 模式。设备每 10 秒醒来一次，采集数据，发完继续睡。平均电流从 5mA 降到了 8μA。嗯，电池寿命从 3 天变成了 6 个月。

注意： Stop 模式下，如果没保留必要的 GPIO 状态，唤醒后可能出现引脚电平跳变。我踩过这个坑——驱动了一个 MOSFET，结果设备在唤醒瞬间误动作。解决方案是在进 Stop 前锁住 GPIO 输出状态。

这是最深度的睡眠。除了 RTC 和备份域，几乎全部断电。SRAM 内容丢失，所有寄存器复位。唤醒就像一次复位，程序从头跑。

Standby 的功耗可以低到几十 nA。适合那种「一年唤醒几次」的设备，比如水表、烟感。但代价是唤醒后需要重新初始化所有外设，代码要处理「冷启动」和「热启动」的区别。

  选型口诀：

  Sleep —— 频繁进出，延迟敏感

  Stop —— 中等休眠，保留状态

  Standby —— 深度休眠，极致省电

做低功耗设计，没有测量数据就是瞎猜。我见过太多人「感觉功耗很低」，结果一上示波器傻眼了。

测量功耗，我建议分三步走：

避坑指南： 我曾经用普通万用表测 Stop 模式的 μA 级电流，结果读数跳来跳去。后来才发现，万用表的采样率太低，捕捉不到瞬态。换成带「低电流模式」的万用表或者用示波器看，才拿到准确数据。

另外，别忘了测量路径上的压降。如果电源线太细，或者用了长跳线，IR drop 会让你的测量结果偏小。嗯，这个坑我也踩过。

低功耗设计不是越省电越好。你得先搞清楚：

举个例子。假设我们要做一个无线温度传感器：

算一下平均电流：

平均电流 = (20mA × 0.2s + 0.005mA × 59.8s) / 60s
         ≈ 0.0717 mA

电池寿命 ≈ 2000 mAh / 0.0717 mA ≈ 27890 小时 ≈ 3.18 年

这个结果够不够？如果客户要求 5 年，那你就得想办法把休眠电流降到 1 μA 以下，或者拉长工作间隔。这就是需求倒推设计的过程。

  核心思路： 先算账，再选模式。不要一上来就怼 Standby，如果设备每 10 秒醒一次，Sleep 模式可能更合适。

下面这张图，把本章的核心逻辑串起来了。你可以把它当成后续章节的导航图。

这张图你看懂了吗？从上到下，先明确目标，再选模式，最后用测量和需求分析来闭环。后面的章节，我们会沿着这个框架一步步深入。

  本章要点回顾：
  三种低功耗模式：Sleep（μs 唤醒）、Stop（μA 级）、Standby（nA 级）
功耗测量要分静态、动态、积分三步走
需求分析先算平均电流，再倒推方案
没有测量数据，不要谈低功耗优化