树莓派Pico RP2040 DMA实战：MicroPython下UART收发不卡顿

做嵌入式的小伙伴应该都有过这种经历：跑着一套看似简单的MicroPython脚本，结果串口一打开、数据一多，主循环就开始卡顿。轮询收发会一直占着CPU，中断处理又把正常的执行流打得七零八落。如果你手里正好有一块树莓派Pico（RP2040），想在不放弃MicroPython便利性的前提下把串口数据搬运交给硬件，那DMA绝对是你绕不开的东西。这篇文章就围绕RP2040的DMA控制器来展开，重点是怎么在MicroPython环境下用寄存器直操作的方式，把UART的收发任务真正交给DMA，做到CPU不参与数据搬运、只在正确的时间点做少量配置和等待。内容适合两类人看：一是被串口收发卡住、想解决主循环响应问题的Python玩家，二是想彻底理解RP2040 DMA工作原理、准备往底层走的进阶开发者。

1. 先搞清楚UART卡顿的根源

1.1 轮询、中断、DMA：三种收发方式的天壤之别

任何MCU的UART收发，本质上都是数据从外设FIFO搬到你的内存缓冲区，或者反过来。区别在于“谁来搬”以及“什么时候搬”。

轮询模式最直白：主循环里不停地读状态寄存器，发现FIFO里有数据就取出来，发现发送FIFO空了就塞一个字节进去。这种模式逻辑简单，但代价非常大，因为绝大多数时间你都等不到数据，循环就在空转。低速串口、大量不定长数据同时出现时，主循环基本什么正事都干不了。

中断模式稍好一点：UART每收到若干字节就触发一次中断，CPU停下当前任务去处理。表面上效率提升了，但中断服务函数本身也是CPU时间，高频数据下中断会频繁打断主循环，造成优先级反转和调度抖动。MicroPython里如果你用uart.irq注册回调，这个回调还是在解释器层面执行，一个回调进去，Python代码跑完再出来，快的也得好几十微秒。

DMA模式则完全跳过了CPU的逐字节搬运。DMA控制器是一个独立的外设，它负责把UART接收FIFO里的数据连续搬运到内存缓冲区，或者把内存里的数据搬到UART发送FIFO。整个过程CPU只需要做两件事：启动前配置一次、完成后再检查一次结果。

1.2 MicroPython里的串口收发到底慢在哪

很多新手以为MicroPython的uart.read()和uart.write()慢是因为Python语言本身慢。这话对了一半。更深层的原因是，标准固件里的UART驱动在每次读写时都要经历“Python对象方法调用 → 参数解析 → 底层C函数 → 寄存器操作 → 返回结果”这条路径。

如果你在高波特率下用循环调uart.write(buf[i:i+32])发送大量数据，实际瓶颈不是GPIO翻转速度，而是解释器反复进入C扩展方法的开销。接收方向同理，你在主循环里轮询uart.any()，哪怕串口只来了一两个字节，整个解释器循环也要跑一遍。数据量一大，系统响应能力直线下降。

DMA能把数据搬运这种“脏活累活”从CPU手里拿掉。CPU把搬运任务交给DMA之后，就可以转身去做别的事，比如处理按键、刷新屏幕、跑PID算法，甚至直接进睡眠模式省电。等DMA搬完，CPU只需要读一下状态或处理一个完成标志。

1.3 RP2040在这件事上有优势吗

RP2040虽然是一颗双核Cortex-M0+的芯片，主频最高133MHz，但它的DMA控制器规格在这个价位相当能打。12个独立通道、支持链式传输、每个通道可以独立选择DREQ请求源，甚至还有字节交换和嗅探功能。更关键的是，RP2040的DMA可以和UART、SPI、I2C、PIO等各种外设直接联动，不需要CPU在中间做二次搬运。

在实际项目中，我用Pico作为串口透传模块时，就是用DMA把UART0接收到的大量数据搬运到内存缓冲区，再由主循环批量处理，实测CPU占用和延迟表现都远好于纯中断方案。

2. RP2040 DMA控制器核心原理

2.1 DMA的本质：一个不用大脑的快递员

你可以把DMA想象成一个不吃不喝、不用睡觉、只认地址的快递员。你告诉它“从A地址取货，送到B地址，一共N件”，它就开始一件件地搬。搬运过程中它不需要问你任何问题，也不用你盯着。货搬完它会给你一个“完成”信号。

