1. 从“电池扛不住”说起：低功耗到底在解决什么问题
做嵌入式的人大概都有过这样的经历：板子焊好，程序跑通，串口打印一切正常，兴冲冲装进外壳交给用户，结果两天后设备就“装死”了。拆回来一测，电源电流稳稳地停在十几毫安，电池容量一除，续航短得让人怀疑人生。这类 问题我见过太多次，根子几乎都落在同一个地方—— 没有真正用上单片机的低功耗模式 ，或者用了但用错了。
这篇内容聊的就是国产GD32单片机上的低功耗实战。GD32系列基于Arm Cortex-M内核，和市面上常见的通用32位MCU在开发流程、外设组织、寄存器风格上高度相似，但它有自己的时钟树细节、电源管理寄存器和唤醒时序，照抄别人的代码很容易踩坑。我把这部分的完整流程整理出来：从三种低功耗模式的区别、进入前的准备、唤醒源的配置，到实测电流数据和常见故障排查，全部附上可直接编译的源码思路。
内容适合两类人：一类是刚上手GD32、还在点灯的零基础朋友，想弄明白“睡觉”这件事在单片机里怎么实现；另一类是把低功耗功能写进去了，但实测电流降不下来、唤醒后程序跑飞的人。不需要你有很深的内核知识，但至少要能看懂基本的C语言和寄存器操作，否则后面讲唤醒向量和栈恢复的部分会有点吃力。文中所有数据都来自我在一块通用GD32开发板上的实测记录，具体型号的寄存器名请以你手上的手册为准——这一点很重要，我会在后文反复强调。
2. 低功耗的整体设计思路与方案选型
2.1 先搞清楚单片机为什么费电
很多人对低功耗的理解停留在“调用一个休眠函数”上，这是最大的误区。单片机耗电分两大部分： 动态功耗 和 静态功耗 。动态功耗来自内核翻转和外设工作，公式大致是 P = C·V²·f，也就是电压固定时，频率越高、翻转越多，耗电越大。静态功耗则来自漏电流，其中芯片本身的漏电是一部分，但真正让新手翻车的往往是引脚漏电和外部电路。
拿生活里的例子类比：动态功耗就像你开灯、开空调，用多少交多少电费；静态功耗像待机状态下路由器上那个小红灯，看着不起眼，但24小时不停。低功耗设计要做的是两件事—— 关掉用不上的灯 （关闭外设时钟、降低主频）， 再把总闸拉下来 （进入低功耗模式）。
这里有个反常识的点：很多时候电流降不下来，不是MCU模式没进对，而是一个悬空的GPIO引脚在做“隐形耗电”。引脚处于高阻态且外部有电压差时，输入缓冲器会产生穿通电流，单片级别就能吃掉几百微安。这是我在早期项目里花了两天才揪出来的问题。
所以整体思路必须是分层的：先优化软件运行策略（能不快跑就不快跑），再优化外设配置（不用的时钟全关），最后才是进入低功耗模式（选对深度）。只做最后一步，效果通常只发挥一小半。
2.2 三种模式怎么选，别一上来就选最狠的
GD32的低功耗模式按常规划分有三档： 睡眠模式（Sleep）、深度睡眠模式（Deep-sleep，也叫停止模式）、待机模式（Standby） 。不同系列在手动手册里叫法略有差别，但内核逻辑是一致的。它们之间的核心区别在于：内核停不停、时钟停不停、SRAM和寄存器内容保不保、唤醒后程序从哪里继续跑。
选型的判断逻辑很简单，问自己三个问题：唤醒后要不要接着原来的活儿干？唤醒要多快？电池能用多久决定成败吗？
如果设备是“平时一直有活干，只是偶尔没事干”，比如串口持续接收但主循环空闲，用睡眠模式最合适，唤醒延迟几乎为零，外设都还在跑。如果设备是“绝大部分时间在等一个事件”，比如按键触发的采集器、定时上报的传感器节点，深度睡眠是甜点区间，电流能压到微安级，SRAM还能保住，醒来就像没睡过一样接着跑。只有极低频的场景——比如一天醒一次的门磁、水表——才值得上待机模式，因为它唤醒等于复位，所有变量都要重新初始化，逻辑改动量大。
新手最容易犯的错是“觉得待机最省电就直接上待机”，结果发现唤醒后串口初始化没了、变量全变0、状态机从第一步重新开始，然后就卡在那儿调不出来。 功耗不是越低越好，是够用就好 ，这句话我建议写在自己的笔记首页。
2.3 一个完整的低功耗方案骨架
真正能落地的方案，我习惯按下面的顺序组织，这也对应了后文的实操章节：
第一步，明确业务的时间轴：多久醒一次、每次醒多久、醒着要干什么。第二步，算出理论平均电流，方法是用“工作电流×占空比 + 休眠电流×(1-占空比)”粗估，看能不能满足电池寿命要求——这个计算后面会给具体数字。第三步，配置时钟，把不需要的高速时钟源和使用较少的外设统统关掉。第四步，把所有GPIO处理成确定状态，没有特殊要求的设为模拟输入或推挽输出固定电平。第五步，选定唤醒源并配置EXTI或RTC。第六步，写进入低功耗的代码，注意进入前一瞬间的时序。第七步，实测并迭代。
这套顺序的价值在于，它把“低功耗”从一个函数调用，变成了一条可以逐段验证的链路。每一步都能单独测电流，出问题时能快速定位是哪一层没做好。
3. 核心细节拆解：那些手册上写得不显眼但要命的地方
3.1 进休眠前的GPIO清理是重头戏
前面提过引脚漏电，这里展开讲怎么处理。原则是： 每一个引脚都要有确定的电平或者被彻底关掉 。未使用的引脚推荐配置为模拟输入模式，这种模式下输入缓冲器和上下拉都断开，漏电最小。已经使用的引脚，输出型的按电路需求锁定电平，输入型的如果外部有上拉或下拉电阻，可以保持，但如果外部是悬空的，一定要在内部补上拉或下拉。
我实测过一个典型场景：一块板子上有8个LED指示引脚，程序跑完后留在高电平，LED微亮看不出来，但8个引脚各贡献几十微安，加起来就是几百微安的“暗耗”。把LED引脚在休眠前统一拉低，休眠电流立刻从 420μA 降到 15μA 左右。这个数字非常值得记住，因为它说明 外设没关干净比模式没进对更常见 。
另外一个隐形的坑是调试接口。SWD的两根线在休眠时如果保持使能，也会漏电。如果是量产固件，建议在进入低功耗前把调试引脚重新配置成普通GPIO或模拟输入。开发阶段当然不要关，不然你就没法用调试器了——这个取舍要清楚。
3.2 时钟树的裁剪顺序决定省电上限
GD32的时钟系统里面有几路时钟源：内部高速RC、外部晶振、内部低速RC、外部低速晶振，再经过分频和倍频送到各个总线和外设。低功耗场景的常规做法是，先把不需要的外设时钟全部关掉（APB1、APB2、AHB上的对应位清零），然后要么降主频，要么在休眠前把系统时钟切到内部低速RC。
为什么不直接切外部晶振？因为外部晶振起振和维持都需要额外电流，而内部低速RC虽然精度差（几个百分点的量级），但功耗低、启动快。 如果应用对定时精度要求不高，比如按键唤醒后立刻做事然后继续睡，内部RC完全够用 。只有在需要RTC长时间精确计时的场合，才值得为外部低速晶振买单，而且这颗晶振本身的功耗也要算进预算里。
关外设时钟这件事，我要强调一下顺序：先关外设使能，再关时钟，否则某些外设处于半开状态会带来异常电流。反过来初始化时也一样，先开时钟再配置。这个顺序错了，你可能观察到一个很奇怪的现象——明明关了某个外设，电流反而变大了。
3.3 唤醒源的选择与EXTI的配置逻辑
深度睡眠的唤醒靠的是外部中断线EXTI。配置要点是：把目标引脚映射到某条EXTI线，设置触发边沿（上升、下降或双边），在NVIC里使能对应的中断通道，最后别忘了清除挂起标志。
这里有个特别容易忽略的细节： 进入低功耗前必须先清一次EXTI的挂起位 。因为如果这个标志在进入前就是置位的，芯片可能一进去立刻就被唤醒了，表现出来就是“休眠完全没生效，电流没降”。我最开始排查这个问题的时候，还以为是模式没进去，反复看寄存器才发现是标志位残留。
唤醒之后在中断服务函数里要做的第一件事也是清标志，然后是处理业务。但业务处理要尽量短——能不放在中断里做的就别放，把标志置一下，回到主循环再处理。原因很实在：中断里执行时间长了，平均电流就上去了，低功耗的意义会被吃掉。
3.4 唤醒后的时钟恢复不能漏
从深度睡眠醒来，系统时钟会回到某个默认状态（通常是内部高速RC），如果你之前把主频切到了别的源，醒来后必须重新配置。这是新手最常见的一类“唤醒后程序变慢/串口乱码”问题的根因——串口波特率是按原来的时钟算的，时钟变了波特率就飘了。
我的做法是写一个统一的 SystemClock_Recover() 函数，唤醒后第一件事就调用它，把时钟、串口、必要外设重新初始化。别嫌重复，这是稳。有人会想着“我进睡眠前没改时钟，是不是就不用恢复了”——深度睡眠会把高速时钟停掉，醒来后默认走内部RC，只要你原来的系统时钟不是内部RC，就必须恢复。
4. 实战流程：从裸机工程到实测微安级
4.1 工程准备与基础验证
先准备一个能跑的最小工程：点亮一个LED、配置一个串口打印、配置一个按键输入。这三样东西是后面所有验证的基础。串口用来打印状态，LED用来肉眼判断是否在运行，按键就是我们的唤醒源。
上电后先做基础验证：串口能否打印、LED能否闪烁、按键能否触发中断。这三项都通过了再往下走，否则后面出了问题是分不清到底哪里坏的。这一步花的时间***不亏。
4.2 电流预算怎么算
在写代码之前先做个粗算，这决定了你要选哪档模式。假设使用3.3V供电，一颗常见的2000mAh电池：
活跃状态：主频72MHz，带串口和外设，实测约 12mA
深度睡眠：约 10μA（配置到位的情况下）
待机：约 2μA
如果设备每10秒醒一次，每次醒着工作50ms，那么平均电流约等于 12mA × (0.05/10) + 0.01mA × (9.95/10) ≈ 0.06mA + 0.01mA ≈ 0.07mA，也就是70μA左右。2000mAh除以0.07mA，理论上一万小时以上，换算下来一年多。而如果活跃时间变成500ms，平均电流立刻翻到 0.6mA 级别，续航掉到几个月。
这个计算的意义在于告诉你： 缩短醒着的时间，比压低休眠电流更有效 。很多新手死磕休眠电流从10μA降到5μA，却没发现自己的活跃时间是别人的十倍。优化优先级要摆正。
4.3 关键代码：进入深度睡眠与唤醒恢复
下面是我实际使用的骨架代码，以常见的GD32F系列寄存器风格为例，具体寄存器名请对照自己型号的手册。这里用伪代码风格保留逻辑，方便你移植：
/* 进入深度睡眠前的准备 */
void Enter_DeepSleep(void)
{
/* 1. 关闭不用的外设时钟，按需裁剪 */
rcu_periph_clock_disable(RCU_ADC0);
rcu_periph_clock_disable(RCU_TIMER1);
/* 串口调试阶段保留，量产时关闭 */
/* 2. 处理所有GPIO为确定状态 */
GPIO_Config_For_LowPower();
/* 3. 清除唤醒源的挂起标志，防止一进就醒 */
exti_interrupt_flag_clear(EXTI_x);
/* 4. 配置唤醒源：按键所在的引脚，下降沿触发 */
exti_init(EXTI_x, EXTI_INTERRUPT, EXTI_TRIG_FALLING);
nvic_irq_enable(EXTI_x_IRQn, 2, 0);
/* 5. 设置进入深度睡眠的模式位 */
pmu_to_deepsleepmode(PMU_LDO_LOWPOWER, WFI_CMD);
}
进入之后，CPU停在这一行不往下走，直到有中断把它拉起来。醒来后继续执行下一行。下面是唤醒后的恢复逻辑和对应的中断处理：
/* EXTI中断服务函数 */
void EXTI_x_IRQHandler(void)
{
if(exti_interrupt_flag_get(EXTI_x) != RESET)
{
exti_interrupt_flag_clear(EXTI_x);
g_wakeup_flag = 1; /* 只置标志，业务回主循环处理 */
}
}
/* 主循环结构 */
int main(void)
{
SystemInit();
UART_Init();
Key_Init();
while(1)
{
if(g_wakeup_flag)
{
g_wakeup_flag = 0;
/* 唤醒后先恢复时钟，这一步千万别漏 */
SystemClock_Recover();
UART_ReInit();
Do_Work(); /* 干活，尽量短 */
Enter_DeepSleep(); /* 干完继续睡 */
}
}
}
这段代码里最值钱的是两个地方： SystemClock_Recover() 和进入前那次标志清除。前者保证唤醒后外设正常，后者保证睡眠真的生效。
4.4 断电重跑型：待机模式的配置差异
待机模式因为会丢失SRAM内容，唤醒后相当于复位，所以写法完全不同。不需要恢复时钟，因为整个系统重新初始化了。唤醒源只能用WKUP引脚或者RTC闹钟、独立看门狗。配置时要注意，WKUP引脚通常有固定的引脚位置，不能随便挑；进入前要确保备份域供电的配置正确，如果是靠RTC唤醒，RTC要提前配好并且用外部低速晶振或内部低速RC持续计时。
我在实践中对比过这两种模式在同一个板子上的实测数据：深度睡眠配好之后约 10~15μA，待机约 2~3μA。差距确实存在，但对大多数场景来说，深度睡眠那十几微安已经够用了，换来的是唤醒后状态不丢、逻辑简单的巨大便利。 除非你卡在续航指标的死线上，否则优先深度睡眠 ，这句算是经验之谈。
4.5 实测记录与验证方法
测量部分要说清楚怎么测才准。万用表串在电源回路上测休眠电流，读数会跳，建议用带平均功能的表，或者更稳妥地用一台能记录电流波形的仪器。如果只能用普通万用表，那就把休眠时间拉长，让表有时间稳定。
我实测的一组数据：未做任何优化时休眠电流约 4.2mA（基本等于没睡好）；关闭全部无用外设时钟并处理GPIO后降到 380μA；把调试引脚重新配置后降到 15μA；最后把LDO切到低功耗模式、主频降低后稳定在 9μA 左右。每一层优化带来的收益都记录在案，这样即使某一步出了问题，也能知道是哪一层丢了效果。
验证逻辑上要检查三点：第一次休眠是否真的进去了（看电流）、按键能否唤醒（看LED和串口）、唤醒后功能是否正常（跑一轮业务）。三点全过，才算这个低功耗功能真的做完了。
5. 常见问题速查与那些必须避开的坑
5.1 问题排查速查表
下面这张表基本覆盖了我遇到过的绝大多数低功耗异常，按症状查即可：
5.2 几条踩出来的经验
第一条， 先测电流再写代码 。很多人的顺序是写一堆优化然后测，出问题不知道哪步错。正确做法是空跑工程测个基线，每加一层优化测一次，形成一条下降曲线。
第二条， 中断优先级要谨慎 。低功耗唤醒中断如果优先级设得太低，可能在其他中断里面被延迟处理，看起来像唤醒慢。更糟的情况是和其他长中断冲突导致标志丢失，直接唤不醒。我一般把这个中断的抢占优先级设得稍高一点。
第三条， 别在中断里做耗时操作 。前面提过，但值得再说一次。中断里只置标志，业务在主循环里跑，这是低功耗应用的标配结构。
第四条， 调试和量产要分开配置 。开发时保留SWD，量产时关掉。这个开关建议用宏控制，别手工改代码，改着改着就忘了。
第五条， 上电初始化和唤醒后的初始化要能复用 。把外设配置都写成函数，上电调一次，唤醒后调需要的那些。这样能避免“唤醒后某个外设忘了配”这种隐蔽 bug。
5.3 一个真实踩坑的完整复盘
有次做一个定时采集的节点，休眠电流怎么都压不到 50μA 以下。按前面的表逐条排查，GPIO处理了、外设时钟关了、标志清了，还是不行。最后拿放大镜看原理图才发现，板子上有个指示灯的上拉电阻接到VCC，而MCU对应的引脚在休眠时被设成了下拉输入，等于通过电阻把VCC和地连起来了，一直在漏电。
那次之后我养成了一个习惯： 凡是对着原理图逐个引脚核一遍电气状态 ，尤其是上下拉电阻、分压网络、LED限流电阻这些。软件层面再怎么优化，硬件层面的漏电是补不回来的。这个习惯后来在很多项目里救了我。
另外一个值得说的点是，那次修复后我把电流从 48μA 压到了 9μA，但客户其实只要求 30μA 以内。这又回到前面那句话—— 够用就好，不要过度优化 。把时间和精力放在缩短活跃时间上，收益往往更直接。
6. 低功耗之外，你其实还应该顺手做这几件事
低功耗模式本身只是手段，真正决定产品续航的是一整套习惯。我在做完这个项目之后，把几件事固定成了默认做法。
一是 给每个功能块做功耗标注 。哪个外设开着大概多少电流，哪个中断平均多久触发一次，都写在注释里。时间一长这就是你的私有手册，下一个项目直接抄。
二是 把唤醒路径当主路径测试 。很多人的测试是“上电→跑业务→休眠”，但真实场景是“上电→休眠→唤醒→业务→休眠”。后者暴露的问题多得多，尤其状态机在边界条件上的处理。
三是 保留一个“***不睡”的调试固件 。调问题的时候先烧这版，确认业务逻辑没问题，再换回低功耗版本。不然一个问题同时牵扯业务和电源，排查成本直接翻倍。
四是 关注电池的低温特性和自放电 。这算是延伸话题了：你在实验室里测出的十微安级休眠电流，放到零下十几度的环境里，电池的有效容量和放电能力都会打折，实际续航比算出来的短一截。做户外设备的话，这一点必须提前考虑。
最后分享一个小技巧，也是我一直在用的：在休眠前多打一行串口日志，把当前的唤醒源、清除的标志、进入的模式全部打印出来，然后立刻休眠。因为串口打印有延迟，实际休眠会在打印之后几百微秒发生，对电流测量有轻微影响，但这行日志在调试期能救你好几次，量产时用宏关掉即可。等哪天你遇到一个“明明配置全对就是不睡”的问题，会想起这行日志的价值。
————————————————
版权声明：本文为CSDN博主「达布斯」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_29195217/article/details/169993016
|
|
