树莓派Pico ADC采集实战：定时温度记录与MicroPython避坑指南

手头一个开源硬件项目需要做环境温度记录，每隔十几秒采一次温度，存成日志。我翻了一圈手边的板子，最后选了树莓派 Pico。原因很直接：便宜、功耗低、MicroPython 生态成熟，而且 RP2040 片内带了一颗 12 位 ADC 和一颗内置温度传感器，完全不需要额外接模拟前端就能先把整个链路跑通。等项目做完，我也把 Pico 的 ADC 软件控制从头到尾摸了一遍，从machine.ADCAPI 的底层行为，到定时采集中断（ISR）里的各种翻车场景，踩了不少坑。这篇文章干脆把这些经验完整写出来，给正要上手 Pico 模拟量采集的朋友做个参考。

主线是"定时温度采集"，但我不打算只给一段能跑的代码就完事。ADC 的分辨率、参考电压、引脚限制、中断回调的禁忌、滤波和校准，这些才是决定一个采集项目能不能长期稳定跑的关键。无论你是刚拿到 Pico 的硬件新手，还是已经被读数漂移和中断死机折磨过的 MicroPython 开发者，这篇内容应该都有参考价值。

1. 方案设计与选型思路

1.1 先把需求拆开：这个项目到底要做什么

我给自己定的目标很朴素：做一个能长时间挂在角落里的温度记录仪，每 30 秒采集一次温度，写入 CSV 日志，断电后数据不丢。后续如果接了外部 NTC 热敏电阻，也要能直接读数并换算成温度。

拆解下来，整个系统其实只有三个核心环节：

• 用 ADC 把温度传感器的电压信号转换成数字量；
• 用定时器产生稳定的采样节奏；
• 在合适的位置做数据换算和日志落盘。

听起来很简单，但实际写代码时你会发现，这三个环节在"实时性"要求上是互相打架的。定时器回调里如果要换算浮点温度，必然占用中断时间；中断里如果要写文件，flash 写入的耗时和不确定性会让整个采集节奏乱掉。所以后面整套方案的核心，就是把这几个动作拆到合适的执行上下文里。

这也是我写这篇文章最想强调的一点：ADC 采集本身不难，难的是把它放进一个真实可用的工程结构里。

1.2 为什么用 MicroPython 而不是 C SDK

树莓派 Pico 官方主推 C/C++ SDK，性能上限高，ADC 采样率可以压到接近硬件极限。但对我这个温度记录仪来说，采样率要求不到 1Hz，C 语言带来的性能优势完全用不上。反而 MicroPython 的开发迭代速度快，USB 串口一开就能直接改代码跑，不用每次插拔烧录，对需要反复调公式的项目友好太多。

温度采集这类低速模拟量采集场景，MicroPython 的 API 抽象已经够用。官方固件里machine.ADC把底层寄存器操作封装得很干净，read_u16()和read_uv()两个方法覆盖了绝大多数需求。如果你的需求是需要跑到 100kS/s 级别的连续采样，或者要和 DMA 配合做高速波形采集，那确实得回到 C SDK。但那是另一个话题了，这篇文章先专注在软件控制逻辑上。

1.3 整体架构：一眼看清数据怎么流动

整个温度记录链路可以用一句话描述：定时器触发"采样标志位"，主循环看到标志位后执行 ADC 读取、温度换算、日志写入。

这个结构我用了一张非常简单的图表来理解，为了直观我画成了文字版本：

Timer 到期 -> 置 sample_flag = True | v 主循环检查 sample_flag -> 读取 ADC(4) -> 电压换算温度 -> 追加写 CSV 文件

关键在哪？ADC 读取和温度换算没有放在定时器回调里做。定时器回调只负责"喊一声该采样了"，实际采样动作放到主循环里完成。这样做的原因后面在 ISR 避坑部分会详细展开，这里先记住结论：MicroPython 的定时器回调不是让你干重活的地方。

2. RP2040 ADC 硬件底细与关键边界条件

2.1 ADC 通道分布与引脚限制

先看 RP2040 的 ADC 通道分布，这是很多人刚上手时最迷糊的地方。芯片内部有 5 个 ADC 输入通道，但对普通用户来说，实际能当外部模拟输入用的只有 3 个：

ADC3 是个典型的"看着能用，实际要绕开"的通道。在树莓派 Pico 官方板上，GP29 已经连接到 VSYS 的分压电阻网络，用来做供电电压监测。如果你直接拿它读外部模拟信号，读数里会叠加系统供电的直流分量，结果完全不可信。所以我建议：普通项目直接用 GP26、GP27、GP28 这三个通道，板上电压监测单独用ADC(4)的内置传感器，别去动 GP29。

