树莓派Pico低功耗实战：RP2040空闲模式与可复用模块设计

做低功耗设备的人，应该都遇到过这种尴尬：系统核心功能明明只需要几十毫秒，剩下的时间全在while(1)空转，电池白白烧在无意义的循环里。树莓派 Pico 用的 RP2040 芯片也不例外，133MHz 全速空跑时，电流轻轻松松到 20mA 朝上，对一块锂电池供电的温度传感器、门磁、遥控器来说，这种浪费非常不划算。

这篇文章我就基于自己的一个移动采集终端项目，把 Pico 空闲模式（Idle Mode）怎么用、怎么把代码封装成能跨项目复用的模块、以及实测有效的功耗优化手段一次讲清楚。内容会比较偏实践，适合正在做电池供电、需要按键唤醒或定时巡检的嵌入式开发者参考。

1. 为什么盯上空闲模式：先搞清楚 RP2040 的功耗状态

1.1 一张表看懂 RP2040 的几种低功耗模式

很多刚接触 Pico 的同学以为“低功耗”就是调用一个 API 让芯片睡过去，实际上 RP2040 的低功耗路径分了好几层，从浅到深分别是：正常空闲（Idle/WFI）、深度睡眠（Sleep）、休眠（Dormant）。

我手头这块原厂 Pico 板，在外部 5V 供电、USB 不枚举、板载 LED 关闭的前提下，各状态电流参考如下（不同批次、不同测量环境会有差异）：

这一篇主要讲第一层——空闲模式（Idle Mode），它是代码侵入最小、恢复速度最快、最适合作为“默认待机态”的一档。后面第 4 章会讲怎么在空闲基础上继续往下抠功耗，顺带给 Sleep/Dormant 指个路。

1.2 空闲模式到底省了什么：WFI 的原理

RP2040 采用的是双核 ARM Cortex-M0+ 内核，它本身提供了一条WFI（Wait For Interrupt）指令。执行这条指令后，CPU 会暂停取指、暂停流水线执行，进到一个“门控时钟”的等待状态，一直要等到有中断请求到达，CPU 才会被唤醒，继续执行下一条指令。

它和你平常写的sleep_ms(1000)完全不同：sleep_ms是让定时器在后台跑，CPU 即使不干实事也可能在循环中忙等或反复调度；而WFI是实打实地把 CPU 的执行单元停住。你可以把它理解成一个人坐在工位上闭目养神，电话不响他就不睁眼，来了电话立刻接起来干活，而不是每隔几秒睁眼看一下有没有新消息。

在 C SDK 里，直接调用__wfi()就能进入这个状态。__wfi()是编译器内建函数，最终会翻译成 ARM 的wfi指令。要注意的是，WFI的核心作用是“停 CPU，不停外设”，所以外设中断——GPIO、定时器、UART、DMA——都能把它唤醒，但只有中断被使能且优先级满足条件时，唤醒才算有效。

1.3 什么场景适合用空闲模式

不是所有项目都适合用空闲模式。我大致把适合的场景归结为三类：

• 事件驱动型等待：比如按键唤醒菜单、外部中断触发拍照、传感器模拟输出触发采集。特点是“不知道什么时候来事件，但来了必须马上响应”。
• 短周期巡检型：比如每 200ms 醒来读一次环境数据，然后继续睡。这种场景下，空闲模式的唤醒延迟极低，比 Sleep/Dormant 那种需要重新锁相环、复位外设的流程快得多，时间精度也好控制。
• 系统大部分时间没有计算任务：比如主流程只是等待 UART 指令、等待 TCP 定时器，中间不做密集运算。这时候与其高频率轮询标志位，不如让 CPU 空下来。

如果应用里存在“长时间不醒也没关系”的间隙，比方说 10 秒以上，那我会建议直接考虑 Sleep 或 Dormant，而不是死磕空闲模式。空闲模式的意义在于“快进快出”，不是“一睡不醒”。

2. 可复用是设计出来的：空闲管理模块怎么拆

2.1 先定接口，再写实现

很多 Pico 入门项目里，__wfi()都是直接写在 main 函数里，简单是简单，但换个项目就得复制粘贴，而且很容易跟业务逻辑搅在一起。我后来做统一电源管理的时候，第一步就是把空闲模式抽成一个独立的idle_manager模块，设计上只做三件事：

