深入RP2040 UART：从寄存器到中断与DMA的串口驱动实战

做嵌入式这些年，串口应该是我打交道最多的外设之一。早期调单片机，习惯直接翻寄存器手册，看数据手册里的时序图，拿示波器一帧一帧去对。后来上手树莓派 Pico，板子小巧、价格也便宜，但它的 UART 和很多传统 MCU 不完全一样——它用的是 ARM 标准的 PrimeCell PL011 外设，这套东西从寄存器布局到中断逻辑，跟 STM32 的 USART 差异不小。第一次用 SDK 的uart_putc发数据倒是挺顺畅，可一旦要自己做流控、开中断、跑 DMA，想绕开库函数直接操作寄存器时，才发现底层细节特别多。

这篇我不打算讲怎么调uart_init()这种封装好的 API，而是直接拆到寄存器层面：RP2040 的 UART 硬件架构长什么样，波特率分频怎么算，收发数据要踩哪些坑，中断和 DMA 怎么接，以及调试时怎么快速定位问题。适合正在折腾 Pico、想把串口用透的人，也适合那些习惯单片机通用外设、想了解 PL011 设计思路的嵌入式开发者。看完你至少能脱离 API 自己写一套不依赖 SDK 的串口驱动，真出问题也知道从哪下手查。

1. 硬件架构与关键设计思想

1.1 两个 UART 外设和引脚映射

RP2040 芯片内部集成了两个完全相同的 UART 外设，官方命名是 UART0 和 UART1。每个 UART 都支持 TX、RX、CTS、RTS 四根信号线，其中 CTS 和 RTS 用于硬件流控。关键点是，这两个外设的引脚并不固定，而是通过芯片内部的 IO Mux 矩阵来分配到不同的 GPIO 上。

我整理了一份常用映射表：

这个设计最大的好处是布线灵活。比如你做了一个扩展板，GP0、GP1 被其他功能占了，可以把串口挪到 GP12、GP13，完全不用改电路，只要初始化时多配置两步。我在实际项目里就经常把 UART0 挪到 GP16、GP17，因为这两个引脚靠近板边的位置，恰好方便外接杜邦线。

另外要注意，同一时刻一个 UART 只能使用一组引脚。你要是把 UART0 的 TX 同时配到 GP0 和 GP12，这是不行的，GPIO 功能选择寄存器同一个引脚只能选一个功能，Mux 矩阵本身不做信号复制。这个点容易在复杂的 PCB 设计里踩雷，软件上配置错了根本没数据发出。

1.2 硬件 FIFO、时钟树和 PL011 血统

PL011 是 ARM 早年推的一个通用异步收发器 IP，后来在 SoC 里被大量采用，比如树莓派其他系列、部分 NIOS 系统都用它。它的特点就是寄存器布局非常标准化，数据手册里那一套DR、FR、IBRD、LCR_H寄存器，几乎所有 PL011 芯片都一致。RP2040 直接沿用了这套设计，所以你在 Pico 上写的寄存器操作代码，以后拿到别的 PL011 平台上，稍微改下基地址和时钟频率基本就能复用。

这个 UART 内部有两个 16 字节的硬件 FIFO，一个管发送，一个管接收。别小看这两个 FIFO，它比传统 51 那种“一个字节一个中断”的设计强太多了。接收数据时，如果开了 FIFO，硬件会连续存 16 个字节才触发一次中断，CPU 不需要每个字节都被打断。发送时，你可以一次性往 FIFO 里塞多个字节，让硬件自己排队往外发，CPU 可以先去干别的事。

时钟方面，UART 外设的时钟来源于系统时钟（clk_sys）。Pico 默认运行在 125MHz，这也是大多数情况下 UART 的参考时钟频率。后面算波特率分频时，这个 125MHz 是核心输入值。如果你用 SDK 改了系统主频，比如降到 50MHz，那波特率分频参数必须重新算，否则实际波特率绝对不对，串口终端上看全是乱码。

1.3 电平特性和对接 5V/1.8V 设备的注意事项