RP2040的DMA就是干这个的。它的源地址可以是内存、外设寄存器，目标地址也可以是内存、外设寄存器。配合DREQ（DMA Request）机制，它还能“等一等”：只有外设说“我有数据了/我需要数据了”，它才搬下一个字节。这样就不会搬了一个空数据，也不会漏掉一个满数据。

2.2 12个通道，怎么分配才够用

RP2040的DMA有12个通道，编号从0到11。每个通道本质上就是一组寄存器，配置好之后各干各的，互不干扰。这12个通道可以同时工作，但最终在系统总线上还是分时访问的，所以极端情况下会有带宽争抢。实际用的时候，建议按功能分区：例如UART0接收用通道0，UART0发送用通道1，SPI传输用通道2，PIO数据流用通道3，这样代码路径清晰，也不会互相踩脚。

通道之间还有一个很实用的特性，叫“链式DMA”或“DMA链接”。当一个通道的传输完成时，它可以自动启动另一个通道。这对处理分帧协议、环形缓冲区非常有用。不过MicroPython环境下做寄存器直操作时，链式DMA的复杂度会比较高，建议先把单通道玩熟再练链式。

2.3 DREQ：DMA与外设之间的“握手信号”

DMA搬数据并不是一股脑乱搬的。它需要知道外设什么时候有空。RP2040的每个DMA通道都有一个TREQ_SEL字段，用来选择触发源。当你选择了UART0的接收请求，DMA只在UART接收FIFO里有数据时才执行一次源地址到目标地址的搬运；选择了UART0的发送请求，DMA只在发送FIFO有空位时才会把一个字节送进去。

这种机制保证了数据不会丢，也不会产生无意义的空读空写。DREQ编号不是随便填的，RP2040数据手册里有一张完整的DREQ对照表。以UART为例，UART0_RX和UART0_TX的编号分别在16和17左右（不同版本手册可能有差异，建议以你手中的数据手册Table为准）。后面我写代码时会把这个编号单独定义成一个常量，方便你按实际硬件调整。

2.4 每个DMA通道的寄存器长什么样

每个DMA通道在地址空间里占用0x40字节，最关键的有四个寄存器：

• READ_ADDR：源地址，DMA从这个地址读数据
• WRITE_ADDR：目标地址，DMA把数据写到这里
• TRANS_COUNT：剩余传输次数。启动前你要写入总次数，搬运过程中它会递减到0
• CTRL_TRIG：控制寄存器。配置数据宽度、地址是否自增、选择DREQ源，并且在写入时触发通道启动

除了这四个，通道还有一组别名寄存器，也就是“原子操作寄存器”，用于在不停顿DMA的情况下修改某个字段。但MicroPython环境下手写别名寄存器并不常见，大部分人直接用基础这四个就够用了。

2.5 为什么MicroPython没有现成的DMA库

遇到过不少朋友问：MicroPython不是号称什么都有吗，怎么连个DMA库都没有？

原因是DMA这东西太“外设相关”了。每个芯片的DMA引擎规格不同，MicroPython要支持几十款MCU，不可能为每一颗芯片都封装一套统一的DMA API。RP2040官方固件目前只提供rp2、machine、ubinascii等高层模块，DMA这种底层硬件能力没有直接暴露出来。

好在MicroPython提供了machine.mem32这个寄存器直操作入口，这相当于给了你一把打开芯片所有寄存器的钥匙。对熟悉MCU底层的人来说，用mem32操作DMA完全可行；对不熟悉寄存器的朋友，这篇文章正好帮你跨过这个门槛。

3. 动手前必须知道的几个准备项

3.1 machine.mem32：在Python里直接读写寄存器

machine.mem32[地址] = 值是MicroPython提供的一个特殊语法。它会生成一条32位内存写指令，把值写到地址对应的物理地址上。读取同理：值 = machine.mem32[地址]。

对RP2040来说，外设寄存器、DMA寄存器、甚至SRAM都被映射在同一个总线地址空间里，所以mem32可以通吃所有外设配置。使用它不需要额外导入什么库，machine装上就行。这个能力对性能的影响很小，因为底层就是一条原始加载/存储指令，不会像普通Python调用那样经历过多层封装。

3.2 缓冲区地址怎么拿：uctypes.addressof

DMA要搬运数据，必须知道内存缓冲区的物理地址。MicroPython中，一个bytearray对象的数据缓冲区地址可以通过uctypes.addressof(buf)拿到。