1. 进入空闲前，调用一组用户注册的回调函数，负责“把现场收拾好”。典型操作是关 LED、关 ADC、把没有用途的 GPIO 拉成固定电平。
2. 执行__wfi()，等待中断唤醒。
3. 唤醒后，调用另一组回调函数，负责“恢复现场”。典型操作是重新开外设、拉高/拉低指示灯、恢复时钟配置。

这组回调要跟业务无关，模块内部不关心你挂上来的是传感器处理函数还是屏幕休眠函数，它只负责按顺序调用。这样一个模块可以原封不动用到下个项目里，只要重新注册回调就行。

接口层面我保留了三个函数：

• idle_manager_init()：把回调表清空，所有状态复位。
• idle_manager_add_hook()：注册一个回调节点，一个项目最多注册若干组。
• idle_manager_enter()：进入空闲，阻塞等待唤醒源，执行完回调后返回。
• 额外加一个idle_manager_enter_with_timeout()，支持“最多睡多久，超时强制醒”。

2.2 回调机制与中断安全

这里有一个常见误区：回调表是全局数据，如果注册的时机和中断触发时机交叠，可能会出现数据竞争。虽然大多数项目只在初始化阶段注册，但既然是做可复用模块，就得考虑安全边界。我的做法是，在idle_manager_add_hook()里用save_and_disable_interrupts()关中断，然后写寄存器表，最后恢复中断标志。几行代码，成本很低，但能让调用方在任意上下文中注册而不出问题。

另外，__wfi()本身有一个容易踩的坑：如果进入前，唤醒源的中断没有使能，或者已经被挂起但没有处理，WFI可能会立即返回，也可能永远睡不醒。所以模块内部会先把唤醒标志位清掉，再由外部保证唤醒中断已完成配置。

2.3 头文件实现示例

头文件不需要很长，清晰就好：

#ifndef IDLE_MANAGER_H #define IDLE_MANAGER_H #include <stdbool.h> #include <stdint.h> typedef void (*idle_hook_func_t)(void); typedef struct { idle_hook_func_t on_enter; // 进入空闲前调用 idle_hook_func_t on_wakeup; // 唤醒后调用 } idle_hook_t; #define IDLE_HOOK_MAX 8 void idle_manager_init(void); bool idle_manager_add_hook(const idle_hook_t *hook); void idle_manager_enter(void); void idle_manager_enter_with_timeout(uint32_t timeout_us); #endif

接口里不出现任何 RP2040 特有的硬件寄存器，将来你要把这套设计移植到 STM32、ESP32，只需要替换idle_manager.c里的实现，上层业务代码一行不用改。这就是“可复用”最直观的价值。

3. 手把手实现：从空工程到可用的 idle_manager

3.1 工程准备与目录结构

我用的是官方 C SDK，环境建议直接用 VSCode 加 Pico SDK 扩展，或者手动用 CMake 拉pico-sdk都行。目录结构很简单：

idle_demo/ ├── CMakeLists.txt ├── src/ │ ├── main.c │ ├── idle_manager.h │ └── idle_manager.c

CMakeLists.txt里把idle_manager.c加进目标源文件，头文件路径指对，其他没啥特殊要求：

add_executable(idle_demo src/main.c src/idle_manager.c ) target_link_libraries(idle_demo PRIVATE pico_stdlib hardware_irq hardware_timer ) pico_enable_stdio_uart(idle_demo 0) pico_enable_stdio_usb(idle_demo 0)

低功耗测试时我把标准输入输出全部关了，因为 USB 调试口本身会带来额外功耗，串口如果开着，UART 外设也在活动。调试完后做功耗实测，这两个都得关。

3.2 完整代码实现

先看头文件刚已经给出，再看源文件：