Pico 的 GPIO 和 UART 都是 3.3V 逻辑电平，这一点很多人一开始没注意。直接拿 Pico 的 TX 去接 5V 的 Arduino 或者老式 51 开发板，虽然有时候能碰巧通信，但那是因为多数 5V 芯片把高于 2.4V 的电压识别为高电平，勉强能用，长期跑在非标条件下，发热和误码风险都在。

反过来更危险：5V 设备的 TX 输出接到 Pico 的 RX 引脚，逻辑高电平接近 5V，这已经超出 RP2040 GPIO 的绝对最大额定值。偶尔试一次可能没事，长时间挂载极有可能损伤引脚甚至烧片。我给几个不同场景的接法建议：

• Pico 与 3.3V 设备互连：直接 TX 对 RX、RX 对 TX，GND 共地，这是最简单的场景。
• Pico 与 5V 设备互连：在 Pico 的 RX 到 5V 设备 TX 之间串一个 1kΩ 左右的电阻，配合 Pico GPIO 内部的钳位二极管做限流；更稳的做法是加一颗 3.3V 电平转换芯片，比如 TXB0104 或者双向 MOSFET 电平转换模块。
• Pico 与 RS232 电平设备互连：不能直接接，必须用 MAX3232 这类 3.3V 供电的 RS232 收发器，把 ±12V 的 RS232 电平转成 3.3V 逻辑电平，再把 TTL 侧接到 Pico 的 RX/TX。
• Pico 与 1.8V 低压模块互连：Pico TX 到 1.8V 模块 RX，可以用电阻分压降到 1.8V 左右；1.8V 模块 TX 到 Pico RX，优先选支持双向电平转换的芯片，别只想着串电阻，因为 1.8V 高电平可能达不到 Pico 的 VIH 阈值。

2. 寄存器操作从零到一：手写一个底层驱动

2.1 关键寄存器布局速查

在写驱动之前，先建立全局认知。RP2040 UART 的寄存器是基于 PL011 标准排列的，每个寄存器 32 位宽度，偏移地址也是标准化的。我自己的工作习惯是先把寄存器宏定义好，之后的操作全基于这套宏，清晰又不容易错。

#define UART0_REG_BASE 0x40034000UL #define UART1_REG_BASE 0x40038000UL #define REG(base, off) (*(volatile uint32_t *)((base) + (off))) #define UART_DR(base) REG(base, 0x00) // 数据寄存器：读=接收，写=发送 #define UART_RSR(base) REG(base, 0x04) // 接收状态寄存器：溢出/帧/校验错误 #define UART_FR(base) REG(base, 0x18) // 标志寄存器：FIFO空/满、忙标志 #define UART_IBRD(base) REG(base, 0x24) // 波特率整数分频 #define UART_FBRD(base) REG(base, 0x28) // 波特率小数分频 #define UART_LCR_H(base) REG(base, 0x2C) // 线路控制：数据位、校验、FIFO使能 #define UART_CR(base) REG(base, 0x30) // 控制寄存器：UART总使能、TX/RX使能 #define UART_IFLS(base) REG(base, 0x34) // FIFO中断触发水平 #define UART_IMSC(base) REG(base, 0x38) // 中断屏蔽设置 #define UART_RIS(base) REG(base, 0x3C) // 原始中断状态 #define UART_MIS(base) REG(base, 0x40) // 屏蔽后中断状态 #define UART_ICR(base) REG(base, 0x44) // 中断清除寄存器 #define UART_DMACR(base) REG(base, 0x48) // DMA控制使能

这里最容易理解错的是DR寄存器：往它里面写数据就是发送一个字节，从它里面读数据就是接收一个字节。它和很多国产 MCU 里“发送寄存器/接收寄存器分开”的设计不一样，共用同一个地址，靠读和写方向区分。

FR状态寄存器是轮询模式下最常用的，其中TXFF（bit5）为 1 表示发送 FIFO 已满，不能再写；RXFE（bit4）为 1 表示接收 FIFO 为空，读不到数据。这两个位就是最基本的握手信号。

2.2 波特率分频计算：别只套公式，要理解原理

PL011 的波特率生成器不是简单的“时钟频率除以目标波特率”，而是用一个 6 位整数分频器加上一个 6 位小数分频器的组合。官方公式是：

• IBRD = UART_CLK / (16 * baud)，只取整数部分
• FBRD = ((UART_CLK - (IBRD * 16 * baud)) * 64) / (16 * baud)，取最接近的整数

