扫码关注
做电池供电的产品，低功耗是绕不开的话题。STM32这类单片机提供了好几种低功耗模式，其中最容易搞混的就是Stop和Standby。
很多人知道Standby功耗更低，但低多少、牺牲了什么、什么时候该用哪个，并不一定说得清楚。今天就掰开揉碎了聊聊这两种模式。
先搞清楚两种模式到底是什么Stop模式，顾名思义就是"停"——把时钟停掉。在Stop模式下，所有的时钟源都被关闭，CPU和外设都停止运行。但SRAM和寄存器的内容是保持的，唤醒后可以接着之前的状态继续跑。
打个比方，Stop就像电脑的睡眠模式——内存还带电，唤醒后很快就能回到工作状态。
Standby模式，则是"待机"——这是STM32里功耗最低的模式之一。在Standby下，不仅时钟停了，连大部分电源域都关掉了。SRAM和寄存器的内容会丢失，唤醒后相当于一次重新复位，程序从头开始跑。
Standby更像是电脑的关机状态——几乎不耗电，但开机需要完整的启动流程。
核心区别到底在哪我整理了几个关键维度的对比，一看就明白：
| 典型功耗 | ~10μA级别 | ~1μA级别 |
| 唤醒时间 | 快，几微秒到几十微秒 | 慢，和复位差不多 |
| SRAM保持 | 保持 | 不保持（可选择部分保持） |
| 寄存器保持 | 保持 | 丢失 |
| 唤醒源 | 外部中断、串口、定时器等 | WKUP引脚、RTC、IWDG |
| 唤醒后行为 | 继续执行 | 程序复位重启 |
功耗差一个数量级，代价就是唤醒的便利性和状态保持。
实际项目中怎么选说几个常见的场景，你大概就有谱了。
需要快速响应的场景，用Stop。比如便携式测量仪表，用户按一下按键就要立刻显示读数。如果用Standby，唤醒还要等初始化、屏幕点亮，用户体验会很差。几微秒的唤醒时间，用户根本感觉不到延迟。
对功耗极度敏感、唤醒不频繁的场景，用Standby。比如物联网的传感器节点，半小时才采一次数据发出去。这种情况下，每次唤醒都重新初始化也没关系，关键是休眠时要尽量省电。差几微秒的唤醒时间，对比半小时的休眠时长，完全可以忽略。
需要保持运行状态的，只能用Stop。如果你的设备有复杂的状态机，休眠前的状态很重要，唤醒后要接着处理，那Standby就不合适了——一觉醒来什么都忘了，状态全丢。Stop模式能保持SRAM和寄存器，唤醒后直接接着跑。
几个容易踩的坑说两个我踩过的坑，省得你们再走弯路。
第一个，很多人配置Stop模式后发现功耗不对，比手册上标的高很多。大概率是GPIO没配好——浮空的输入引脚会引入额外功耗。进入低功耗前，把不用的GPIO都设成模拟输入或者带上拉/下拉的输出，功耗能下来一大截。
第二个，用Standby的时候，别把需要保存的数据放在普通SRAM里。一进入Standby，普通SRAM就断电了，数据全丢。如果确实需要保存少量数据，可以用备份寄存器（BKP）或者RTC的备份域，这些在Standby下是保持的。数据多的话，就存Flash里。
还有一点容易忽略：唤醒源的选择。Stop模式下几乎所有外部中断都能唤醒，但Standby能用来唤醒的源少很多，就那么几个。选型的时候就要考虑清楚，别等画完板子才发现唤醒源不对。
简单总结一下Stop和Standby没有绝对的好坏，就是一个"功耗"和"便利性"的权衡。
想要唤醒快、能保持状态，就用Stop，代价是功耗稍高一点点（其实也很低了）。想要极致低功耗、唤醒频率不高、不在乎启动时间，就用Standby，能把功耗压到最低。
实际项目里，很多时候是两种模式配合着用——短时间休眠用Stop，长时间不用就进Standby。具体怎么组合，就得看你的产品需求了。