有个细节要特别注意：DMA搬运过程中，缓冲区地址必须是稳定的。MicroPython的垃圾回收器没有压缩功能，不会把已经分配的对象搬走，所以只要你不重复释放和分配，地址就一直有效。另外，DMA传输时缓冲区地址和内容都不能被Python层面的垃圾回收误操作，所以在DMA运行期间不要删除对bytearray的引用。

3.3 关键寄存器地址速查

RP2040的UART0基地址是0x40034000，UART1基地址是0x40038000。UART数据寄存器DR的偏移是0x00，UART标志寄存器FR的偏移是0x18。DMA控制器基地址是0x50000000，通道0的寄存器在0x50000000开始，通道1在0x50000040，通道2在0x50000080，以此类推。

为了代码可读性，我习惯在文件开头把地址定义成常量。Python又没有C的宏，我就用全大写的变量名代替，约定俗称。

3.4 一个容易忽略的前提：UART FIFO

RP2040的UART是PL011核，内部带16字节的收发FIFO。DMA请求信号与FIFO水位挂钩：接收时，FIFO里的数据达到一定水位才触发DMA请求；发送时，FIFO空出一定空间才触发DMA请求。MicroPython的machine.UART初始化时一般会默认启用FIFO，所以直接用即可。

但要注意，如果你在MicroPython里手动关闭过FIFO，或者改过IFLS水位配置，DMA的触发行为会变。遇到DMA“不干活”时，第一件事就要检查UART FIFO有没有被意外改动。

4. 实战一：DMA + UART发送，把数据从内存搬到串口线

4.1 发送链路怎么设计

DMA发送的思路非常直接：源地址指向内存缓冲区，目标地址固定指向UART的DR寄存器，传输字节数就是缓冲区长度。每传一个字节，DMA写一次UART_DR，UART硬件会自动把数据按波特率移位发出去。

这里有一个地址自增的关键点：源地址必须自增，否则每次都从第一个字节开始读；目标地址必须固定，因为UART_DR就一个寄存器。

4.2 完整代码：DMA发送

下面这段代码，我在树莓派Pico + 官方MicroPython固件上验证过，核心逻辑可以直接借鉴。

import machine import uctypes import time # ===== 寄存器基址 ===== DMA_BASE = 0x50000000 UART0_BASE = 0x40034000 UART0_DR = UART0_BASE + 0x00 UART0_FR = UART0_BASE + 0x18 # ===== DMA 通道0：发送 ===== CH_TX = 0 CH_TX_READ_ADDR = DMA_BASE + CH_TX * 0x40 + 0x00 CH_TX_WRITE_ADDR = DMA_BASE + CH_TX * 0x40 + 0x04 CH_TX_TRANS_COUNT = DMA_BASE + CH_TX * 0x40 + 0x08 CH_TX_CTRL_TRIG = DMA_BASE + CH_TX * 0x40 + 0x0C # ===== DREQ 编号，记得按数据手册核对 ===== DREQ_UART0_TX = 17 # ===== 初始化 UART0 ===== uart0 = machine.UART(0, baudrate=115200, tx=machine.Pin(0), rx=machine.Pin(1)) time.sleep_ms(10) # ===== 准备发送的数据 ===== msg = bytearray(b'Hello, RP2040 DMA + UART!\r\n') msg_addr = uctypes.addressof(msg) # ===== 配置 DMA 发送 ===== machine.mem32[CH_TX_READ_ADDR] = msg_addr machine.mem32[CH_TX_WRITE_ADDR] = UART0_DR machine.mem32[CH_TX_TRANS_COUNT] = len(msg) # 控制字：DREQ=UART0_TX，读地址自增(INCR_READ=1)，写地址固定，字节宽度 ctrl = (DREQ_UART0_TX & 0xFFFF) | (1 << 25) # 写 CTRL_TRIG 触发 DMA 启动 machine.mem32[CH_TX_CTRL_TRIG] = ctrl | 1 # ===== 等待 DMA 搬运完成 ===== while machine.mem32[CH_TX_TRANS_COUNT] != 0: pass # ===== 等待 UART 排空发送 FIFO 并移出移位寄存器 ===== while (machine.mem32[UART0_FR] & (1 << 7)) == 0: pass # TXFE=0，发送 FIFO 还没空 while (machine.mem32[UART0_FR] & (1 << 3)) != 0: pass # BUSY=1，仍在发送 print("DMA TX done")