为什么是 16 倍？因为 UART 接收端在一个 bit 时间内会采样 16 次，从起始位下降沿开始，在第 8 个采样点附近判断数据位的电平，这样能有效避免噪声干扰。这个 16 倍过采样是 UART 的经典方案，ST 的芯片也是类似思路。

拿 125MHz 时钟跑 115200 波特率举例：

divisor = 125000000 / (16 * 115200) = 125000000 / 1843200 ≈ 67.83 IBRD = 67 余数部分 = 125000000 - (67 * 1843200) = 1505600 FBRD = 1505600 * 64 / 1843200 ≈ 52.28，取 53

实际算出来的波特率：

实际串行时钟 = 125000000 / (16 * (67 + 53/64)) ≈ 115176.9 baud 误差 = (115176.9 - 115200) / 115200 ≈ -0.02%

UART 协议要求双方波特率误差在 ±2% 以内基本都能稳定通信，0.02% 的误差完全没问题。但如果你把系统时钟改成 100MHz，还继续用 125MHz 的参数去算，那结果就是 92160 的实际波特率，误差高达 20%，终端铁定乱码。这就是为什么我建议驱动里把时钟频率做成参数，别写死。

2.3 寄存器级初始化完整代码

有了寄存器宏，初始化流程就比较直白了。下面是我不依赖 SDKuart_*API 的纯寄存器初始化：

