4. 休眠与唤醒策略：周期性唤醒、事件驱动唤醒、异步唤醒的权衡
各位做低功耗的朋友，咱们今天聊一个绕不开的话题——休眠与唤醒。
说实话，我见过太多项目，电池选得挺大，结果没跑几个月就趴窝了。问题出在哪？多半是休眠策略没选对。你想想看，一个传感器节点，99%的时间都在等数据，如果这99%的时间还在全速跑，那功耗能低才怪。
所以，怎么睡、怎么醒，这里面门道很深。我个人习惯把唤醒策略分成三类：周期性唤醒、事件驱动唤醒、异步唤醒。今天咱们就掰开揉碎，看看它们各自适合什么场景，又该怎么权衡。
4.1 周期性唤醒：最经典，也最容易被滥用
周期性唤醒，说白了就是让设备定时起床干活。比如每10秒醒来一次，采集数据、发送报文，然后继续睡。这种模式在物联网里太常见了，几乎每个低功耗设备都会用到。
优点很明显：
- 实现简单，一个定时器就能搞定
- 时序可预测，便于系统设计
- 功耗可控，占空比一算就出来
但坑也不少：
- 如果事件发生在休眠期间，你就错过了
- 为了不错过重要事件，你可能得把周期设得很短，结果功耗反而上去了
- 多个设备同时唤醒，容易造成信道冲突
所以，周期性唤醒的关键在于——周期到底设多少？ 我的建议是：先算清楚应用能容忍的最大延迟，然后在这个基础上尽量拉长周期。比如温度监测，变化很慢，30秒甚至1分钟一次都行；但如果是门磁报警，延迟超过1秒可能就 unacceptable 了。
4.2 事件驱动唤醒：省电，但得有触发源
事件驱动唤醒，就是设备平时深度休眠，直到某个外部事件发生才醒来。这个事件可以是GPIO中断、传感器阈值触发、或者RTC闹钟。
这种模式的好处是——真正的按需工作。没有事件发生，设备就一直睡，功耗可以做到极低。我见过一些用纽扣电池跑3年的传感器节点，用的就是纯事件驱动模式。
但问题也很现实：
- 你得有一个能产生中断的硬件源
- 如果事件太频繁，设备频繁唤醒，功耗反而比周期性唤醒还高
- 有些MCU在深度休眠模式下，只有少数几个GPIO能唤醒，设计时得仔细看手册
举个例子，一个智能门锁。平时深度休眠，只有按下指纹或触碰门把手时才唤醒。这种场景下，事件驱动就是最优解。但如果是一个温度传感器，你总不能等温度变化了才去采集吧？那得等到猴年马月。
4.3 异步唤醒：最灵活，但代价也最大
异步唤醒，指的是设备之间可以互相唤醒。比如A节点发一个唤醒信号，B节点收到后从休眠中醒来。这在多跳网络、Mesh网络中特别有用。
常见的实现方式有两种：
- 带内唤醒： 用数据包本身作为唤醒信号。设备会周期性地打开接收窗口，检测是否有前导码或特定序列。
- 带外唤醒： 用独立的唤醒信道或引脚。比如一个低功耗的唤醒接收器，专门监听唤醒信号。
异步唤醒的优势：
- 网络拓扑灵活，节点可以随时加入或离开
- 延迟可控，适合对实时性有要求的场景
- 支持多跳通信，扩展性好
但代价也不小：
- 需要额外的硬件支持（比如双信道接收器）
- 协议栈复杂度大幅增加
- 如果唤醒信号处理不当，容易造成误唤醒，白白耗电
4.4 三种策略的对比与选择
说了这么多，到底该怎么选？我整理了一个表格，方便大家对照：
| 特性 | 周期性唤醒 | 事件驱动唤醒 | 异步唤醒 |
|---|---|---|---|
| 实现复杂度 | 低 | 中 | 高 |
| 功耗水平 | 中（取决于占空比） | 低（无事件时极低） | 中低（取决于监听窗口） |
| 实时性 | 差（受周期限制） | 好（事件即响应） | 好（可快速唤醒） |
| 适用场景 | 周期性数据采集 | 触发式报警、交互设备 | 多跳网络、Mesh网络 |
| 硬件要求 | 定时器即可 | 需要中断源 | 需要双信道或唤醒接收器 |
嗯，这里要注意：实际项目中，很少只用一种策略。我做过的大多数产品，都是混合使用。比如一个环境监测节点，平时用周期性唤醒采集温湿度，但遇到报警事件（比如烟雾浓度超标）时，立即切换到事件驱动模式，提高响应速度。
4.5 实战中的避坑指南
最后，分享几个我这些年总结出来的经验：
- 别忽略唤醒时间本身。 有些MCU从深度休眠唤醒需要几毫秒，如果唤醒太频繁，这部分时间占比会很大，反而更耗电。
- 注意外设的休眠状态。 我遇到过传感器在休眠时还在偷偷耗电的情况。一定要确认每个外设都进入了对应的低功耗模式。
- 异步唤醒要防误触发。 我曾经在一个项目中，因为环境噪声导致唤醒接收器频繁误触发，电池一周就耗光了。后来加了信号强度检测和多次确认机制才解决。
- 测试要覆盖边界条件。 比如电池电压低的时候，MCU的唤醒时间可能会变长，这个在常温下测不出来，但低温低压下就会暴露。
好了，关于休眠与唤醒策略，今天就聊到这里。下一章咱们会深入讲讲动态电压频率调整（DVFS），这也是低功耗设计里的一把利器。到时候见！