一、唤醒方案概述：为什么需要快速唤醒？
各位同学好，我是老张。做嵌入式低功耗设计这么多年，我越来越觉得「唤醒」这件事，比「休眠」更考验功力。
你想想看，一个设备休眠做得再好，如果唤醒慢半拍，用户可能就直接把产品摔了。我当年做一款智能门锁，待机电流做到 5μA，老板拍手叫好。结果呢？用户按指纹后要等 2 秒才能开门——投诉电话被打爆了。从那以后我明白一个道理：低功耗是基础，快速唤醒才是用户体验的命门。
1.1 为什么需要快速唤醒？
说白了，就是用户等不起。我们来看几个典型场景：
- 智能门锁/门禁：用户站在门口，按指纹或刷卡，期望 200ms 内开门。超过 500ms，用户就会觉得「卡」。
- 可穿戴设备：抬手亮屏，从手腕抬起动作到屏幕点亮，延迟超过 300ms 就会感觉「迟钝」。
- 工业传感器：事件触发上报，比如振动传感器检测到异常，需要在 10ms 内唤醒 MCU 并发送报警。
- 汽车电子：CAN 总线唤醒，要求从休眠到报文收发延迟小于 100μs，否则会丢帧。
我做过一个蓝牙温湿度标签，客户要求电池用两年，同时按键后 50ms 内蓝牙广播必须发出。嗯，这个指标当时折腾了我整整两周。
核心矛盾：休眠越深，功耗越低，但唤醒时间越长。我们需要在「省电」和「响应快」之间找到那个甜蜜点。
1.2 低功耗与唤醒延迟的权衡
这里我画了一张表，大家一看就明白：
| 休眠模式 | 典型功耗 | 唤醒时间 | 适用场景 |
|---|---|---|---|
| Run（运行） | mA 级 | 0 | 持续工作 |
| Sleep（睡眠） | 几百 μA | 几 μs | 短时待机，如按键扫描 |
| Deep Sleep（深度睡眠） | 几 μA ~ 几十 μA | 几十 μs ~ 几 ms | 周期性唤醒，如传感器采集 |
| Standby（待机） | 几百 nA ~ 几 μA | 几 ms ~ 几十 ms | 长时间待机，如门锁 |
| Shutdown（关断） | nA 级 | 几十 ms ~ 几百 ms | 极低功耗，如电池仓储模式 |
注意看，从 Deep Sleep 到 Standby，功耗降了一个数量级，但唤醒时间却涨了 10 倍以上。为什么会这样？因为 Standby 模式下，很多内部稳压器和时钟都关了，重新启动需要时间。
我个人习惯是：先定唤醒时间指标，再反推休眠模式。比如门锁要求 200ms 唤醒，那 Standby 模式就够用；但如果要求 10ms 内响应，就必须用 Deep Sleep 甚至 Sleep 模式。
避坑指南：我曾经在一个项目中，为了省电把 MCU 切到了 Shutdown 模式，结果外部中断唤醒后，MCU 花了 80ms 才把 HSE 晶振稳定下来。后来我改用 LSI 做低速时钟，配合 Deep Sleep 模式，唤醒时间降到了 2ms，功耗只多了 1μA。这个教训告诉我：别为了省那 1μA 而牺牲 10 倍的唤醒速度。
1.3 常见唤醒源介绍
唤醒源，说白了就是「谁把芯片叫醒」。不同的唤醒源，延迟和功耗特性完全不同。我按使用频率给大家排个序：
1. GPIO 外部中断
最常用，也最直接。按键、传感器输出、通信模块的唤醒信号，都可以接 GPIO 中断。
- 优点：响应快，通常几 μs 就能唤醒
- 缺点：需要外部信号触发，不能定时
- 注意：GPIO 的上下拉电阻在休眠时可能漏电，我建议用外部上拉/下拉，或者用 MCU 内部弱上拉（通常 40kΩ 以上）
2. RTC 闹钟
定时唤醒的标配。比如传感器每 10 秒采集一次数据，就用 RTC 闹钟。
- 优点：精度高，功耗极低（RTC 模块通常只耗几百 nA）
- 缺点：只能定时，不能响应外部事件
- 经验：我习惯用 RTC 的「自动唤醒」功能，而不是闹钟中断。前者硬件自动触发，不需要软件干预，更省电
3. 通信模块唤醒
蓝牙、Wi-Fi、LoRa 等无线模块，通常有专门的唤醒引脚。
- 蓝牙：主机通过广播包唤醒从机，延迟一般在 10ms ~ 100ms
- Wi-Fi：支持 DTIM 休眠，AP 会缓存数据，STA 定时醒来接收
- LoRa：CAD（信道活动检测）模式，可以在极低功耗下检测前导码
我记得做一款蓝牙门锁时，手机 APP 开锁经常要等 3 秒。后来发现是蓝牙模块的唤醒轮询间隔设成了 1 秒。改成 100ms 后，功耗只多了 20%，但用户体验好了不止一个档次。
4. 比较器/模拟唤醒
适合模拟信号触发的场景，比如电池电压低于阈值时唤醒 MCU 做保护。
- 优点：不需要 ADC 连续采样，省电
- 缺点：精度一般，容易误触发
- 建议：加一点硬件滤波，比如 RC 低通，或者用迟滞比较器
5. 专用唤醒控制器
一些高端 MCU 内置了「唤醒控制器」，可以组合多个唤醒源。比如 STM32 的 WKUP 引脚，或者 NXP 的 LLWU 模块。
- 优点：支持多种唤醒条件，比如「任意按键唤醒」或「指定按键组合唤醒」
- 缺点：配置复杂，需要仔细看参考手册
重要提醒：唤醒源不是越多越好。每个唤醒源在休眠时都需要保持供电，会额外消耗电流。我见过一个产品，用了 5 个 GPIO 中断唤醒，结果每个 GPIO 的上拉电阻在休眠时漏了 2μA，加起来 10μA，比 MCU 本身的休眠电流还大。所以，唤醒源够用就行，别贪多。
1.4 快速唤醒的底层逻辑
讲到这里，大家应该明白了：快速唤醒的本质，是在休眠状态下保留关键外设的供电和时钟。
比如你要用 GPIO 中断唤醒，那 GPIO 模块的供电就不能断，中断检测电路必须保持工作。你要用 RTC 唤醒，那 RTC 的 32.768kHz 晶振就不能停。
我个人的设计原则是：
- 先定唤醒延迟：根据产品需求，确定最大允许的唤醒时间
- 再选休眠模式：根据唤醒延迟，选择最省电的休眠模式
- 最后配唤醒源：在选定的休眠模式下，配置可用的唤醒源
举个例子，一个智能门锁：
- 唤醒延迟要求：200ms（用户按指纹到开锁）
- 休眠模式选择：Standby（唤醒时间约 50ms，留有余量）
- 唤醒源配置：指纹模块的 GPIO 中断 + RTC 定时心跳（每 30 秒醒来检查网络）
这样设计，待机电流能做到 3μA 左右，唤醒时间 50ms，完全满足需求。
一句话总结：快速唤醒不是技术难题，而是设计取舍。你愿意为「快」付出多少功耗，决定了你选择哪种方案。后面的章节，我会带大家一步步实现这些方案，从硬件电路到软件代码，咱们一个一个来啃。
好，这一章就到这里。下一章我们讲「硬件层面的快速唤醒设计」，包括外部中断电路、RTC 电路、以及如何避免唤醒时的毛刺问题。到时候我会分享一个我踩过的坑——因为一个电容没加，导致门锁半夜自己开了...嗯，你们猜猜是怎么回事？