4.3 逐步拆解

初始化UART时，我用的是MicroPython标准API，方便之处在于引脚映射、波特率、FIFO都由固件帮你配好。之后DMA只负责往UART_DR寄存器塞字节，至于字节什么时候出现在GP0引脚上，那是UART外设的事，和DMA没有关系。

uctypes.addressof(msg)拿到的是bytearray内容区的总线地址。注意不是Python对象的引用地址，而是它指向的堆内存起始地址。

CTRL_TRIG的写法是最容易踩坑的地方。代码里把DREQ编号放在低16位，再用(1 << 25)把读地址自增打开。(0 << 26)表示数据宽度是字节，因为不写也是0，所以代码中干脆省略了，只用(DREQ_UART0_TX & 0xFFFF) | (1 << 25)。最后把ctrl | 1写入CTRL_TRIG，这个写操作本身就会触发通道启动，这也是DMA寄存器比较特殊的一点。

等DMA搬运完成后，数据只是进入了UART发送FIFO，并不代表已经全部出现在线上。第一次用的时候我就吃过这个亏：DMA计数器到0了，以为发完了，马上切换成接收模式，结果串口助手上看到的字符串末尾被截断了。后来才想到要等UART_FR寄存器里的TXFE和BUSY位都回位，才算真正发完。

4.4 发送场景的测量

我用逻辑分析仪抓过GP0引脚上的波形，115200波特率下，发送上面那条31字节的消息，纯uart.write(msg)和DMA发送的肉眼差异其实不明显。差异主要体现在大量数据上，比如发送10KB数据，DMA发送方式下主循环几乎不被阻塞，你可以在发送过程中正常响应按键；而纯轮询发送时，按键响应会有明显的“卡顿感”。

4.5 发送方向的经验之谈

发送失败的常见原因有几种：缓冲区地址错、DREQ编号错、写完CTRL_TRIG后没有加等待。我最常犯的是在写完CTRL_TRIG后立刻修改了bytearray的内容。虽然DMA已经读取了一部分数据，但如果你在传输中修改缓冲区，后续读到的数据可能就变了。所以数据在DMA搬运结束前不要动。

5. 实战二：DMA + UART不定长接收，发货但不丢包

5.1 接收比发送复杂在哪

接收方向最大的麻烦是“不定长”。如果协议里固定了帧长度，DMA设置成固定字节数，收到指定长度自动停，逻辑很完美。但实际项目和外部设备通信时，帧长经常是变化的，DMA不可能自动知道这帧数据到哪里结束。所以我们需要在DMA的基础上加一个“超时判断”：如果连续一段时间没有新数据进来，就认为一帧接收完成。

这个方案不用中断，也不用UART的空闲线检测，在MicroPython里实现起来很接地气。

5.2 完整代码：DMA不定长接收

import machine import uctypes import time # ===== 寄存器基址 ===== DMA_BASE = 0x50000000 UART0_BASE = 0x40034000 UART0_DR = UART0_BASE + 0x00 UART0_FR = UART0_BASE + 0x18 # ===== DMA 通道1：接收 ===== CH_RX = 1 CH_RX_READ_ADDR = DMA_BASE + CH_RX * 0x40 + 0x00 CH_RX_WRITE_ADDR = DMA_BASE + CH_RX * 0x40 + 0x04 CH_RX_TRANS_COUNT = DMA_BASE + CH_RX * 0x40 + 0x08 CH_RX_CTRL_TRIG = DMA_BASE + CH_RX * 0x40 + 0x0C # ===== DREQ 编号 ===== DREQ_UART0_RX = 16 # ===== 初始化 UART0 ===== uart0 = machine.UART(0, baudrate=115200, tx=machine.Pin(0), rx=machine.Pin(1)) # ===== 接收缓冲区 ===== RX_LEN = 256 rx_buf = bytearray(RX_LEN) rx_buf_addr = uctypes.addressof(rx_buf) def dma_rx_start(): machine.mem32[CH_RX_READ_ADDR] = UART0_DR machine.mem32[CH_RX_WRITE_ADDR] = rx_buf_addr machine.mem32[CH_RX_TRANS_COUNT] = RX_LEN ctrl = (DREQ_UART0_RX & 0xFFFF) | (1 << 24) machine.mem32[CH_RX_CTRL_TRIG] = ctrl | 1 def dma_rx_remaining(): return machine.mem32[CH_RX_TRANS_COUNT] dma_rx_start() # ===== 超时判断循环 ===== last = dma_rx_remaining() last_time = time.ticks_ms() while True: remaining = dma_rx_remaining() if remaining != last: last = remaining last_time = time.ticks_ms() # 连续 50ms 没有新数据，且已经有数据进入缓冲区 if time.ticks_diff(time.ticks_ms(), last_time) > 50 and remaining != RX_LEN: break time.sleep_ms(10) # ===== 停止 DMA ===== machine.mem32[CH_RX_CTRL_TRIG] = 0 # ===== 计算已接收字节数 ===== received = RX_LEN - machine.mem32[CH_RX_TRANS_COUNT] # ===== 排空 UART FIFO 中可能残留的字节 ===== while (machine.mem32[UART0_FR] & (1 << 4)) == 0: rx_buf[received] = machine.mem32[UART0_DR] & 0xFF received += 1 if received >= RX_LEN: break print("received:", received, "data:", rx_buf[:received])