#include "idle_manager.h" #include "hardware/irq.h" #include "hardware/sync.h" #include "pico/time.h" #include "pico/stdlib.h" static idle_hook_t hooks[IDLE_HOOK_MAX]; static uint8_t hook_count = 0; static volatile bool flag_wake = false; static int64_t timeout_callback(alarm_id_t id, void *user_data) { (void) id; (void) user_data; flag_wake = true; return 0; } void idle_manager_init(void) { hook_count = 0; flag_wake = false; for (int i = 0; i < IDLE_HOOK_MAX; i++) { hooks[i].on_enter = NULL; hooks[i].on_wakeup = NULL; } } bool idle_manager_add_hook(const idle_hook_t *hook) { if (hook == NULL) return false; if (hook_count >= IDLE_HOOK_MAX) return false; uint32_t flags = save_and_disable_interrupts(); hooks[hook_count++] = *hook; restore_interrupts(flags); return true; } void idle_manager_enter(void) { for (uint8_t i = 0; i < hook_count; i++) { if (hooks[i].on_enter) hooks[i].on_enter(); } flag_wake = false; __wfi(); for (uint8_t i = 0; i < hook_count; i++) { if (hooks[i].on_wakeup) hooks[i].on_wakeup(); } } void idle_manager_enter_with_timeout(uint32_t timeout_us) { alarm_id_t alarm_id = add_alarm_in_us(timeout_us, timeout_callback, NULL, true); idle_manager_enter(); cancel_alarm(alarm_id); }

代码逻辑不复杂，但有几个点我特别说明一下。

第一，timeout_callback用了alarm_id_t类型的参数，这是当前 Pico SDK 的标准写法，老版本 SDK 可能没有报警 ID 参数，如果你用的 SDK 比较老，按自己版本调整即可。

第二，flag_wake被声明成volatile。这是因为中断服务函数和主循环是两个不同的执行上下文，编译器有可能把标志位优化掉，不加上volatile，极端情况下唤醒后判断不到事件。

第三，超时版本依赖的是 RP2040 的硬件定时器和add_alarm_in_us接口。定时器中断触发后，CPU 会被唤醒，然后flag_wake被置位。这个函数适合“最多睡 X 微秒，不管有没有事件都起来”的场景。

3.3 在 main 中接线：注册唤醒源与回调

模块本身不干活，活都在回调函数里。下面是一个典型的“LED 熄灭 + 按键唤醒 + 唤醒后闪灯提示”示例：

#include <stdio.h> #include "pico/stdlib.h" #include "hardware/gpio.h" #include "idle_manager.h" #define WAKE_PIN 2 static void on_enter(void) { gpio_put(PICO_DEFAULT_LED_PIN, 0); // 如果有 ADC 或其他外设，在这里统一关掉 } static void on_wakeup(void) { gpio_put(PICO_DEFAULT_LED_PIN, 1); // 恢复外设配置 } void gpio_callback(uint gpio, uint32_t events) { if (gpio == WAKE_PIN) { // 记录唤醒事件，可以设置标志位供主循环处理 } } int main(void) { stdio_init_all(); gpio_init(PICO_DEFAULT_LED_PIN); gpio_set_dir(PICO_DEFAULT_LED_PIN, GPIO_OUT); gpio_put(PICO_DEFAULT_LED_PIN, 0); gpio_init(WAKE_PIN); gpio_set_dir(WAKE_PIN, GPIO_IN); gpio_pull_up(WAKE_PIN); gpio_set_irq_enabled_with_callback(WAKE_PIN, GPIO_IRQ_EDGE_FALL, true, gpio_callback); idle_hook_t hook = { .on_enter = on_enter, .on_wakeup = on_wakeup }; idle_manager_init(); idle_manager_add_hook(&hook); while (true) { idle_manager_enter(); // 唤醒之后执行业务 busy_wait_us(1000); } }

这段代码可以直接编译运行，用杜邦线把 GPIO2 接到 GND，Pico 会立即醒来，LED 点亮一次。实测中，按键唤醒的响应延迟在微秒级别，体感上就是“按下就亮”，没有迟钝感。

3.4 唤醒源配置示例

除了 GPIO 边缘触发，另一种常用唤醒源是定时器。比如温度采集终端每隔 500ms 采样一次，中间空窗期全部用空闲模式填补：

