3、待机模式选择策略
好，咱们接着聊。前面我们把制氧机的功耗模块拆了个七七八八，现在该动真格的了——到底选哪种待机模式？
说实话，这个问题我当年也纠结过。记得第一次做低功耗产品，我天真地以为「能睡多深就睡多深」，结果客户投诉说Wi-Fi连不上，紧急停机按钮按了没反应。嗯，从那以后我学乖了：待机模式的选择，本质上是个「取舍」问题。
3.1 制氧机的三大待机需求
咱们先捋一捋，制氧机在待机时到底要干哪些活：
- 保持Wi-Fi连接：用户可能通过手机App查看设备状态，或者接收远程指令。Wi-Fi模块不能完全断电，得维持心跳包。
- 定时唤醒：比如用户设定了「每天早上8点自动开机」，MCU得在指定时间醒来干活。
- 紧急停机检测：这是安全红线。待机时如果检测到异常（比如压力过高、温度超标），必须立刻响应。
你想想看，这三个需求对功耗和响应速度的要求完全不一样。Wi-Fi连接需要持续供电，定时唤醒可以靠RTC，紧急停机则要求极低延迟。
3.2 Cortex-M的四种待机模式
以STM32L4系列为例，Cortex-M4内核提供了四种主要的电源模式。我习惯把它们比作「睡觉的四个层次」：
| 模式 | 功耗（典型值） | 唤醒延迟 | 保留内容 |
|---|---|---|---|
| Run | ~100 μA/MHz | 0（立即） | 全部 |
| Sleep | ~50 μA/MHz | 几个时钟周期 | CPU暂停，外设继续 |
| Deep Sleep (Stop) | ~1.5 μA | ~5 μs | SRAM、寄存器保留 |
| Standby | ~0.3 μA | ~50 μs | 仅备份寄存器 |
看到这个表，你可能会想：「Standby功耗最低，直接选它不就行了？」别急，我踩过这个坑。
3.3 我的选择策略
我个人习惯把制氧机的待机状态分成两个阶段：
第一阶段：短时待机（比如用户离开5分钟）
这时候用Sleep模式就够了。CPU暂停，但Wi-Fi模块和传感器继续工作。唤醒延迟几乎为零，紧急停机检测也能实时响应。功耗嘛，大概几十微安，对于电池供电的设备来说可以接受。
第二阶段：长时待机（比如夜间）
这时候我会切换到Deep Sleep模式。Wi-Fi模块进入低功耗模式（比如DTIM睡眠），RTC定时唤醒。紧急停机检测怎么办？我一般用外部中断引脚，比如接一个加速度传感器或压力开关，一旦触发就能把MCU从Deep Sleep中唤醒。
至于Standby模式，我只有在极端情况下才用——比如电池电量极低，需要保命。因为唤醒后要重新初始化外设，那几十微秒的延迟在紧急停机场景下是致命的。
3.4 各模式唤醒延迟对比
咱们再深入一点，看看唤醒延迟到底差多少。我拿示波器实测过：
- Sleep → Run：不到1微秒。基本感觉不到，适合频繁唤醒的场景。
- Deep Sleep → Run：大约5微秒。主要花在恢复时钟和锁相环上。如果你用内部HSI振荡器，还能再快一点。
- Standby → Run：50微秒起步。因为要重新加载启动代码、初始化堆栈、恢复外设寄存器。我测过最慢的一次到了80微秒，差点没把甲方急死。
你想想看，如果紧急停机检测要求10微秒内响应，那Standby模式就直接出局了。所以，安全相关的功能一定要用低延迟的唤醒源。
3.5 避坑指南
最后分享几个我踩过的坑：
- Wi-Fi模块的功耗陷阱：有些Wi-Fi模块在低功耗模式下仍然会周期性发射信标，功耗可能高达几毫安。我建议在待机时关闭Wi-Fi的TCP连接，只保留UDP心跳，能省不少电。
- RTC校准：Deep Sleep模式下RTC还在跑，但晶振的温漂会导致时间不准。我习惯在每次唤醒后同步一次NTP时间，或者用外部高精度RTC芯片。
- GPIO状态：进入Deep Sleep前，记得把未使用的GPIO设为模拟输入或下拉，否则悬空引脚会漏电。我曾经因为这个多耗了0.5微安，排查了两天才发现。
总结一下：
- 短时待机 → Sleep模式（低延迟，Wi-Fi保持）
- 长时待机 → Deep Sleep模式（低功耗，RTC唤醒）
- 紧急场景 → 外部中断唤醒（必须用低延迟模式）
- Standby模式 → 仅用于电池极低时的保命策略
好了，待机模式的选择策略就聊到这儿。下一节咱们讲讲具体的代码实现，包括怎么配置RTC唤醒、怎么处理Wi-Fi的低功耗模式。到时候我会贴出完整的示例代码，保证你能直接抄作业。