串口通信这四个字，在嵌入式项目里几乎天天被挂在嘴边。Pico 作为一块几十块钱的开发板，UART 资源虽然不算多，但足够应付绝大多数传感器、串口屏、舵机控制板和数据采集场景。我最早接触 Pico 串口的时候，以为只是发个字符串的事，结果被电平转换、波特率误差、数据粘包挨个锤了一遍，才把通信调稳定。这篇文章不打算从零讲晶体管电平，而是把所有和 Pico 串口实战相关的硬件细节、MicroPython 编程写法、调试工具用法直接摆出来，帮你跳过我已经走过的弯路。不管你是刚拿到板子的新手，还是正在做项目的开发老手，这篇内容应该都能给你省下几个调试的夜晚。
我在写这篇内容时，参照了身边好几个真实项目的经验，也把社区里讨论比较多的串口问题整理了进来。整体思路是：先讲硬件选型和接线，再讲 MicroPython 里怎么写代码，接着是调试工具怎么选怎么用，最后是一份排查实录。每部分尽量说人话，把“为什么这么做”也交代清楚。
1. 串口通信在 Pico 项目里的定位
1.1 为什么是串口，而不是 I2C 或 SPI
很多刚接触 Pico 的朋友会问我：需要通信的时候，到底选串口 UART、I2C 还是 SPI？简单说，I2C 和 SPI 都是板级总线，适合芯片与芯片之间短距离、高速率传输；而 UART 是设备与设备之间最通用的通信方式，不需要时钟线，两根信号线就能跑，大量外设模块——GPS、指纹模块、激光雷达、串口屏、舵机驱动板——默认都是 UART 接口。所以 Pico 上做项目，往外接的第一种通信大概率就是串口。
UART 通信的原理不复杂：发送方把并行数据转成串行位流，按约定的波特率、数据位、校验位、停止位逐位发送；接收方在正确的位时间上采样，把位流重新拼成字节。它没有时钟线，所以收发双方必须提前约定好“节奏”，这也是为什么串口调试里波特率一旦出错，就会完全收不到数据。
1.2 适用场景与常见项目形态
在我接触到的实际项目里，Pico 串口通信大概有这几种典型形态：
- 传感器数据采集上传：Pico 读取温湿度、气压、IMU 等数据，通过 UART 发给上位机显示或存档。
- 设备控制：上位机通过串口下发指令，Pico 解析后控制舵机、电机、LED，很多机器人项目就是这种架构。
- 模块对接：接串口屏、GPS、蓝牙模块、4G 模组，这类模块本身只暴露 UART 接口。
- 调试信息输出：把 Pico 运行状态打印到串口终端，方便实时观察变量和程序执行流程。
这些场景和我早期做 51 单片机串口通信、STM32 串口通信实验时用的思路是相通的，但 Pico 的 MicroPython 环境让原型开发速度快不少，不用管寄存器配置，一行UART(0, baudrate=115200)就把外设打开了。对于需要快速验证方案的项目，这种开发效率优势非常明显。
2. Pico 的 UART 硬件特性与接线
2.1 UART0、UART1 外设资源与引脚映射
RP2040 芯片内部只有两个 UART 外设：UART0 和 UART1。每个 UART 在物理上可以映射到多组引脚，MicroPython 对 Pico 官方保留了默认映射：
- UART0：TX = GP0，RX = GP1（默认）
- UART1：TX = GP4，RX = GP5（默认）
这里要注意一点：默认映射只是 MicroPython 的约定，你完全可以通过tx=Pin(x), rx=Pin(y)指定其他引脚。但 UART0 和 UART1 在 RP2040 上挂了不同的引脚组，具体哪些引脚能映射到哪个 UART，建议查官方 datasheet 的 GPIO 功能表。我在实际项目里习惯固定使用默认引脚，方便查阅和复用，除非用到的别的引脚被其他外设占用才会重新映射。
每个 UART 还支持硬件流控 RTS/CTS，在 Pico 上默认没暴露，如果接的是带流控的模块（比如某些蓝牙模组），需要确认固件和引脚是否支持。大多数场景用不到流控，把 TX、RX、GND 三根线接好就能跑。
2.2 电气特性：3.3V 电平与"魔改 5V 串口"的风险
这是 Pico 串口通信最容易出问题的地方。Pico 的 GPIO 是 3.3V 电平，忍耐输入极限大约是 3.6V 左右。很多传统串口设备是 5V TTL 电平，比如老一点的 GPS 模块、51 单片机扩展板、某些 STM32 开发板上的 5V 串口。如果你直接拿 5V 设备的 TX 接到 Pico 的 RX，长期使用有烧坏引脚的风险。
我见过不少人图省事，直接接上去“能用”，然后某天引脚就废了。正确的做法是加电平转换芯片，比如 TXS0108E、BSS138 双 MOS 方案，或者用电阻分压把 5V 降到 3.3V 再接 Pico。反过来，Pico 的 TX 接 5V 设备的 RX 一般问题不大，因为很多 5V 设备把高电平阈值设在 2.0V 以上，3.3V 也能识别，但最好也做转换，保证电平标准一致。
如果接的是 RS232 电平的 DB9 串口，那就更危险了。RS232 的空闲态是负电压，正负摆幅能达到 ±12V 左右，直接接 Pico 基本必烧。这时候必须用 MAX3232 这一类的 RS232 转 TTL 芯片做转换。我常跟身边的人说：接串口先看对方是 TTL 还是 RS232 电平，再看逻辑电平是 3.3V 还是 5V，这两个判断能避开 90% 的接线问题。
2.3 多串口扩展与 USB 转串口接线参考
Pico 原生只有两个 UART，如果项目里需要更多串口，有几条路可以走：
- 用 PIO 实现软件串口。RP2040 的 PIO 非常灵活，社区有人实现了 PIO UART，可以扩展出多个串口，但 CPU 占用和稳定性需要测试。
- 用 I2C 转 UART 芯片，比如 SC16IS752，把额外串口挂到 I2C 总线上，代码里通过驱动读写。
- 某些社区固件开始支持 USB Host，接上 USB 转串口适配器就能多出串口。这个方案依赖固件成熟度，稳定性需要自己验证。
在做 Pico 和电脑通信时，常用 USB 转 TTL 模块（CH340、CP2102、FT232 等）把 Pico 的 UART 接到电脑 USB 口。接线就三根线：Pico 的 TX 接模块的 RX，Pico 的 RX 接模块的 TX，两边 GND 共地。注意共地这件事特别重要，不共地的话信号电平没有参考点，经常出现时通时不通的问题。
3. MicroPython 串口编程实操
3.1 固件准备与开发环境
要在 Pico 上跑 MicroPython，先得把固件刷进去。去官方下载最新的 .uf2 固件，按住 Pico 板子上的 BOOTSEL 键插入 USB，会弹出一个名为 RPI-RP2 的 U 盘，把 .uf2 文件拖进去就自动刷好了。之后用 Thonny 作为 IDE 比较省心，它对 Pico 的支持很完善，可以直接在编辑区写代码，点运行就能在板子上执行，还能在下方 Shell 里看 print 输出。
当然，如果你不喜欢 Thonny，也可以用 VS Code 加 MicroPico 插件，或者在命令行直接用 mpremote 连接设备执行脚本。我个人调试串口时用 Thonny 比较多，因为它内置的文件管理方便，修改main.py后按 Ctrl+D 软复位就能生效。
3.2 UART 对象初始化：参数到底怎么选
MicroPython 里初始化 UART 的代码很简单：
from machine import UART, Pin # UART0，TX=GP0, RX=GP1，默认引脚 uart0 = UART(0, baudrate=115200, tx=Pin(0), rx=Pin(1), bits=8, parity=None, stop=1)这几个参数中，baudrate 是最需要对齐的，两侧必须一致。bits 一般选 8，parity 为 None，stop 为 1，这也是绝大多数串口设备的默认配置。如果连接的是老设备或者特殊模块，需要看对方手册确认是否用了 7 位数据位、偶校验或者 2 位停止位。如果两侧参数不一样，能收到数据但解出来的字节是错的。
有一点要提醒：UART(0, ...)这种写法在创建时就会初始化外设，所以不需要再调用init()。如果你后面想改参数，可以调用uart0.init(baudrate=9600)重新配置，外设不用重新创建。
3.3 基本收发：write/read/readline 的正确用法
MicroPython 的 UART 对象主要有这几个方法：
write(data)：发送数据，data可以是 bytes 或 str。read(n)：读取最多 n 个字节，不加参数则读取全部可读数据。readline()：读取一行，以换行符结束。any()：返回接收缓冲区中的字节数，可用来判断是否有数据。
一个轮询收发的例子：
from machine import UART, Pin import time uart = UART(0, baudrate=115200, tx=Pin(0), rx=Pin(1)) while True: if uart.any(): data = uart.read() print("recv:", data) uart.write(b"echo: ") uart.write(data) time.sleep_ms(10)这里我习惯把any()放在主循环里轮询，最简单的场景够用。但要注意read()读取的内容可能不是完整的一帧数据，如果上位机一次发来多个字节，可能被拆成两次读出，所以最好按协议帧来解析，而不是直接判断“读到了就是一条完整指令”。这个后面会展开讲。
3.4 按行解析协议：以串口控制舵机为例
用 Pico 控制舵机是很常见的入门项目，很多朋友做机械臂、云台都会用到。串口控制舵机的思路是：上位机通过 UART 发来类似#90\n的指令，Pico 解析出角度值，再通过 PWM 输出控制舵机转到对应角度。
舵机 PWM 信号周期一般用 20ms（50Hz），高电平脉冲宽度 0.5ms~2.5ms 对应 0°~180°。Pico 的 PWM 模块是 16 位的，要算占空比。
from machine import UART, Pin, PWM import time uart = UART(0, baudrate=115200, tx=Pin(0), rx=Pin(1)) servo = PWM(Pin(15)) servo.freq(50) def angle_to_duty(angle): # 0.5ms / 20ms = 2.5% -> 65535 * 0.025 = 1638 # 2.5ms / 20ms = 12.5% -> 65535 * 0.125 = 8192 return int(1638 + (angle / 180.0) * (8192 - 1638)) while True: if uart.any(): line = uart.readline() if line: line = line.strip() print("cmd:", line) if line[:1] == b'#': try: angle = int(line[1:]) angle = max(0, min(180, angle)) servo.duty_u16(angle_to_duty(angle)) uart.write("OK angle=%d\n" % angle) except ValueError: uart.write("ERR bad number\n") else: uart.write("ERR unknown cmd\n") time.sleep_ms(10)这里有两点经验：
第一，解析协议时一定要做异常处理。串口本质上是不可靠信道，什么乱七八糟的字节都可能收到，如果int()转换失败没有处理，程序很容易崩在解析处。
第二，用readline()按行解析时，协议里的换行符必须和发送方保持一致。如果上位机发的是\r\n，Pico 这边可以先用line.replace(b'\r', b'')清理一下再做解析，否则b'90\r'转 int 会报错。
3.5 使用 IRQ 和 FIFO 处理不定长数据
在实时性要求高的项目里，主循环轮询any()可能不够及时。Pico 的 MicroPython 固件支持 UART 的 IRQ 中断，可以用uart.irq(trigger=UART.RX_ANY, handler=on_rx)注册回调函数，数据到达时自动触发。
from machine import UART, Pin import time uart = UART(0, baudrate=115200, tx=Pin(0), rx=Pin(1)) rx_buf = bytearray() def on_uart_rx(u): while u.any(): rx_buf.append(u.read(1)[0]) uart.irq(trigger=UART.RX_ANY, handler=on_uart_rx)使用中断时要注意：回调函数里不要做耗时操作，比如打印、大量字符串拼接、网络请求，这些都应该放到主循环处理。中断里只负责把数据快速搬进缓冲区，然后在主循环里检查缓冲区，解析完整帧。
如果数据量很大，比如每秒几千字节，bytearray 的append效率也够用，但要注意缓冲区长度。MicroPython 在 Pico 上给 UART 分配了 FIFO 和缓冲区空间，处理不过来时数据会丢，所以协议设计上最好有帧头、帧长、校验和，解析失败就丢弃重新同步。
3.6 与宿主机联动：Windows 下用串口连接 VMware 中的 Linux
这个需求在调试场景里很常见。比如你的上位机跑在 Windows，但编译和测试程序在 Linux 虚拟机里，想让虚拟机里的 Python 直接访问 Pico 串口。
在 VMware 里，可以给虚拟机添加一个串行端口，选择“使用命名管道”，例如：
\\.\pipe\com_1然后在 Windows 宿主机上用一些工具把物理 COM 口转发到这条命名管道，这样虚拟机里的 Linux 看到的/dev/ttyS0就对应着 Pico。也可以在宿主机上用 Python 的 pyserial 写个十几行的转发脚本，把串口字节流原样搬到管道另一端。这种方式比每次都在 VMware 里单独映射 USB 设备要灵活，尤其当 Pico 不是 USB 直接连接而是通过 USB 转 TTL 模块接入时。
如果不想用虚拟机，直接在 Windows 上用 pyserial 读取 Pico 串口数据也很方便。安装好 pyserial 后，一行代码就能列出可用串口：
import serial.tools.list_ports for p in serial.tools.list_ports.comports(): print(p.device, p.description)Windows 下 Pico 的 USB 转串口设备通常显示为 COM3、COM5 之类的编号，具体是哪个可以用这个列表确认。
4. 调试工具选型与实战技巧
4.1 串口调试助手怎么选
串口调试助手的工具很多，我用过的场景里比较顺手的有：
- PuTTY：老牌终端，支持串口连接，界面朴素但稳定，适合纯文本收发。
- sscom：经典的串口调试助手，界面友好，支持定时发送、十六进制显示、文件发送。
- VOFA+：带波形显示，看传感器的连续数据流非常方便，可以自定义协议。
- minicom/picocom：Linux 终端下的串口工具，适合在虚拟机或树莓派上直接调试。
选工具的标准在我看来有两个：一是能不能方便地切换十六进制/ASCII 显示，二是能不能定时发送和保存日志。这两点决定了你在解析复杂协议时能不能快速定位问题。
这里还要提一下 Unity 串口通信的场景。如果你用 Unity 做上位机读取 Pico 数据，不要在 Unity 的主线程里直接读写 SerialPort 的ReadLine()或者长时间阻塞等待，否则 Unity 的渲染线程会被卡住，严重时会出现类似渲染管线异常之类的报错。正确做法是开一个后台线程读串口，把数据放入队列或共享变量，主线程在Update()里取数据，这样画面才不卡，串口读写也更稳定。
4.2 逻辑分析仪是排查串口问题的神器
很多时候软件看起来没问题，但就是收不到数据。这时候我最推荐的调试工具是逻辑分析仪。我手里一直放着 Saleae 逻辑分析仪的 16 通道版本，平时接上 TX、RX、GND 三根线，在软件里选择 UART 解码协议，设置好波特率，就能看到波形和解析出来的数据帧。
逻辑分析仪能帮你确定三件事：
- 发送端到底有没有在发数据，波形上有没有脉冲。
- 数据的内容是什么，和发送的字节是否一致。
- 实际波特率和设置的波特率有没有偏差。
解码时要注意采样率至少要高于波特率的 4 倍，否则采样点不够容易解码出错。我通常用 10M 采样率去测 115200 的串口，非常充裕。如果买的是其他品牌，只要软件支持 UART 协议解码，用法都差不多。
4.3 虚拟串口与自动化测试
在调试上位机程序时，把真实硬件和软件耦合在一起有时候很痛苦。比如想测试协议解析逻辑，但硬件还没到位。这时可以用虚拟串口工具，比如 com0com 在 Windows 上创建一对虚拟 COM 口，把 COM5 和 COM6 连在一起，一个程序往 COM5 写数据，另一个程序就能从 COM6 读到相同的数据。
由此可以搭一套自动化测试环境：用 Python 脚本模拟设备端，向虚拟串口发送预定好的测试帧，同时校验上位机返回的应答。跑回归测试时不用真实硬件，效率高很多。等到真实硬件到位后，把串口名换掉就能跑同样的测试用例。
如果是在 Linux 下，虚拟串口可以用socat -d -d pty,raw,echo=0 pty,raw,echo=0创建一对伪终端，用法类似。
4.4 用 Modbus/Python 脚本扩展调试能力
串口调试不只限于收发数据。很多工业传感器、电表、道闸控制器用的是 Modbus RTU 协议，这时候用串口调试助手直接发 Modbus 帧也能调，但效率很低。我一般会用 Python 的minimalmodbus或pymodbus库，直接按寄存器地址读写，调试起来清晰很多。
其实不只是 Modbus，任何自定义协议都可以用 Python 脚本做上位机模拟。比如先用 pyserial 写好数据帧封装、CRC 校验、发送重试逻辑，再配合日志功能，就能快速验证 Pico 端协议解析的边界条件。这种脚本后期还能直接转成正式的上位机程序雏形，省不少开发时间。
5. 常见问题与排查实录
5.1 波特率：9600 能通、4800 不通是怎么回事
有朋友遇到过串口波特率设置为 9600 能正常通信，但改成 4800 就完全没有数据的情况。这个现象往往不是“波特率越低越容易通”这个直觉能解释的，根源在于两侧的实际波特率误差。
UART 是异步通信，接收端通过起始位同步后，在每一个位时间的中心点采样。如果实际波特率和设置值之间存在偏差，累积到帧末的停止位时偏差会越来越大。绝大多数 UART 外设能容忍大约 ±2%~3% 的波特率误差。如果 A 设备实际波特率是 9615，B 设备按 9600 收，误差只有 0.15%，没问题；但如果把 B 设备设成 4800，A 设备仍按 9600 发，位采样点完全错位，自然收不到。
另一种常见情况是，两块板子都声称是 4800，但其中一块用了精度不高的时钟源，或者代码里波特率计算有误，导致实际差距超过容差。Pico 的时钟来自 USB PLL，精度很高，不大会出现这种问题；但如果你接的模块内部是 RC 振荡器，就有可能出现“9600 能通、4800 不能通”的反直觉现象。解决办法是用逻辑分析仪实测一下发送端波形的实际波特率，或者降低通信速率到一个双方都真正支持且误差足够小的值。
5.2 乱码、丢字节与缓冲区溢出
乱码最常见的原因就是收发双方波特率或数据格式不一致。先确认两侧的波特率、数据位、停止位、校验位完全一致。其次检查共地，GND 不连时信号电平没有参考点，容易出现随机乱码和间歇性丢字节。
丢字节则多半和接收端处理速度有关。如果上位机 600ms 才读一次串口，而 Pico 以高速率持续发送，缓冲区一旦溢出，新的数据就会覆盖旧数据。MicroPython 的 UART 内部有缓冲区，在 Pico 上一般有 256 字节左右，如果你用read()一次性读完还好，但若没有及时读取，FIFO 满了之后数据就丢了。
我习惯的做法是：协议帧尽量短，或者发送端加适当延时；接收端用中断或高频轮询尽快把数据搬到自己的解析缓冲区；同时给每帧数据加上校验和或 CRC，解析失败就丢弃重发。工业上常用的做法是帧头加长度加数据加 CRC32，虽然看起来有些冗余，但在真实环境中非常有价值。
5.3 收不到数据：从硬件到软件逐步排查
收不到数据时，别急着改代码，按下面这个顺序排查最快：
- 用逻辑分析仪看 Pico 的 TX 引脚到底有没有波形。如果没有，说明代码没发出去，或者引脚接错。
- 检查接线是否交叉。Pico 的 TX 要接对方设备的 RX，Pico 的 RX 要接对方设备的 TX。很多人把 TX-TX 直连，自然收不到。
- 确认共地。GND 不接或者接触不良，信号电平没有参考，收不到是常见现象。
- 用电脑的 USB 转 TTL 模块直接测 Pico，排除对方设备的问题。
- 检查代码里 UART 的引脚参数是不是写错了，比如把
rx=Pin(1)写成了rx=Pin(0)，和 TX 针脚冲突。 - 用串口调试助手发数据给 Pico 时，确认助手打开的端口没错，且 Pico 端程序确实在跑
any()轮询。
这套排查顺序我基本每次都能定位到问题，而且大概率是接线或者引脚配置错误，真正是芯片坏掉的情况极少。
5.4 电平适配问题与设备烧毁防范
再强调一次电平问题，因为烧坏引脚是“不可逆”的。Pico 的 3.3V 引脚耐压有限，接 5V TTL 设备时必须做电平转换。我用得最多的是 BSS138 双 MOS 电平转换模块，几块钱一个，支持双向传输，I2C 和 UART 都能用。如果只是单向传输，用电阻分压也可以，但分压值要算好，确保高电平不低于接收端的高电平阈值。
RS232 设备则必须走 MAX3232 之类的芯片。很多人把电脑背后的 9 针 DB9 串口当成普通 TTL 串口用，结果一接上 Pico 就烧了。DB9 使用的 RS232 电平是负逻辑，完全不能直接对接 3.3V TTL。
另外，热插拔也要小心。串口线最好在断电状态下接线，尤其是和外部电源模块相连时。我见过不少设备损坏案例是在设备带电时插拔串口线，瞬间的电压尖峰把引脚打坏了。稳妥的做法是先接 GND，再接 TX、RX，最后才上电。
串口通信看起来只是两根线的事，但真正调稳了，你才会明白背后是波特率、电平标准、缓冲管理和协议设计的一整套配合。我在 Pico 上做串口项目的过程中，最大的体会就是：不要低估接口本身的坑，宁可多花十分钟接好电平转换和共地，也不要图省事直接怼上去。
最后再分享一个小技巧：养成保存串口日志的习惯。无论是用串口助手的日志功能，还是在 Python 脚本里把收发数据记录到文件，调试复杂协议时这些日志就是最宝贵的线索。很多看起来随机出现的问题，翻日志时往往能发现固定的规律。这篇文章里写到的每个坑，几乎都是从日志里一点点扒出来的。希望这些经验能帮你少走弯路，早点把串口通信跑通跑稳。
