2. 硬件基础：MCU低功耗模式详解（Sleep、Stop、Standby），唤醒源与唤醒延迟

各位同学，咱们今天聊点硬核的。做低功耗嵌入式系统，说白了就是跟MCU的“睡眠”打交道。你想想看，一个设备大部分时间都在待机，怎么让它睡得更沉、醒得更快，这就是核心问题。

我个人习惯，拿到一款新MCU，第一件事就是翻它的电源管理章节。别急着写代码，先把芯片能睡多深搞清楚。今天我就带大家把STM32（以F4/L4系列为例）的三种典型低功耗模式扒个底朝天。

2.1 三种低功耗模式：从“打盹”到“冬眠”

MCU的低功耗模式，其实就像人的睡眠。有浅睡、深睡，还有冬眠。咱们一个一个看。

2.1.1 Sleep模式（浅睡）

这是最轻量级的省电模式。说白了，就是CPU内核停了，但外设还在跑。比如你的定时器、串口、ADC，都还在正常工作。

• 电流消耗：通常在几mA到几十mA（取决于外设开启数量）
• 唤醒延迟：极短，几乎可以忽略（几个CPU时钟周期）
• 典型场景：等待某个外设事件，比如串口收到一帧数据

2.1.2 Stop模式（深睡）

这个模式就厉害了。它把CPU内核、大部分外设的时钟都关了。只保留一小部分“守夜人”电路，比如RTC、外部中断、一些特定的唤醒引脚。

• 电流消耗：典型值在几十μA（微安）级别
• 唤醒延迟：几十到几百微秒（需要重新锁相环、恢复寄存器）
• 典型场景：电池供电的传感器节点，需要定期上报数据

2.1.3 Standby模式（冬眠）

这是最极致的省电模式。它几乎把整个芯片都断电了，只留下一个最小的唤醒逻辑电路。RAM里的数据？对不起，全丢了。寄存器配置？也丢了。醒来后，芯片就像重新上电一样，从复位向量开始执行。

• 电流消耗：极低，通常只有几百nA（纳安）到几μA
• 唤醒延迟：最长，通常需要几毫秒（相当于一次复位启动）
• 典型场景：电池寿命要求极高的设备，比如智能手表（大部分时间在冬眠，偶尔亮屏）

2.2 唤醒源：谁叫得醒你？

不同的睡眠模式，能叫醒它的“闹钟”也不一样。你想想看，睡得太沉了，一般的声音是叫不醒的。

为什么会这样？因为Standby模式下，大部分中断控制器都断电了，只有RTC和那几个专用的唤醒引脚还连着电。所以，你想用串口唤醒Standby？没门儿。

2.3 唤醒延迟：从“叫醒”到“干活”要多久？

这个指标太关键了。你想想，一个传感器节点，如果唤醒延迟占了整个工作周期的10%，那功耗就白白浪费了10%。

唤醒延迟主要由两部分组成：

1. 硬件恢复时间：电源域重新上电、时钟稳定、锁相环锁定。这部分是硬性的，由芯片设计决定。
2. 软件恢复时间：重新初始化外设、恢复上下文、检查唤醒原因。这部分我们可以优化。

我给大家一个典型数据（以STM32L4系列为例）：

2.4 实战要点：如何选择？

好了，理论讲完了。咱们来点实际的。怎么选？我一般按这个思路来：

1. 先看唤醒频率：如果每秒要醒100次，用Standby就是找死（唤醒延迟3ms，占了30%的时间）。用Sleep或Stop更合适。
2. 再看数据保持需求：如果醒来后需要保留上次的计算结果，那就不能用Standby（RAM会丢）。要么用Stop，要么在Standby前把关键数据存到备份寄存器或Flash里。
3. 最后看唤醒源：如果只能用串口唤醒，那对不起，你只能用Sleep模式。Stop和Standby都不支持串口唤醒。

嗯，今天就先聊到这儿。下一节，我会带大家实际动手，在FreeRTOS里把Sleep模式跑起来。到时候咱们再细聊怎么在RTOS调度和低功耗之间找到平衡点。