另外一个小细节：machine.ADC构造函数传入参数时，内部实际上分不清你传的是"ADC 通道号"还是"GPIO 编号"。ADC(4)是芯片上的温度传感器通道，而ADC(26)指的是 GPIO 26，也就是 ADC0。要是你写成ADC(0)，MicroPython 会尝试把它当 GPIO0 使用，而 GPIO0 并不支持 ADC 功能，轻则报错重则读出来的数值完全无意义。我的习惯是统一用ADC(Pin(26))这种显式写法，可读性最好。

2.2 12 位分辨率与参考电压的坑

RP2040 的 ADC 核心是 12 位逐次逼近型（SAR）结构，理论上能分辨 4096 个数字台阶。MicroPython 的read_u16()返回的是 0 到 65535 的 16 位整数，这其实是把 12 位结果等比放大到 16 位范围，方便统一处理，并不代表底层精度变成了 16 位。

参考电压方面，Pico 板上没有独立的 VREF 引脚，ADC 直接使用 3.3V 电源作为满量程参考。这里有两个实际问题：

第一，USB 供电的 3.3V 没那么干净。USB 电压 5V 经过板载稳压器转换到 3.3V，负载变化时电压会有轻微波动，反映在 ADC 读数上就是最末尾几位在跳。对温度采集这种慢速场景，影响不大，但如果你要做电池电压监测、传感器信号精细测量，就会明显感觉到读数不稳。

第二，芯片出厂时 ADC 的增益和零偏并不完美。数据手册上写了典型误差参数，不同芯片之间也有个体差异。我在实际测试中拿同一块 Pico 读内置温度传感器，不同板子之间温度显示能差 2 到 3 摄氏度，这就是未校准的典型表现。后面第 6 章会讲怎么用软件校准来弥补。

2.3 输入阻抗、分压电阻与滤波电容

内部 SAR ADC 采样瞬间会从外部电路抽取一个瞬态电流。如果信号源阻抗太高，电荷来不及补充，采样结果就会偏低。RP2040 的数据手册建议信号源阻抗尽量低，但微控制器内置 ADC 在这方面通常都不算特别宽松。

实际项目里最常见的场景是接 NTC 热敏电阻或电位器，外围必然有分压电阻。分压电阻一选就是 100k 级别的话，ADC 读数会明显偏低且跳动。我在 NTC 温度采集里踩过这个坑：刚开始选了 100k 固定电阻，常温下读 NTC 分压，和万用表实测比低了近 30mV，换算成温度偏差好几度。后来把分压电阻降到 10k，再接一个 100nF 电容并到 ADC 引脚对地，读数立刻稳定下来。

给 ADC 输入引脚并一个小电容，相当于加了个低通滤波器，能有效抑制高频噪声。我在所有模拟输入脚上都并了 100nF，效果很明显。如果信号变化很快，电容会拖慢响应，但对温度这种慢变信号完全不是问题。

3. machine.ADC API 用法详解

3.1 构造函数与一次最基本的读取

MicroPython 里创建 ADC 对象有几种写法，我直接把最常用的贴在下面：

from machine import ADC, Pin # 方式一：传入 Pin 对象，最推荐 adc0 = ADC(Pin(26)) # 方式二：直接传入 GPIO 编号 adc0 = ADC(26) # 方式三：读取内置温度传感器 sensor_temp = ADC(4) # 读取原始值（16 位范围 0-65535） raw = adc0.read_u16() print(raw) # 读取换算后的微伏值 voltage_uv = adc0.read_uv() print(voltage_uv)

read_u16()和read_uv()是machine.ADC最常用的两个方法，前者对小白友好，后者对精度敏感场景更合适。初次接触的人容易忽略一个细节：ADC(Pin(26))创建对象后，GPIO 会自动从普通数字 IO 切换到 ADC 模拟输入功能。如果在这之前你手动把Pin(26, Pin.OUT)设为输出，一定要重新ADC(Pin(26))或执行Pin(26).init(Pin.IN)复位引脚功能，否则后面读到的数值会异常。

3.2 read_u16 和 read_uv 到底怎么选

read_u16()返回 0 到 65535 的整数，它是把底层 12 位 ADC 结果线性映射到 16 位整数空间。如果你想自己换算电压，可以直接拿 65535 当满量程：

voltage = raw / 65535 * 3.3