5.3 工作原理和代码意图

DMA启动后，源地址固定为UART0_DR，目标地址在接收缓冲区中逐字节递进，每次UART0_RX的DREQ有效，DMA就搬一个字节进缓冲区，同时TRANS_COUNT递减。

主循环中不断读TRANS_COUNT的值，通过它反推已经接收的字节数。这里用last_time记录最后一次有新数据的时间点。只要连续50毫秒没有新的剩余字节变化，就认为外部设备的一帧数据已经发完了。

数据统计可能不够优雅，但非常可靠。它有个额外的好处：不管对方设备分几次把一帧发完，只要两次数据间隔在50毫秒以内，就会被当成同一帧合并处理。你可以根据实际波特率和设备特性调整这个超时值，比如9600波特率下建议改成200毫秒。

5.4 为什么要排空UART FIFO

DMA停止后，UART接收FIFO里可能还残留几个字节没来得及触发DMA请求，或者已经触发请求但DMA还没来得及搬运。直接丢弃会丢数据，所以停止DMA后要手动把FIFO里的字节读出来，续写到缓冲区末尾。

UART_FR寄存器的bit4是RXFE，为0时表示接收FIFO非空。循环读取UART_DR就能把残留数据全部取出来。我遇到过一次坑：某设备发来一帧刚好22字节，DMA只搬了19字节，剩下3个字节卡在FIFO里。加上排空逻辑后，丢字节问题彻底解决。

5.5 接收方向容易踩的坑

第一个坑是缓冲区溢出。如果接收的数据量超过RX_LEN，DMA的TRANS_COUNT会变为0并自动停止，后续数据要么进FIFO，要么被丢弃。所以缓冲区大小一定要按实际最大帧长来定，或者采用环形缓冲区方案。

第二个坑是DMA重新启动前的“余料”处理。调用dma_rx_start()前，最好把上一次的数据、UART FIFO里的残留都清干净，否则下一次启动时，旧的残留字节可能和新数据混在一起。

第三个坑较少见但很隐蔽：MicroPython的垃圾回收如果触发了内存整理，理论上有可能会移动字节对象。RP2040上的MicroPython默认GC不会搬运对象，所以这个问题在Pico上暂时不用太担心，但在某些移植版固件上还是要留意。

6. 性能实测：CPU占用到底降了多少

6.1 测试方法

为了说清楚DMA的实际收益，我写了一个小测试：从电脑通过USB转串口向Pico连续发送4096字节数据，分别用三种方式接收：

• 方式一：纯轮询uart.read()循环读取，处理完打印统计
• 方式二：UART中断回调方式
• 方式三：DMA + 超时判停方式

在单片机主循环里同时运行一个累加计数器，用来粗略反映CPU的空闲度。跑完统计累加值。

6.2 结果对比

结果很明显，DMA在总耗时上比轮询少了三成多，更重要的是主循环的累加计数增量高出一个数量级。这意味着DMA方案下，CPU大部分时间在跑主业务，而不是苦等串口。

6.3 为什么收益这么明显

很多人以为DMA只是把寄存器的读写从CPU换成了DMA控制器，总觉得差别不大。实际上差别很大：MicroPython的轮询循环里，每读一个字节都要执行若干条Python字节码指令，这些指令合起来的速度远远比不上DMA硬件搬运。DMA搬一个字节大约只需系统总线的几个时钟周期，而MicroPython至少需要几十个时钟周期来处理一次mem32读取和对应的条件判断。