void uart_reg_init(uint32_t base, uint32_t sys_clk, uint32_t baud) { // 1. 先关闭整个UART，避免配置过程中产生毛刺 UART_CR(base) = 0x0; // 2. 计算波特率分频 uint32_t divisor = sys_clk / (16 * baud); uint32_t remainder = sys_clk % (16 * baud); uint32_t fraction = (remainder * 64) / (16 * baud); UART_IBRD(base) = divisor; UART_FBRD(base) = fraction; // 3. 线路控制：8位数据、无校验、1位停止位，使能FIFO // WLEN = 0b11 表示8位，FEN = 1 使能FIFO UART_LCR_H(base) = (0x3 << 5) | (1 << 4); // 4. 使能UART、发送、接收 // UARTEN = bit0，TXE = bit9，RXE = bit8 UART_CR(base) = (1 << 0) | (1 << 8) | (1 << 9); }

这里有个细节：为什么先关 UART 再配参数？因为如果你在 UART 还在运行的时候修改波特率分频，正在发送的半截字节可能直接被硬件打断，收端必然出错。配置外设就像换轮胎，最好先停稳了再动手。

还有一点要提醒，LCR_H寄存器在 PL011 上是只写寄存器，读出来永远是 0，不要尝试用它做回读校验。想验证配置生效，可以通过外部实际通信来确认。

2.4 轮询模式发送和接收

在没开中断之前，最朴素的收发就是轮询。发送一个字节前，先查发送 FIFO 是否满，满了就等着，没满就往DR写。接收同理，先查接收 FIFO 是否空，空了继续等，有数据就读。

void uart_putc(uint32_t base, char c) { // 等待发送FIFO不忙（TXFF=0） while (UART_FR(base) & (1 << 5)); UART_DR(base) = (uint32_t)c; } void uart_puts(uint32_t base, const char *s) { while (*s) { uart_putc(base, *s++); } } char uart_getc(uint32_t base) { // 等待接收FIFO有数据（RXFE=0） while (UART_FR(base) & (1 << 4)); return (char)(UART_DR(base) & 0xFF); }

这个实现看着简单，但实战中立刻会遇到一个问题：接收端如果在没有数据的时候一直死等，整个 CPU 都被卡死。这在嵌入式里是不能接受的。所以我实际用轮询接收的场景很少，只会在系统比较空闲、只处理一个设备时用。更多时候，要么配合超时机制跳出等待，要么直接改中断模式，让串口自己在后台积累数据。

超时版本的接收函数可以这么写：

int uart_getc_timeout(uint32_t base, uint32_t timeout_us, char *out) { uint32_t elapsed = 0; while (UART_FR(base) & (1 << 4)) { // 这里用系统时基计时，超过时间就放弃 if (elapsed++ >= timeout_us) { return -1; } } *out = (char)(UART_DR(base) & 0xFF); return 0; }

3. 中断与 DMA：让串口真正解放 CPU

3.1 中断源与触发条件

轮询最大的代价是 CPU 空转，如果系统里还有其他实时任务，比如 PID 控制、传感器采集、网络协议栈，串口长期占着 CPU 显然不现实。这时候就该用中断。

RP2040 的 UART 中断和很多 MCU 一样，属于事件触发型。PL011 提供多种中断源，常用的有这么几个：

• RXIM（bit4）：接收 FIFO 达到设定水位时触发，默认水位是 FIFO 非空即触发
• RTIM（bit5）：接收超时中断，接收 FIFO 里剩了几个字节，且一段时间没有新数据进来，就会触发一次
• TXIM（bit10）：发送 FIFO 低于设定水位时触发，告诉 CPU“你可以继续填数据了”
• OEIM、BEIM、FEIM、PEIM：溢出、间隔、帧错误、校验错误中断

实际接收场景里，RX 中断和 RT 中断通常要一起用。为什么？因为 RX 中断是按“FIFO 达到水位”触发的，如果你只收到 5 个字节，没到 16 字节的水位，RX 中断可能一直不来，数据就卡在 FIFO 里。RT 中断的作用就是兜底：只要一段时间没有新字节到达，硬件就强制触发一次中断，让你把 FIFO 里的残余数据取走。

3.2 配置中断：寄存器级别的完整流程

中断配置分三步：设置中断使能、清掉遗留的中断标志、使能 NVIC 层面的 IRQ。在 RP2040 上，UART0 的 IRQ 编号是 13，UART1 是 14。

void uart_irq_enable(uint32_t base) { // 先清所有中断标志，防止历史遗留状态误触发 UART_ICR(base) = 0x7FF; // 使能RX和RT中断 UART_IMSC(base) = (1 << 4) | (1 << 5); // 使能NVIC中断 if (base == UART0_REG_BASE) { NVIC_EnableIRQ(13); // UART0_IRQ } else { NVIC_EnableIRQ(14); // UART1_IRQ } }

中断处理函数长这样。读取DR寄存器的动作本身就会清除 RX 中断标志，但为了严谨，我还是会在最后写一次ICR，把 RT 中断清掉。

#define RX_RING_SIZE 256 volatile uint8_t rx_ring[RX_RING_SIZE]; volatile uint32_t rx_head = 0; volatile uint32_t rx_tail = 0; void uart0_irq_handler(void) { while (!(UART_FR(UART0_REG_BASE) & (1 << 4))) { uint8_t byte = (uint8_t)(UART_DR(UART0_REG_BASE) & 0xFF); rx_ring[rx_head] = byte; rx_head = (rx_head + 1) % RX_RING_SIZE; } UART_ICR(UART0_REG_BASE) = (1 << 4) | (1 << 5); }

这里用环形缓冲区来承接中断收下来的数据，主程序只需要检查rx_head != rx_tail就能知道有没有新数据。第一次写这个逻辑的人容易在“读空条件”和“写满条件”上搞混，我的建议是：环大小取 2 的幂，用位与代替取模，头尾相等就是空，(rx_head + 1) % RX_RING_SIZE == rx_tail就是满。

如果你用 Pico SDK 环境，可以把uart0_irq_handler注册到中断向量表里：

irq_set_exclusive_handler(UART0_IRQ, uart0_irq_handler); irq_set_enabled(UART0_IRQ, true);

这两种方式本质一样，SDK 背后也只是在配置 NVIC。

3.3 使用中断发送：避免打断接收

发送中断的逻辑和接收不太一样，它不是“一有空位就通知你”，而是“FIFO 低于水位就通知你”。用发送中断时，通常配合一个发送环形缓冲区：主程序把待发送的数据写入发送缓冲，然后使能 TX 中断；硬件每发掉一批数据，就触发一次中断，中断里从缓冲区取数据填充 FIFO，缓冲区空了就关闭 TX 中断。

比如，你要发一段很长的日志，直接在一个循环里往DR里写，会长时间占用 CPU。用发送缓冲区的话，先填到缓冲区，开一次 TX 中断，剩下的事情就交给硬件了：

volatile uint8_t tx_ring[TX_RING_SIZE]; volatile uint32_t tx_head = 0; volatile uint32_t tx_tail = 0; volatile uint8_t tx_busy = 0; void uart_send_byte(uint8_t byte) { uint32_t next = (tx_head + 1) % TX_RING_SIZE; while (next == tx_tail); // 缓冲区满则等待 tx_ring[tx_head] = byte; tx_head = next; UART_IMSC(UART0_REG_BASE) |= (1 << 10); // 使能TX中断 }

中断里发送部分：

void uart0_irq_handler(void) { // 先处理接收 while (!(UART_FR(UART0_REG_BASE) & (1 << 4))) { uint8_t byte = (uint8_t)(UART_DR(UART0_REG_BASE) & 0xFF); rx_ring[rx_head] = byte; rx_head = (rx_head + 1) % RX_RING_SIZE; } // 然后处理发送 if ((UART_MIS(UART0_REG_BASE) & (1 << 10)) && (tx_tail != tx_head)) { UART_DR(UART0_REG_BASE) = tx_ring[tx_tail]; tx_tail = (tx_tail + 1) % TX_RING_SIZE; if (tx_tail == tx_head) { UART_IMSC(UART0_REG_BASE) &= ~(1 << 10); // 数据发完，关TX中断 } } UART_ICR(UART0_REG_BASE) = (1 << 4) | (1 << 5) | (1 << 10); }

3.4 DMA 模式：大数据量传输的终极方案

如果数据量特别大，比如每秒几十 KB 的日志输出、把 SD 卡里的文件通过串口导出，中断模式也有点力不从心——每个字节都触发一次中断或者每填满 FIFO 才触发一次中断，CPU 开销仍然存在。DMA 模式才是终极解：硬件自动把数据从内存搬到 UART FIFO，或者从 FIFO 搬到内存，全程不需要 CPU 干预。

RP2040 的 DMA 控制器可以和外设联动，UART0 的发送 DMA 请求编号DREQ_UART0_TX是 20，接收是 21；UART1 对应 22 和 23。当 FIFO 有空位时，DMA 控制器自动触发搬运。

接收方向的 DMA 配置思路：

#include "hardware/dma.h" int dma_tx_channel; uint8_t dma_tx_buffer[1024]; void dma_uart_tx_init(uint32_t base, const uint8_t *data, uint32_t len) { dma_tx_channel = dma_claim_unused_channel(true); dma_channel_config cfg = dma_channel_get_default_config(dma_tx_channel); channel_config_set_transfer_data_size(&cfg, DMA_SIZE_8); channel_config_set_read_increment(&cfg, true); // 从内存读取，地址递增 channel_config_set_write_increment(&cfg, false); // 写到UART DR，地址固定 channel_config_set_dreq(&cfg, DREQ_UART0_TX); // 由UART的发送请求触发 dma_channel_configure( dma_tx_channel, &cfg, (void *)&UART_DR(UART0_REG_BASE), // 写入地址 data, // 读取地址 len, // 传输字节数 true // 立即启动 ); }

DMA 接收也类似，把读地址指向 UART 的DR，写地址指向内存缓冲，由DREQ_UART0_RX触发。全部数据收完后会触发 DMA 中断，你可以在里面做数据处理。

这里有个很容易犯的错误：DMA 的接收方向和串口 FIFO 的字符长度要匹配，寄存器DR读出来的低位只有 8 位有效数据，但 DMA 搬运时可以以字节为单位。如果配置成 32 位传输，硬件会把 4 个字节读到一个 word 里，排列顺序和你预想的不一样，一定要选DMA_SIZE_8。

三种收发模式怎么选，我列个表：

4. 实测调试三板斧：从硬件到波形的排查路径

4.1 回环自测：1 分钟验证硬件和配置

拿到一块新 Pico，第一次跑串口，我建议先做回环测试。方法很简单：用杜邦线把板子的 TX 和 RX 短接起来，然后程序里循环把收到的字节原样发回去。你可以直接在串口助手里发A，如果收到A，说明硬件通路、初始化配置、FIFO 方向全部正常。

回环测试的好处是隔离问题。如果回环通了，至少能证明 Pico 这边没问题，后面接外部设备出乱码，问题大概率在对方设备或者接线。如果回环都不通，那就要从引脚映射、波特率分频、使能位这些地方一层层查。

在寄存器层面做回环还有一个隐藏技巧：PL011 控制寄存器里有个LBE（bit4）位，把它置 1，TX 会在芯片内部直接连到 RX，不需要外部杜邦线，就能完成回环。这招很适合在没有示波器、没有万用表的环境下做自检：

UART_CR(UART0_REG_BASE) |= (1 << 4); // 打开回环 uart_putc(UART0_REG_BASE, 'T'); char recv = uart_getc(UART0_REG_BASE); // recv 应该等于 'T' UART_CR(UART0_REG_BASE) &= ~(1 << 4); // 关闭回环

4.2 用逻辑分析仪抓时序，别全信调试助手

串口调试助手只能告诉你“电脑收到了什么”，它没法告诉你“线上到底跑了什么波形”。遇到疑难杂症，比如数据时好时坏、偶尔丢字节，最好还是把逻辑分析仪夹在 TX 和 GND 上，抓一段实际波形。

UART 协议的单帧格式需要注意：空闲时 TX 线是高电平，发送第一个字节时，先拉低一个 bit 时间作为起始位，然后从低位到高位依次送 8 个数据位，最后再拉高一个 bit 时间作为停止位。如果你在逻辑分析仪上看到起始位、数据位、停止位都是正常的，但内容对不上，那基本可以判断是电平和采样时序的问题，而不是配置缺位。

我经常用逻辑分析仪检查两点：一是波特率偏差，二是停止位长度。如果波形宽度比理论值窄或宽，就说明分频参数或者系统主频和设想不一致。用 Pico 自己的clk_sys如果是从外部晶振 PLL 出来的，哪怕晶振偏差千分之几，这个偏差在波特率计算里都会被放大，最好用高精度时钟源。

4.3 对接 USB 转串口设备和 PC 时的那些小坑

把 Pico 连到电脑，最常见的方案是通过 USB 转串口模块，比如基于 FT232R、FT231X 的板子。这些芯片在 Windows 下需要装驱动，装好以后会枚举成一个 COM 口，波特率、数据位、停止位、流控选项都可以在设备管理器里查看。

这里我吃过亏：USB 转串口模块和 Pico 之间要共地。一旦忘了共地，电平根本没有参考点，数据飘忽不定，终端上全是随机乱码。检查顺序可以固定为：先看 COM 口号是否被系统识别，再看双方波特率、数据位、停止位、校验位是否一致，最后查 TX/RX 是否交叉连接——Pico 的 TX 接模块的 RX，Pico 的 RX 接模块的 TX，接反了就是“只发不收”。

如果用 USB 转串口模块的 DTR/RTS 引脚做自动下载或复位控制，还要注意这些信号不是标准串口数据线，不会出现在 UART 的帧结构里。很多初学者以为把 DTR 接到 Pico 的某个 GPIO 是“额外的串口通道”，其实不是，它们通常是用来控制目标板复位的。

5. 常见问题与排查技巧实录

5.1 乱码，到底是怎么回事

乱码是串口开发里出现频率最高的问题，没有之一。根据我自己的排查经验，乱码通常可以分成几类。

第一类是“持续乱码，完全没有规律”。这种情况优先查波特率。125MHz 时钟下需要算好 IBRD 和 FBRD，并且确认你用的clk_sys确实是 125MHz，不是改了 PLL 之后的另一个频率。另外，接收端的波特率也要和发送端完全一致，电脑终端软件里选错一个档位，立刻就是满屏雪花。

第二类是“开始几个字节正确，后面全乱”。这种情况之前遇到过，原因是 UART 的时钟在系统启动阶段还没稳定，或者你的程序在上电后立刻调用发送，而外部电平转换芯片还没完成初始化。解法是初始化串口后延时几毫秒再发数据，同时检查对方的 RX 使能时序。

第三类是“偶尔错一个字节”。这往往是电平质量问题。我的排查方法是把波特率降下来测试，比如从 115200 降到 9600，如果错误率明显下降，说明是线路噪声、地线干扰或者电平幅度不足。3.3V 对 5V 设备直接对接时，这种问题尤其明显，最好加电平转换。

5.2 只能发不能收，或者只能收不能发

单向通信的问题排查思路更直接。先分清是哪一端的问题：在 Pico 上写一个小程序，定时往外发0x55，用示波器或逻辑分析仪看 TX 引脚有没有波形；如果有波形，说明发送路径正常，问题在接收路径或对方设备。

“只能发不能收”最常见的原因是引脚映射错了，比如你软件里配置了 RX 在 GP13，但实际板子上数据线接到的是 GP17。检查GPIO功能选择寄存器，确认当前引脚挂载的是 UART 功能而不是普通 GPIO。其次是 RX 使能位，CR寄存器的RXE（bit8）如果被清零了，硬件就不会接收任何数据。

“只能收不能发”则要重点检查 TXE 和 CTS 硬件流控。如果你把硬件流控使能了，但 CTS 引脚没有拉低（对方没有拉低表示“别发”），UART 硬件就会一直憋着不发数据。这种问题在调试时特别隐蔽，因为程序看着没问题，就是数据不出来。

5.3 中断不触发，数据卡死在高水位

中断模式下最常见的问题是：数据明明进来了，但中断一个也不触发。三个检查点：

第一，确认IMSC里已经使能了对应中断位。很多人在初始化时只写了UART_ICR清标志，忘了写UART_IMSC使能。

第二，确认 NVIC 层的 IRQ 使能。寄存器层面的中断使能只是“允许外设产生NVIC中断”，如果 NVIC 那边没有打开，CPU 根本不会跳转到中断服务函数。

第三，检查UART_MIS状态。有时候中断已经置位，但因为软件没有清ICR，导致中断一直被挂在 pending 状态，CPU 反复进入中断，处理完又立刻被触发，看起来像“死循环”。这种问题在调试时很容易误判为“中断卡住”。

5.4 高速率下的数据丢失和 FIFO 水位调节

把波特率提到 921600 甚至 2Mbps 时，数据丢失的概率会明显上升。原因无非两种：一是接收端 CPU 处理不过来，二是 FIFO 中断水位设置不合理。

PL011 的IFLS寄存器可以设置 FIFO 触发水位。默认水位比较低，FIFO 里进来少量数据就触发中断，如果 CPU 正在忙其他事，频繁中断大概率有丢失风险。反之，如果你把水位设得太高，FIFO 攒了很多数据才触发中断，中途硬件又没地方存，溢出错误就会出现。

我的建议是：中等速率（115200~460800）使用 1/2 水位，高速率（921600 以上）使用 3/4 甚至 7/8 水位，让硬件尽可能多缓存，CPU 每次中断多处理一批。同时配合环形缓冲区，避免中断里做耗时操作。

这里再提一个芯片自带的错误位：接收溢出时，UART_RSR的OE（bit0）会被置 1。很多人在中断里读了DR就完事，从来不检查这个状态位，结果数据丢了都不知道。建议每次批量读完 FIFO 后，顺手读一下RSR并清除错误标志，至少在调试时打印出来，能看到系统是否在高速压力下丢掉过数据。

5.5 快速排查速查表

最后分享一个调试习惯

我自己做了一个串口调试的小板子，把 Pico 的 UART0 引到排针，同时接了一个 USB 转串口模块和一颗 LED。调试任何串口应用之前，先跑一遍纯寄存器版回环，确认硬件通路没问题；再跑中断版收发的 demo，验证系统优先级和缓冲逻辑；最后才接真实设备。这个习惯帮我避开了大量“改了一堆代码，其实问题在接线”的低级返工。如果你现在正被乱码或者丢数据折磨，别急着改软件，先按这个顺序把底层的通路验证一遍，大概率能快速锁定问题。

另外，Pico 的 UART 底层这套 PL011 知识点不只适用于这一块板子。之后你如果接触其他基于 ARM PrimeCell 外设的芯片，比如树莓派 4B、部分瑞萨和恩智浦的 SoC，会发现寄存器布局大差不差，波特率分频、FIFO 水位、中断清除这些操作思路完全一样。从寄存器层面把一个外设吃透，比背熟某个具体芯片的 API 要值钱得多。