read_uv()直接返回微伏单位（1 微伏 = 0.000001 V）的整数值。从 API 设计角度看，read_uv()是更高级的封装，它内部会考虑到 ADC 参考电压的具体值，免去了你手动换算可能引入的缩放误差。在 RP2040 移植的官方固件里，read_uv()还会尽量利用芯片的校准信息，比单纯拿 3.3V 当参考电压算，结果更贴近真实电压。

所以我自己的原则是：

• 只是判断有没有电压、需要大致读数的，用read_u16()够了；
• 要做温度、电压这些需要精确物理量的，直接用read_uv()先拿电压，再套物理公式。

这样代码里少一步换算，逻辑也更清楚。

3.3 用内置温度传感器做第一次验证

Pico 内置温度传感器挂在 ADC4 通道上，不需要外接任何元件。官方给出的电压-温度关系是：

temperature = 27 - (voltage - 0.706) / 0.001721

其中voltage单位是伏特，公式的意思是：0.706V 对应 27 摄氏度，温度每升高 1 摄氏度，输出电压降低约 1.721mV。写个完整循环：

import machine import time sensor_temp = machine.ADC(4) while True: voltage = sensor_temp.read_uv() / 1_000_000 # 转换成伏特 temperature = 27 - (voltage - 0.706) / 0.001721 print("voltage={:.3f} V, temp={:.1f} C".format(voltage, temperature)) time.sleep(2)

这是我建议每个人都先跑一遍的验证程序。它能帮你确认固件、板子、ADC 链路是否正常，同时建立对read_uv()和公式换算的直接感知。板子上电后温度传感器读出来的值通常比室温偏高几度，因为芯片本身在发热，属于正常现象，不用慌。

4. 定时温度采集完整实战

4.1 用 Timer 搭出稳定的采样节拍

定时采集最直接的做法是用machine.Timer产生周期性回调。基础用法：

from machine import Timer timer = Timer() timer.init(period=30000, mode=Timer.PERIODIC, callback=timer_handler)

period单位是毫秒，mode设为Timer.PERIODIC表示每个周期都会触发，回调函数timer_handler会被周期性调用。Pico 的 MicroPython 固件对软件定时器支持得不错，你可以创建多个 Timer 实例分配不同的周期。

对于温度记录这种低频任务，30 秒甚至 60 秒采样一次即可。这个周期下，主循环即使偶尔被别的任务阻塞一两百毫秒，也不会影响整体节奏。反而是那种"回调里直接做所有事"的写法，看着简单，一旦插入耗时操作，回调执行时间过长会直接影响下一次定时触发，积累下来定时就失真了。

4.2 标志位加主循环：最稳的配合方式

我推荐的模式是，定时器回调里只置一个标志位，真正的采集和换算在主循环里做：

from machine import Timer, ADC import time sensor_temp = ADC(4) sample_flag = False def timer_handler(timer): global sample_flag sample_flag = True timer = Timer(period=30000, mode=Timer.PERIODIC, callback=timer_handler) while True: if sample_flag: sample_flag = False # 先清位，再干活 voltage = sensor_temp.read_uv() / 1_000_000 temperature = 27 - (voltage - 0.706) / 0.001721 print("time={}, temp={:.2f} C".format(time.time(), temperature))

为什么说这样"最稳"？因为 MicroPython 是运行在嵌入式环境里的解释器，定时器回调本质上是中断上下文。中断上下文里不适合处理耗时操作，这个是所有嵌入式程序员的共识，原因我在第 5 章详细展开。

这里还有个容易忽略的细节：进入if sample_flag后第一件事就是清标志位。如果先采集再清标志，万一采集过程比较长，下一次定时器回调又触发，设置了一个新的标志位，主循环处理完上一轮后会立刻再跑一轮，逻辑上没问题，但读起来容易混乱。先清位再干活，可以确保每一轮采集对应一次定时器触发，时序更干净。

4.3 把采样数据稳定写入日志文件

采集只是前半部分，日志落盘才是记录仪的核心需求。MicroPython 中直接操作文件系统用内置的open()就行：

from machine import Timer, ADC import time sensor_temp = ADC(4) sample_flag = False LOG_FILE = "temp_log.csv" def timer_handler(timer): global sample_flag sample_flag = True def read_temperature_c(): voltage = sensor_temp.read_uv() / 1_000_000 return 27 - (voltage - 0.706) / 0.001721 def append_log(temp_c): with open(LOG_FILE, "a") as f: f.write("{},{:.2f}\n".format(time.time(), temp_c)) timer = Timer(period=30000, mode=Timer.PERIODIC, callback=timer_handler) print("Temperature logger started, press Ctrl+C to stop.") while True: if sample_flag: sample_flag = False temp = read_temperature_c() append_log(temp) print("time={}, temp={:.2f} C".format(time.time(), temp))