void timer_wakeup_callback(void) { // 定时器中断服务函数，唤醒后进入 } void setup_timer_wakeup(void) { // 使用 repeating timer struct repeating_timer timer; add_repeating_timer_ms(500, timer_callback, NULL, &timer); }

需要注意，重复定时器每次触发都会产生中断，所以主循环里执行idle_manager_enter()后，最多 500ms 就会醒来一次。如果业务逻辑执行速度足够快，系统就始终处于“醒来处理一下，然后继续睡”的低功耗节奏中。

4. 功耗优化：同样一块板，电流差十倍的做法

4.1 关外设：别让空闲变成假空闲

WFI只停 CPU，不停外设。如果你进入空闲前，UART、ADC、PWM、DMA 全部还在跑，那功耗跟正常运行差的并不远。我见过一个同学低功耗做了半天，电流还在 20mA，最后发现是调试用的 USB 转串口模块一直在工作。

真正有用的一步，是在on_enter里把不参与本次待机的外设全部停掉。比如 ADC 采样完就执行：

adc_run(false); adc_hw->cs.en = 0;

PWM 有占空比输出的通道，如果不是故意保持输出，直接关闭输出让引脚回到低电平。UART 在待机期间没有收发需求，就复位发送逻辑，或者干脆在没有调试需求时关闭串口。

这里要强调一个 RP2040 的硬件特性：它不像有些高端的 MCU 那样按外设单元独立切clk_peri时钟，外设时钟是全局的，所以“关外设”主要靠的是让外设停止工作、停止输出翻转，而不是去切某个外设时钟。GPIO 不翻转、内部模块不跑，省下的动态功耗才是大头。

4.2 降时钟 vs 空闲模式

空闲模式下，如果中断到来很稀疏，可以考虑把系统时钟降下来。RP2040 默认跑 133MHz，需要高频是因为主循环里有大量实时运算；低频场景下其实 12MHz 甚至更低也够用。

我在一个传感器项目中这么干过：正常采集时用 133MHz，处理完数据后把系统时钟切到 12MHz 的内部振荡器，再执行__wfi()。12MHz 下即便被频繁唤醒，整体功耗也明显低于 133MHz 的空闲等待。切换时钟的代码用 SDK 的clock_configure接口，需要注意切换后重新校准串口波特率，否则打印会乱码。

不过降频不是越多越好，因为中断响应延迟会变长，而且部分外设对时钟有最低要求。比如 UART 波特率和 PWM 频率都跟clk_peri挂钩，降得太狠可能影响功能。我的建议是：先确认业务能接受的唤醒延迟，再决定降频幅度。

4.3 GPIO 浮空漏电的坑

这是一个很隐蔽但很常见的漏电路径。RP2040 的 GPIO 处于高阻输入状态时，如果没有外部上下拉，引脚电位会悬在中间，CMOS 输入级的两个管子可能同时导通，产生贯穿电流。

进入空闲之前，所有没接外设的 GPIO 都应该被明确设成一种确定状态。两种做法我都在用：

• 设成输出模式，并输出低电平。适合该引脚在待机期间没有电气需求的情况。
• 设成输入模式，并启用内部上拉或下拉。适合该引脚还可能被外部信号驱动的场景。

注意：如果 GPIO 外部已经接了上拉电阻或者传感器输出，不能盲目设成输出低电平，否则会产生外部短路电流。这一点要结合具体硬件原理图判断。

4.4 进阶：从空闲到 Sleep/Dormant

如果项目能接受秒级的唤醒延迟，就可以从空闲模式往下走。RP2040 的 SDK 里提供了pico_sleep相关的接口，比如：

• sleep_run_from_rosc()：从内部振荡器运行，省掉 PLL 和外部晶振功耗。
• sleep_run_dormant_until_edge_low(pin)：进入 dormant，等待指定引脚下降沿。
• RTC 定时唤醒：配合 RTC 设置，可以做到每天固定时间醒来。

Sleep 和 Dormant 的功耗比空闲模式低得多，但代价是唤醒后需要重新初始化 PLL、恢复外设状态，代码逻辑相对复杂。如果要兼顾低功耗和可维护性，我建议把“进入哪种低功耗态”也抽象成策略，由上层业务决定。

4.5 实测数据参考

我自己在几块板子上测过一组数据，环境是 5V 串接万用表，USB 未连接，板载 LED 关闭：

同样一块板子，从 24.6mA 降到 4.1mA，靠的就是“空闲模式 + 外设关闭 + 降频”这套组合拳。至于再往下，就得牺牲唤醒速度和使用便利性了。

5. 常见问题与排查技巧

5.1 一进 WFI 就被唤醒

这是最常遇到的问题。表现是调用idle_manager_enter()后，代码瞬间就往下走了，电流根本没降下来。

原因基本是：有某个中断源一直处于 pending 状态，或者被意外使能。常见嫌疑对象有：

• UART 接收中断：调试口连接上位机，上位机发了数据，RX 中断置起。
• 定时器中断配置成add_repeating_timer_ms，间隔太短，看起来就像“一直醒着”。
• USB 中断：stdio_init_all()使能 USB，USB 枚举中断频繁触发。
• GPIO 中断配置错误，电平触发且外部信号一直满足条件。

排查方法很简单：先把所有外设中断关掉，只保留你真正需要的唤醒源，然后逐个打开，观察是哪个中断导致立即唤醒。建议用irq_set_mask_enabled这类接口做全局控制，快速二分定位。

5.2 唤醒后外设不工作

唤醒后 UART 乱码、PWM 不输出、I2C 无响应，多半是on_enter里动了外设，但on_wakeup没有完整恢复。

比如我在一个项目里把 ADC 的时钟关闭，唤醒后只调用了adc_select_input而没有重新adc_run(true)，结果采样直接读到 0。后来我把“外设初始化”拆成两个子函数，一个hw_deinit负责关，一个hw_reinit负责开，并确保on_enter和on_wakeup严格配对。

如果涉及切换系统时钟，还需要注意唤醒后重新配置 PLL，并等待pll_is_locked，否则 CPU 可能以错误频率运行，最直观的表现就是串口波特率错乱。

5.3 功耗数据下不来

代码看着都关了，电流还是居高不下，这时候问题往往不在 MCU 本身，而在开发板外围。我踩过的坑按出现的概率排序：

1. 板载电源指示灯常亮：这是最容易被忽视的，一个高亮 LED 工作电流就有几毫安。
2. 电压转换芯片静态电流：很多开发板上的 LDO 本身就会吃掉几十到几百微安。
3. USB 接口上拉电阻：USB D+ 的上拉电阻只要还在使能，系统就很容易被外设识别为“在线设备”。
4. 外部传感器持续供电：传感器在工作，MCU 睡了也没用。低功耗设计一定要把传感器供电也纳入开关控制。

解决方式是：用杜邦线给 MCU 单独供电，或者把板上不必要的跳线断开，再用万用表串联测量。测量时把量程切到 µA 档，读数才有参考意义。

5.4 快速排查表

5.5 调用时机和编译器优化

高版本 Pico SDK 默认开了-O2优化，正常情况下不影响__wfi()的行为，但如果你在某些编译器上看到“WFI 立即返回”的问题，也可以检查一下唤醒源中断服务函数里是否有占用 CPU 过多的操作。WFI 唤醒后，中断服务函数会先执行，然后才回到idle_manager_enter()的下一行，这个执行顺序需要心里有数。

另外，如果代码使用了 FreeRTOS，不需要在任务里手动写__wfi()，FreeRTOS 自身的portIDLE钩子就能做到类似效果。如果你引入了 RTOS，这套idle_manager更多是作为应用层的电源策略模块，而不是系统节拍的替代品。

6. 把空闲模式扩展到整个低功耗框架里

前面的idle_manager只覆盖了空闲模式，真正做低功耗项目时，我会把这套设计继续往上扩展成一个power_manager模块，把 Sleep、Dormant 也统一进同一套回调框架。

具体思路是：把“低功耗层级”定义成枚举，例如：

typedef enum { POWER_LEVEL_ACTIVE, POWER_LEVEL_IDLE, POWER_LEVEL_SLEEP, POWER_LEVEL_DORMANT } power_level_t;

然后给每个层级都挂一组on_enter/on_wakeup回调。上层应用只需要根据自己的业务需求，声明“我这个阶段能忍多少毫秒的唤醒延迟”，电源管理模块就自动选择进入哪个层级。这样写出来的代码，换一个项目、换一块板子，基本只改配置文件，主体逻辑完全不动。

我最初只是想把按键唤醒这块代码整理一下，没想到后来在四五个项目里都用上了，省了非常多的重复劳动。回头再看，比“把 WFI 写在 main 里”这种野路子强太多了。

最后再分享一个小技巧：做功耗优化时，硬件测量和代码优化要同步进行。我第一次调低功耗，只顾着看代码逻辑，结果发现数据怎么都不对，后来把万用表串在电池端才发现，问题出在电源指示灯上。低功耗是系统工程，MCU 的空闲模式只是起点，整板的漏电路径才是真正决定续航的地方。