做单片机低功耗项目，最有意思的一件事就是看着电流表上的数字往下跳。树莓派Pico这板子，网上讨论最多的往往是怎样控制舵机、怎样玩转各种外设，但真到做电池供电产品时，焦点就会落到低功耗和唤醒机制上。Pico 的软件控制本质上是给了开发者一批电源管理的 API，MicroPython 和 C SDK 都有，用法和注意事项却很少能在一篇文章里讲全。这篇我把从 API 到实践的过程重新走一遍，包括三种睡眠模式的选型、关键接口、实测方法和几个我踩过的坑。新手可以用它当入门指南，做过一两轮低功耗设计的人也能对照着查漏补缺。
很多人会问：树莓派Pico 到底能不能做低功耗项目？答案是可以，但有限制。RP2040 这颗芯片本身静态电流不算大，进入休眠或 dormant 模式后能到微安级别，比普通 STM32 稍高一点，但仍然适合做电池供电的传感器节点、遥控器、小型控制器。真正影响功耗的往往是板载 USB 电路、LED、外设和 GPIO 状态。这篇文章会从方案选型开始，把 API 背后的原理和落地细节拆开讲，顺便记录我实测中遇到的各种问题。整篇内容基于我自己的项目经验，固件版本不同可能略有差异，但排查思路是通用的。
1. 项目整体设计与低功耗方案选型
低功耗设计从来不是“在代码末尾加一句 sleep”这么简单。先想清楚整个系统的工作模式，再决定用哪一级低功耗 API，才是正确的顺序。
1.1 为什么选择树莓派Pico作为低功耗控制核心
树莓派Pico的最大优势是性价比和生态。一块板子十几块钱，双核 Cortex-M0+，外设接口齐全，MicroPython 固件开箱即用，C SDK 的文档也算详细。做低功耗项目时，Pico 比很多传统单片机友好得多，因为它的社区里已经有大量现成的低功耗案例和 API 封装，不需要从数据手册的寄存器层面开始啃。
但选择 Pico 之前必须清醒认识到一点：开发板不等于芯片。Pico 板子上有 USB 转串口芯片、电源 LDO、板载 LED 等外围电路，哪怕芯片休眠到微安级，这些外围也可能偷偷吃掉几毫安。如果项目目标是纽扣电池供电多年的产品，我会建议直接买 Pico 模块或者只使用 RP2040 芯片自行设计最小系统；如果只是做原型验证、评估方案，那直接用开发板没问题，只要在测试时把板载干扰排除掉就行。
单论软件控制，Pico 在 MicroPython 里的machine模块提供了 sleep、lightsleep、deepsleep 等接口，在 C SDK 里又有更底层的 dormant 模式接口。这些 API 让开发者可以按需切换到不同功耗档位，比某些单片机只有一个 idle 模式要灵活得多。实际项目中，我用 Pico 做过户外温湿度采集节点，也做过遥控器，整体体验是：代码调试速度快，低功耗能力够用，但细节处理不到位的话，电流会非常难看。
1.2 三种低功耗模式怎么选：sleep、lightsleep 与 deepsleep
Pico 的软件控制接口通常会暴露三种睡眠层级，我在取舍时一般按下面这张表来决策：
| 模式 | 典型待机电流 | 唤醒源 | 恢复时间 | 适合场景 |
|---|---|---|---|---|
| sleep（普通睡眠） | 毫安级，比 run 低一些 | 定时器、GPIO 中断、看门狗 | 微秒级 | 需要高频快速唤醒的短任务 |
| lightsleep（浅睡眠） | 毫安级，部分时钟关闭 | RTC 定时器、GPIO 边沿 | 毫秒级 | 周期性任务，间隔几秒到几十秒 |
| deepsleep / dormant（深睡） | 几十微安到几百微安 | RTC 闹钟、GPIO 边沿 | 毫秒级 | 电池长期待机，唤醒频率很低 |
普通 sleep 在 RP2040 上基本只是让 CPU 暂停，外设时钟还开着，省电效果有限。lightsleep 会把大部分时钟域关掉，但保留某些唤醒源，适合“每 5 秒醒一次，采集数据然后继续睡”的场景。deepsleep 在 MicroPython 中通常映射到底层的 dormant 模式，RTC 和唤醒逻辑继续运行，其他部分基本断电，适合“一天只醒几次”的场景。
选型时不要盲目追求最低功耗。deepsleep 的恢复流程更复杂，唤醒后很多外设状态会丢失，需要重新初始化；如果任务每隔几秒就要跑一次，用 deepsleep 反而可能因为启动开销导致平均功耗更高。我自己做项目时，一般先把任务周期列出来：周期小于 1 秒用 sleep，周期在 1 秒到 1 分钟用 lightsleep，周期超过 1 分钟或者要求断电待机才用 deepsleep。这个经验能帮你少走很多弯路。
2. 软件控制的 API 底层原理与核心接口
低功耗 API 的调用方式不难，但理解它背后做了什么更重要。这一节我会把 MicroPython 和 C SDK 两类接口都讲一下，顺便解释它们的差异。
2.1 MicroPython 中的低功耗 API 与调用方式
MicroPython 里最常见的三个接口是machine.sleep、machine.lightsleep和machine.deepsleep。lightsleep和deepsleep可以传入毫秒数作为超时定时唤醒，也可以在某些固件版本中传入引脚参数等待 GPIO 边沿唤醒。一个最简单的定时节电程序类似这样：
import machine # 浅睡眠 5 秒，醒来后继续执行后面的代码 machine.lightsleep(5000) print("wake up") # 深睡 30 秒，唤醒后脚本会从头执行 machine.deepsleep(30000)这段代码看着简单，实际项目里却有不少细节。首先，RP2040 上的deepsleep在不同 MicroPython 固件版本里的实现并不完全一致。较新的固件通常会把系统切到 dormant 模式，只保留 RTC 和唤醒源；但旧固件可能只是做了类似 lightsleep 的处理，电流降不下去。我建议拿到板子后先升级到官方最新稳定版固件，再写一个最简休眠测试，实测电流是否达到预期。
另一个容易踩的坑是：MicroPython 的 deepsleep 唤醒后，脚本会从main.py开头重新执行。这不是 Pico 的问题，而是 MicroPython 的解释器设计如此。所以你不能想当然地认为“睡醒之后会回到 sleep 下一行继续跑”。如果想区分“首次启动”和“唤醒后启动”，需要借助 RTC 内存或文件系统保存状态。下面这段代码展示了一种笨但有效的状态标记：
import machine rtc = machine.RTC() if rtc.memory() == b'wake': # 这是唤醒后的第二次执行，开始干活 do_something() rtc.memory(b'') machine.deepsleep(30000) else: # 首次启动，或者上次工作已完成 rtc.memory(b'wake') machine.deepsleep(30000)如果用这种方案，还要注意 RTC 内存不支持所有平台，RP2040 上是否可用取决于固件编译选项。我在项目里更常使用外部 Flash 里的小文件作为标志位，虽然会引入擦写寿命问题，但胜在通用。
2.2 C SDK 中更底层的电源管理接口
如果你用的是 C SDK，低功耗控制的粒度会更细。RP2040 的数据手册里，把最低功耗状态称为 dormant，进入 dormant 之前通常要先配置好唤醒源和时钟。官方 SDK 里相关的接口主要分布在hardware/rtc.h、hardware/pll.h、hardware/clocks.h和sleep.h这些头文件里。
典型的 dormant 流程是这样：
- 把系统时钟切换到外部晶振或保持低功耗时钟源，必要时关闭 PLL；
- 配置 RTC 闹钟，或者配置唤醒引脚为边沿触发；
- 调用
sleep_goto_dormant_until_edge_high(pin)之类的等待函数进入休眠； - 唤醒后重新配置时钟，恢复外设状态。
官方例程hello_dormant里演示了sleep_goto_dormant_until_edge_low的用法，唤醒源是 GPIO 信号。C SDK 的好处是可以精确控制每一个寄存器，功耗能做到比 MicroPython 更低，也更适合直接集成到产品固件里。但代价是代码量明显增加，而且唤醒后的时钟重配非常容易出问题。如果你只是评估 LPO 功耗，先跑官方例程是最稳妥的方式。
我在实际项目里通常会先在 MicroPython 环境验证业务逻辑，等逻辑稳定后，再把功耗敏感部分用 C SDK 重写。这样既能利用 Python 的快速迭代，又能拿到 C 语言级别的低功耗效果。
3. 从 API 到实践的完整落地流程
讲完原理，我们直接落到操作。这一节我会带你走一遍完整流程：环境准备、基线测量、代码实现和结合外设的真实案例。所有步骤都以常见实践为准，固件差异会单独提醒。
3.1 准备工作：环境、工具和基线测量
做低功耗项目，一块可信任的电流测量设备比编译工具链还重要。我早期用过普通万用表的电流档，量程切换太粗，测量微安级电流时读数根本跳不稳；后来换了一块便宜的台式万用表和几个精密采样电阻，才把数据测准。如果预算有限，至少也准备一个能测微安的小量程电流表，或者自己用 INA219 模块搭一个简易电流计。
硬件连接上有几个关键点：
- 测量电流时，把电流表串在供电正极线路上，不要串在地线上，避免共地干扰；
- USB 供电时会引入额外的电流路径，测深睡眠电流时尽量用电池或外部可调电源给 VSYS 供电，并彻底拔掉 USB 线；
- 板载 LED 接到 GP25，不写代码时默认可能是输出低电平拉亮，测试前先用代码把它设为输入，或者直接断开相关跳线。
我每次都会先烧一个最简单的点灯程序，确认 Pico 能正常运行，然后测一次 run 模式的电流作为基线。接着再烧一个彻底休眠的程序，测一次最低电流。如果这两个数值差距很小，说明睡眠 API 根本没有生效，先查固件版本和接线，再做更复杂的功能。
基线测量非常折磨人，但也是低功耗项目里最有价值的一步。我见过很多人写了一大堆低功耗代码，结果电流还是 20 多毫安，最后发现只是没断开 USB 连线。先把基线打牢，后面所有优化才有意义。
3.2 案例一：定时唤醒的传感器节点
假设我们要做一个电池供电的温湿度采集节点，每 30 秒醒一次，通过 UART 把数据发出去，然后继续深睡。基于 MicroPython，最直白的写法是：
import machine from machine import Pin, UART def do_task(): uart = UART(0, baudrate=115200) uart.write('hello low power\r\n') uart.deinit() Pin(25, Pin.IN) # 禁用板载 LED do_task() machine.deepsleep(30000)第一次烧录运行会发现问题：板子会在开机时执行一次任务，睡 30 秒，醒来后从头又开始执行任务、又睡，如此循环。这看起来没什么问题，但如果你希望“首次启动只睡不干活，之后每次唤醒都干活”，就必须给程序加状态判断。
我的习惯是先用 RTC 内存做标记，因为读写比 Flash 快得多。RP2040 的 MicroPython 固件如果支持machine.RTC().memory()，可以直接使用；如果不支持，就用一个小的.state文件。示例：
import machine rtc = machine.RTC() SLEEP_MS = 30000 # 尝试读取状态 state = rtc.memory() if hasattr(rtc, 'memory') else b'' if state == b'work': # 上一次已经准备睡觉，这次醒来应该执行任务 rtc.memory(b'') # 清空状态 do_task() machine.deepsleep(SLEEP_MS) else: # 首次启动，先标记状态，再进入睡眠 rtc.memory(b'work') machine.deepsleep(SLEEP_MS)这个流程的逻辑要点在于：唤醒后第一件事不是干活，而是通过状态判断该不该干活。否则每次复位都会误执行一次本该只在唤醒后执行的操作。
除了状态判断，还要考虑唤醒后有没有外设需要重新配置。UART、ADC、I2C 这类外设在深睡后多半处于默认状态，必须在任务函数里重新初始化。我的do_task()每次都会重新创建 UART 对象，用完再释放，就是为了避免在睡眠期间留下占用状态。
3.3 案例二：GPIO 边沿唤醒与低功耗舵机控制
热搜里经常有人搜“树莓派pico控制舵机”，但很少有人提舵机待机时也在耗电。舵机只要通电就会维持力矩，电流从几十毫安到几百毫安不等，这直接毁了低功耗设计。所以我在涉及舵机的项目里，一定会用外部负载开关切断舵机电源，只让 Pico 核心保持待机。
硬件上，用一只 P-MOS 或者负载开关芯片串在舵机电源线里，Pico 的一个 GPIO 控制开关。这个 GPIO 在低功耗模式下保持低电平，确保舵机断电；唤醒后再拉高，给舵机上电。整套系统还可以加一个按键，按下后通过 GPIO 边沿唤醒 Pico。
下面是一个基于 MicroPython 的简化示例：
from machine import Pin, PWM, deepsleep import time # 舵机电源控制引脚 servo_power = Pin(6, Pin.OUT) servo_power.value(0) # 默认关闭 # 唤醒引脚，接按键到 GND，按下产生下降沿 wake_pin = Pin(16, Pin.IN, Pin.PULL_UP) # 进入深睡等待唤醒 deepsleep(wake_pin)注意，deepsleep(wake_pin)这种写法并不是所有固件都支持。有些版本要求machine.deepsleep(time_ms, wake_pins)，还有的固件只支持定时唤醒。遇到不支持的情况，可以退而求其次用lightsleep配合引脚 IRQ，一样能实现按键唤醒，只是待机电流会高一些。
唤醒之后，代码会从脚本开头执行，此前servo_power已经初始化为 0，舵机保持断电状态。这时需要重新拉高舵机电源，初始化 PWM，控制舵机转到目标角度，等舵机完成动作后再关闭 PWM 和电源，重新进入深睡。一个容易忽略的问题是，舵机上电瞬间电流尖峰很大，如果电池或 LDO 供电能力不足，Pico 可能会被拉复位。所以我在靠近舵机电源引脚的地方都会加一个大电解电容，通常 220 到 470 微法，能明显改善电压跌落。
4. 常见问题、排查技巧与实操心得
低功耗项目的难点集中在最后调试阶段。你会发现所有 API 都调用了，电流却依然“纹丝不动”。这一节把常见问题、排查思路和我自己的一些心得整理出来。
4.1 电流居高不下的排查：硬件基线优先
低功耗模式下电流异常偏大，我通常会按下面这些原因逐项排除：
| 可能原因 | 典型现象 | 解决方法 |
|---|---|---|
| 板载 LED 仍然点亮 | 电流多 1 到 5 mA | 把 GP25 设为输入，或物理断开 |
| USB 连线未断开 | 电流多 10 到 50 mA | 测量时使用电池/外部电源，拔掉 USB |
| 外设电源未切断 | 电流一直多几十到几百 mA | 用负载开关单独控制外设供电 |
| GPIO 悬空引脚漏电 | 电流多个几 mA | 未用引脚设为输入并启用上下拉 |
| 电源芯片自身功耗 | 待机电流与模式无关 | 更换静态电流更低的 LDO 或 DCDC |
| 锂电池保护板损耗 | 待机电流偏高 | 减小导线电阻，关闭保护板额外负载 |
排查顺序很关键：先把所有外设断开，Pico 最小系统跑到最低模式，测出“裸板功耗”。如果这一步电流正常，说明低功耗 API 没问题，问题在外部电路；如果这一步电流都不正常，再从固件和板级找原因。切记不要一开始就怀疑寄存器配置有问题，硬件漏电的概率往往更高。
我踩过最深的坑是：GPIO 悬空。有一块板子在 deepsleep 下电流一直稳定在 2.3 mA，排查了很久，最后发现是一个没用到的引脚默认浮空，反复漏电。把引脚显式设置为输入并拉低之后，电流立刻降到 90 多微安。所以我在编写低功耗代码时，会写一个disable_unused_pins()函数，把未用 GPIO 统一处理一遍。
4.2 Deep sleep 唤醒后的运行状态与工程化设计
深睡唤醒后，CPU 和外设重新上电，寄存器回到默认状态，MicroPython 脚本从头执行。这个行为特点很容易让新手困惑：为什么唤醒后变量值都没了？我用 RTC 内存或文件状态来解决，但还有另一个细节——系统时钟。
RP2040 进入 deepsleep 之前，如果我把时钟切到了低频外部晶振，唤醒后 PLL 可能没有自动恢复。这时再去操作 UART 或 PWM，波特率和频率会完全不对。C SDK 官方例程里一般会有reconfigure_clock()，MicroPython 固件内部通常做了恢复，但外部晶振的等待时间不同，偶尔也会出现首次 UART 输出乱码的情况。稳妥做法是在暖启动后加一个小延时，比如 10 到 50 毫秒，让时钟稳定。
中断问题也要注意。进入休眠前，如果某个外设中断频繁触发，它可能会把系统反复唤醒，导致无法真正睡下去。我习惯在进入低功耗前关掉不需要的中断，唤醒后再重新注册。MicroPython 里可以用irq处理，C SDK 里则要显式irq_set_enabled。
工程化设计上，另一个容易被忽略的是看门狗。如果用了独立看门狗，深睡会让看门狗超时复位，反而破坏低功耗流程。要么在休眠前暂停看门狗，要么把看门狗超时时间拉得很长。我在电池供电项目里通常不使用独立看门狗，而是靠 RTC 闹钟和外部唤醒来保证安全性，减少功耗。
4.3 几个反直觉的低功耗经验与专属建议
第一，降频并不一定能省电。RP2040 运行频率降低后，执行任务的时间会拉长，虽然瞬时电流略降，但总功耗可能反而上升。尤其是需要定时唤醒的任务，高频率短时间执行完，再快速进入深睡，往往比低频率慢吞吞执行更省电。所以我很少通过降频来优化电池续航。
第二，不要迷信数据手册里的静态电流。手册上的数字是在理想条件下测得的，实际板子有 LDO、LED、USB 接口，外部还有各种上拉电阻，统统会把电流拉高。我实测 Pico 开发板用官方 MicroPython 跑 deepsleep，裸板大概在一百微安到几百微安区间，比芯片的 dormant 理论值高不少。如果产品必须做到几十微安，建议重新画板，而不是继续用开发板。
第三，买一个带示波器功能的电流探头会方便很多。普通万用表只能看到平均电流，看不到唤醒瞬间的尖峰。我曾经遇到一个舵机项目，平均电流看起来很低，但每次上电瞬间都有一毫秒的大电流毛刺，导致电源电压严重跌落。后来借了一台电流探头，才发现问题出现在负载开关开通太慢。这种瞬态问题，只靠万用表很难定位。
第四，代码里尽量少用阻塞式延时。深睡之前的time.sleep()会让系统白白空转。如果需要等待外设稳定，可以临时用lightsleep替换部分延时，既能保持 CPU 低功耗，又能达到延时的目的。但要注意确保唤醒源设置正确，否则可能一睡不醒。
最后，分享一个小技巧：在电路板上预留一个功耗测量跳线，或者直接焊一个 0 欧姆电阻作为测量点。现场调试时断开跳线，把电流表串进去，测完再恢复。这个习惯帮我省了大量拆线接线的时间，也避免因为反复插拔导致接口接触不良。
回头再看，低功耗控制的难点从来不在 API 本身，而在系统级的功耗边界。Pico 能睡到微安级，前提是你把板载 USB、LED、外设供电和 GPIO 状态全部清理干净。我的习惯是先把测量设备和基线搭好，再一行行改代码，每改一步都看一眼电流变化。不要一上来就把所有低功耗接口全用上，否则出了问题很难定位。希望这篇实践笔记能帮你少走点弯路，把树莓派Pico的软功耗控制真正用起来。