打开文件的模式用了"a"，即追加模式，每次写入新的一行，不会覆盖之前的记录。日志格式是timestamp,temp两列，之后用任何表格软件都能导入。

你可能会问，每次采样都打开和关闭文件，会不会太频繁？对 30 秒一次的采集来说完全没问题。但如果后面的需求变成 1 秒采 10 次，我建议改成"每积累 10 条或 20 条，集中写入一次"，减少 flash 写入次数，延长存储寿命。这个优化很简单，在内存里维护一个列表，凑够数量后再一次性写入。

4.4 外接 NTC 热敏电阻怎么读数

内置温度传感器是芯片温度，不等于环境温度。真要测环境温度，外接 NTC 热敏电阻是最常见的低成本方案。电路上用一只固定电阻与 NTC 串联形成分压，ADC 读分压点电压：

from machine import ADC, Pin from math import log BETA = 3950 R_REF = 10000 # 固定电阻，单位欧姆 T0_K = 298.15 # 25 摄氏度对应的开尔文温度 adc = ADC(Pin(26)) voltage = adc.read_uv() / 1_000_000 # 当 NTC 接在下方、固定电阻接在 3.3V 和采样点之间时： r_ntc = R_REF * voltage / (3.3 - voltage) # 用 Beta 公式计算温度 temp_k = 1 / (1 / T0_K + log(r_ntc / R_REF) / BETA) temp_c = temp_k - 273.15 print("NTC temp: {:.2f} C".format(temp_c))

Beta 公式是从 25 摄氏度基准点推算温度的经典方法，精度对大多数场景足够。要注意的是分压电路连接方式：如果 NTC 在下方，采样点电压随温度升高而升高，公式如上；如果 NTC 在上方，采样点电压随温度升高而降低，r_ntc的计算公式要反过来。

电阻选型上，固定电阻别选太大。我一开始用 100k，读数很不稳定，后来换 10k 固定电阻，加上 100nF 滤波电容，读数立刻干净了很多。原因就是 SAR ADC 的输入阻抗问题，前面硬件部分已经解释过。

5. ISR 避坑指南：这些坑我替你踩过了

5.1 Cortex-M0+ 的浮点短板决定了中断写法

树莓派 Pico 的主控 RP2040 是双核 ARM Cortex-M0+。这里有个很关键的硬件事实：Cortex-M0+ 没有硬件浮点单元（FPU），MicroPython 的浮点运算是纯软件模拟，而且用的是双精度 float。这意味着一次简单的温度换算27 - (voltage - 0.706) / 0.001721，在中断回调里执行要比你想象中慢得多。

我实际测试过，在定时器回调里连续做 10 次浮点运算，中断处理时间会明显拉长。如果是低频采集，你可能感知不到；但如果把周期缩短到 10 毫秒，中断占用时间占比上升，主循环卡顿、定时漂移就会接踵而至。

所以最直接的建议是：中断回调里不要做浮点运算，不要做温度换算。把一切重计算都放到主循环。这是 ISR 避坑的第一条铁律。

5.2 中断回调里的禁忌清单

结合我的使用经验，整理了一份 MicroPython 环境下 ISR 回调的禁忌清单，按重要程度排序：

• 不要调用print()。print要经过 USB CDC 串口输出，整个过程是阻塞式的，在中断上下文里执行轻则拖慢系统，重则导致回调卡死、看门狗超时，表现就是程序突然"假死"。这是新手最容易踩的坑，因为写着写着总想打印点东西看看。
• 不要做内存分配。在中断里创建列表、拼接字符串、调用append，都会触发内存堆操作。MicroPython 的官方文档明确建议中断处理程序里避免分配内存，否则可能触发垃圾回收（GC）在中断上下文执行，引发奇怪的问题。
• 不做文件 I/O。打开文件、写入文件是耗时操作，flash 写入时间不可控，绝对不应该出现在中断回调里。
• 不要做浮点计算。前面已经详细说了原因，这里再强调一次。
• 不要调用会长时间阻塞的库函数。比如网络请求、time.sleep()这类，一定不要出现在回调里。

那中断回调里到底能做什么？只能做最轻量、最确定的事，比如置一个标志位、翻转一个 LED、修改一个整数变量。仅此而已。

5.3 我在实际项目里碰到过的两起事故

第一起是我在定时器回调里直接放了一段print加温度读取的代码，本来想着 30 秒才跑一次，应该没事。跑了半天，USB 串口突然无响应，代码看起来像卡死了一样。拔掉电源重新上电才恢复。