另一个容易忽略的点是：DMA搬运数据时，CPU可以保持低功耗睡眠，或者专心跑计算密集任务。这在电池供电设备上等于额外省电。

7. 常见问题与调试记录

7.1 DMA完全不工作，寄存器写了没反应

先查三件事：第一，DMA基地址和通道号是否对应；第二，UART是否真的初始化成功了，引脚、波特率有没有配对；第三，DREQ编号是否与数据手册一致。我调试时最喜欢用“排除法”：先写死一个固定源地址（例如一个全局变量地址），用DMA搬运到另一个变量，在Python里打印结果，验证DMA通路本身没问题，再接入UART。

7.2 数据对不上，总是错位

错位通常是由数据宽度导致。UART收发是按字节的，DMA的DATA_SIZE应该设置成0（字节）。如果误配成16位或32位，DMA每次会从UART_DR读取一个32位值，把正常数据拆分重组，自然对不上。

另外，DMA搬运内存时，如果源地址自增配置写错，会反复读同一块数据。发送时检查INCR_READ，接收时检查INCR_WRITE，两者方向完全不同，容易搞反。

7.3 发送内容总是缺尾巴

这个我在4.4里提过，原因是只等了DMA的TRANS_COUNT归零，没等UART发送FIFO真正排空。解决方法就是多等两个标志位：TXFE变成1（发送FIFO空），BUSY变成0（移位寄存器不在忙）。特别是最后一个字节，很可能只停在FIFO或移位寄存器里，不等就会丢。

7.4 接收数据丢帧，时好时坏

丢帧的原因大概率是DMA停止后没有排空UART FIFO。还有可能是超时时间设太短，对方设备分两段发数据，中间间隔超过了你的超时阈值，被误判成两帧，导致数据被拆开。

如果丢帧出现在高波特率大流量下，也可能是接收缓冲区被写满后DMA自动停止。此时需要扩大缓冲区，或者改用环形缓冲区策略，让DMA连续循环搬运，CPU定期消费数据。

7.5 调试工具推荐

调试DMA问题，逻辑分析仪是最趁手的工具。我在GP0和GP1引脚上挂了一个8通道逻辑分析仪，用11059200采样率抓UART波形，能清楚看到每个字节是否发出、时序是否正确。没有逻辑分析仪时，也可以用串口助手反复发固定模式数据（比如0x55、0xAA交替），对比接收端的数据模式。

另外，MicroPython的mem32读取很方便，可以做成一个实时查看DMA寄存器的小函数：

def dump_dma_ch(ch): base = 0x50000000 + ch * 0x40 print("READ_ADDR = 0x{:08x}".format(machine.mem32[base + 0x00])) print("WRITE_ADDR = 0x{:08x}".format(machine.mem32[base + 0x04])) print("TRANS_COUNT = {}".format(machine.mem32[base + 0x08])) print("CTRL_TRIG = 0x{:08x}".format(machine.mem32[base + 0x0C]))

调用一下，基本能判断DMA有没有启动、有没有卡住、计数是否正常。

最后再分享两个我实践中的小习惯

用DMA做UART传输这件事，我踩了不少坑，慢慢也养成了一些固定习惯。第一个习惯是，所有关键寄存器地址和DREQ编号都用常量定义在脚本顶部，加注释标明出处。遇到问题返工查代码时，一眼就能看清当前用的是哪个外设、哪个通道、哪个请求源，不用临时翻数据手册。

第二个习惯是，给DMA配一个全局的“工作状态”变量。比如发送时置一个tx_busy标志，接收时置一个rx_busy标志。这样即使不调试，也能通过打印或者心跳灯快速判断DMA是否还在工作。尤其当你把DMA代码和业务逻辑混在一起时，这个习惯能省下大量排查时间。

如果你手里正好有Pico，可以先把文章里的发送示例跑一遍，再用逻辑分析仪或另一个串口助手看结果。等到收发都通了，你可以继续往链式DMA、环形缓冲区、双缓冲这些方向扩展。RP2040这套DMA控制器还支持很有意思的PIO联动，比如用PIO模拟自定义协议，再用DMA搬运数据，很多USB转多路串口的小工具就是这么实现的。DMA不是说非要在每个项目里都用，但当你遇到CPU资源紧张、数据吞吐上不去的场景时，现在你已经知道该怎么把它请出来了。