排查下来原因就是print在中断上下文里执行，USB 输出和回调互相抢占，最终把系统拖进了不可恢复的阻塞状态。从那以后，我所有中断回调里再也不出现print。

第二起是我把一个温度转换公式直接写在了回调里：

# 反面教材，别这么写 def timer_handler(timer): voltage = sensor_temp.read_uv() / 1_000_000 temp = 27 - (voltage - 0.706) / 0.001721 log_list.append(temp)

这段代码的问题不是跑不了，而是每次回调执行时间长达几十毫秒，而且频繁触发 GC。我把采样周期从 30 秒调到 100 毫秒测试时，主循环的响应几乎停顿，连 LED 闪烁都变得一顿一顿的。改成标志位模式后，问题迎刃而解。

5.4 如果坚持要在中断里做处理，有没有折中方案

有些场景确实要求在中断里快速响应外部事件，比如检测到 GPIO 边沿立刻做保护动作。这时候我的建议是：

• 中断里只记录核心数据，比如把 ADC 原始整数读取存到全局变量；
• 把标志位置起来；
• 主循环里集中处理所有后续逻辑。

如果数据量比较大，可以考虑用bytearray这种预分配好的固定缓冲，在中断里往缓冲区写入数据，不触发新的内存分配。这个思路在 MicroPython 里完全可行，但复杂度会上来。对温度采集这种需求，老老实实用标志位加主循环就够了，没必要给自己加戏。

6. 读数波动与精度问题排查

6.1 常见问题速查表

我把自己和周围朋友在 Pico ADC 采集上遇到的问题汇总成了一张表，基本覆盖了新手阶段 90% 的异常现象：

6.2 三个简单好用的滤波方法

ADC 原始读数总会有噪声，下面三个滤波方法不需要任何库，两三行代码就能实现。

滑动平均是最简单的方法：连续采 N 次取平均。N 越大越平滑，但响应变慢。对温度采集，N 取 10 到 20 就很舒服：

def read_adc_averaged(adc_obj, n=10): total = 0 for _ in range(n): total += adc_obj.read_u16() time.sleep_ms(2) return total // n

中值滤波适合剔除偶发尖峰干扰：采 3 到 5 次，取中间值。如果信号本身噪声不大，只是偶尔出现明显异常值，中值滤波比平均更合适。

限幅滤波则是从物理常识出发：温度不可能在瞬间跳变 5 度。如果当前读数与上一次相差超过阈值，就认为这次是干扰，丢弃或采用上一次值。这三个可以组合使用，先用滑动平均压掉随机噪声，再用限幅滤波拦截异常跳变，实测效果非常稳。

6.3 温度偏移的校准技巧

内置温度传感器的公式来自 RP2040 数据手册的典型值，但每颗芯片的实际曲线存在个体差异。如果对绝对温度精度有要求，建议做一次简单的两点校准：

先用冰水混合物做一个接近 0 摄氏度的参考点，再测一个接近室温的参考点（用精度的温度计做基准）。然后计算实际读数与参考温度之间的偏移量，在最终结果上加上这个 offset：

# 假设用标准温度计读出当前环境为 26.4 C # 而内置传感器连续读数稳定在 28.9 C OFFSET_C = 26.4 - 28.9 # 这里等于 -2.5，最终要减去 2.5 度 corrected_temp = raw_temp + OFFSET_C

用偏移量校准后，绝对精度能改善不少。更讲究的做法是拟合增益和零偏两个参数，但对温度记录仪来说，一个 offset 足够用了。

采样频率、滤波参数、校准偏移量，这几个参数建议根据自己项目的实际情况调整，不要照搬我的数值。我给的是一套工作方法，不是唯一答案。

这篇文章从 Pico 的 ADC 硬件边界讲到了machine.ADCAPI 的具体用法，又用定时温度采集串起了完整工程实践，最后把 ISR 里的坑和滤波校准技巧都过了一遍。我个人在实际操作中体会最深的一点是：嵌入式开发的很多 bug 不是功能实现不了，而是把代码放错了执行上下文。一个问题放在主循环里可能很简单，放进中断回调里就成了系统崩溃的隐患。写 ADC 采集代码时，先想清楚每个动作应该发生在哪个上下文，比急着写通功能更能节省后面的调试时间。

最后再分享一个小技巧：调试 ADC 程序时，别光看打印值，多拿万用表实测引脚电压，和read_uv()的返回值对一下。两边对不上，最快的排查方向就是分压电阻阻值和参考电压稳定性这两个点。把这条习惯养成，模拟量采集这条路基本就稳了。