RP2040 MicroPython DMA内存搬运实战：手写dma_copy告别慢速循环

在 RP2040 上用 MicroPython 写数据搬运逻辑，最让人崩溃的就是“循环复制”这个场景。你辛辛苦苦写了个for i in range(len(src)): dst[i] = src[i]，跑起来才发现速度慢到怀疑人生；换成dst[:] = src虽然底层是 C 实现，但 CPU 照样被同步阻塞住，大缓冲区一份就是一两毫秒，什么都干不了。其实 RP2040 这颗芯片自带一套功能很完整的 DMA 控制器，MicroPython 里也能直接用，只是资料少、示例乱，很多教程一上来就让你翻 SDK 源码，搞得大家听到“DMA”就觉得高不可攀。这篇文章我准备用最朴素的方式，把 MicroPython + RP2040 下 DMA 做“内存到内存数据传输”这件事彻底讲透，读完你不仅能写出自己的dma_copy，还能理解背后的寄存器、触发机制和坑点，特别适合被数据处理速度卡住、又不想放弃 MicroPython 的开发者。

1. 为什么要做 DMA 内存搬运

1.1 MicroPython 里的数据复制痛点

MicroPython 跑在 RP2040 上，Python 层的循环效率比 C 慢了不止一个数量级。我们经常遇到这样的场景：传感器一次性采回几 KB 数据、图像帧需要做行列变换、音频缓冲需要前后搬移，这些操作如果用 Python 层逐字节循环来做，64KB 数据复制一次可能要花掉几百毫秒，这在任何实时性敏感的场景里都是不可接受的。

有人会说，那用dst[:] = src不就行了？这个操作确实是由 MicroPython 内部的 C 代码实现的，速度快很多，但它仍然是“同步”的：复制期间 CPU 被占用，你的 MicroPython 线程只能干等着。在需要同时处理采集、显示、通信的任务里，这种阻塞会带来明显的调度抖动。

更关键的是，RP2040 这套 Cortex-M0+ 双核芯片，本身专门为这种数据搬运设计了 DMA 硬件，不用白不用。

1.2 RP2040 DMA 到底能做什么

RP2040 的 DMA 控制器有 12 个独立通道，可以在内存、外设、PIO、Flash XIP 之间搬运数据，支持增加读地址、增加写地址、链式传输、环形缓冲，甚至可以在一次传输完成后自动触发另一个通道继续干活。

很多人以为 DMA 只能配合外设用，比如 SPI 接收、UART 发送、ADC 采样，其实它最基础也最实用的一种模式就是“内存到内存”。我们只需要把源地址、目标地址、传输次数填进寄存器，再设置一个强制请求，DMA 就会自己把数据搬完，不需要任何外设参与。

这里涉及到 RP2040 DMA 的触发机制：DMA 的每一次数据传输都需要一个 DREQ 请求。普通外设模式下，DREQ 来自 SPI、UART、PIO 等；但如果我们把 DREQ 设置成DREQ_FORCE，DMA 就会一直处于“请求有效”状态，相当于软件强制触发，这正是实现内存到内存搬运的关键。

1.3 什么场景才真正值回票价

不是所有复制都要上 DMA。数据只有几十字节、复制频率很低，DMA 的配置开销反而比直接 C 层切片更大。真正值回票价的场景有几个特点：

• 数据块大，典型是 1KB 以上的缓冲区；
• 复制频率高，比如音频帧、图像帧、传感器批量数据；
• 搬运过程可以和 CPU 其他逻辑并行，或者至少希望 CPU 不被长时间阻塞。

比如说，你要把一块图像帧缓冲搬到另一块缓冲做处理，再搬运到 PIO 控制的屏幕接口，这种“搬来搬去”的操作如果全用 Python 层代码，CPU 被吃得死透；用 DMA 把这些搬运甩给硬件，CPU 就能腾出来跑协议栈、UI 逻辑或者其他计算任务。

2. MicroPython 里怎么调 DMA：寄存器直操作才是王道

2.1 为什么不用 rp2.DMA 封装

MicroPython 官方固件里其实提供了一个rp2.DMA类，理论上可以直接用dir(rp2.DMA)查看方法。但这里有个现实问题：不同固件版本的 API 差异很大，有人用的 1.19、有人用 1.23，还有各种第三方编译版本，DMA类的属性和方法经常对不上，网上抄来的代码在另一台设备上很容易直接报错。

所以我更推荐用machine.mem32直操作寄存器。MicroPython 的machine.mem32可以直接读写 RP2040 的内存映射地址，DMA 控制器的寄存器本质上就是一段内存地址，这种方式不受固件封装变化影响，只要寄存器地址和位段定义不变，代码就能稳定跑。

直操作寄存器还有一个好处：你能真正理解 DMA 的工作流程。等你以后去看官方 C SDK 或者移植到其他芯片，核心思路完全通用。

2.2 寄存器地图与一次传输的执行流程

RP2040 DMA 控制器的基地址是0x50000000。每个通道占 0x40 字节的寄存器空间，通道 0 的四关键寄存器如下：

通道 1 的寄存器等于基地址加 0x40，通道 n 的基地址就是0x50000000 + n * 0x40。

一次内存到内存 DMA 传输的流程只有三步：

1. 把源地址填入READ_ADDR；
2. 把目标地址填入WRITE_ADDR；
3. 把传输次数填入TRANS_COUNT，再向CTRL_TRIG写入控制字，DMA 就会开始搬运。

CTRL_TRIG这个名字很有意思，“CTRL”是控制，“TRIG”是触发，也就是说向它写入配置的同时，还会触发通道启动。

2.3 CTRL_TRIG 位域与参数计算

CTRL_TRIG是一个 32 位寄存器，每个位段都要搞清楚，否则 DMA 根本不会按你预想的方式工作。以下是本次最关键的几个位段：

参数计算的要点在于：TRANS_COUNT存的不是“字节数”，而是“传输单元的个数”。如果你设置DATA_SIZE=0，也就是 8 位模式，那么传 1024 字节就需要填1024；如果你设置DATA_SIZE=2，也就是 32 位模式，那么传 1024 字节只需要填1024 // 4 = 256。这一点特别容易踩坑，很多人逻辑看着不错，结果数据只搬了一部分或者在末尾越界，就是因为把字节数直接填进了TRANS_COUNT。

内存到内存传输时，INCR_READ和INCR_WRITE一般都设为 1，这样 DMA 才会把源地址和目标地址依次递增。如果不设置，DMA 会一直重复读写同一个地址，结果就是整块数据全变成了第一个字节的复制。

3. 保姆级实操：从零写一个 dma_copy

3.1 准备缓冲区并获取物理地址

在 MicroPython 里，我们能直接拿到 Python 对象的内部内存地址，用uctypes.addressof。这段代码创建两个 256 字节的bytearray，一个当源，一个当目标：

from machine import mem32 from uctypes import addressof src = bytearray(range(256)) # 0x00~0xFF dst = bytearray(256) # 全 0 src_addr = addressof(src) dst_addr = addressof(dst) print(hex(src_addr), hex(dst_addr))

bytearray对象在内存中的地址是物理地址，RP2040 的 SRAM 从0x20000000开始，DMA 可以直接访问这片地址。MicroPython 的 GC 是标记清除、不移动对象的，所以只要你一直持有src和dst的引用，地址就是稳定的。

小提示：bytearray分配出来的内存通常 4 字节对齐，但这不是绝对保证。为了稳妥，我建议在配置 DMA 时先检测地址对齐情况，再决定用 32 位模式还是 8 位模式。

3.2 配置寄存器并触发，完成第一次内存搬运

现在开始第一次真正的 DMA 内存到内存传输。为了安全，先用 8 位模式，也就是每个传输单元 1 个字节：

DMA_BASE = 0x50000000 CH0_BASE = DMA_BASE + 0x00 # 填源地址和目标地址 mem32[CH0_BASE + 0x00] = src_addr mem32[CH0_BASE + 0x04] = dst_addr # 传输次数，8位模式等于字节数 mem32[CH0_BASE + 0x08] = len(src) # 控制字：TREQ_SEL=0x3F 强制请求，INCR_WRITE=1，INCR_READ=1 # DATA_SIZE=0（8位），EN=1 ctrl = (0x3F << 16) | (1 << 5) | (1 << 4) | (0 << 2) | 1 mem32[CH0_BASE + 0x0C] = ctrl # 等待传输完成 while mem32[CH0_BASE + 0x08] != 0: pass print("copy done:", dst == src)

运行后如果打印copy done: True，说明 DMA 已经成功把 256 字节从src搬到了dst。这一步看着简单，但背后已经包含了 DMA 工作的全部核心：地址、计数、控制使能。

while mem32[CH0_BASE + 0x08] != 0是轮询等待方式。DMA 每完成一个传输单元，TRANS_COUNT就会递减一次，减到 0 表示整批数据搬完了。虽然轮询会让 CPU 干等，但作为教学和简单场景已经够用，后面再聊更高级的异步方式。

3.3 封装成可复用函数

把上面的逻辑封装成一个函数，顺便支持 32 位模式加速。我推荐这样写：

from machine import mem32 from uctypes import addressof DMA_BASE = 0x50000000 DREQ_FORCE = 0x3F def dma_copy(dst, src, nbytes=None): if nbytes is None: nbytes = min(len(src), len(dst)) if nbytes <= 0: return 0 ch_base = DMA_BASE # 固定用通道0 s = addressof(src) d = addressof(dst) # 地址4字节对齐时，优先用32位模式 if (s | d) & 3 == 0 and nbytes % 4 == 0: data_size = 2 << 2 count = nbytes >> 2 else: data_size = 0 << 2 count = nbytes mem32[ch_base + 0x00] = s mem32[ch_base + 0x04] = d mem32[ch_base + 0x08] = count ctrl = (DREQ_FORCE << 16) | (1 << 5) | (1 << 4) | data_size | 1 mem32[ch_base + 0x0C] = ctrl while mem32[ch_base + 0x08] != 0: pass return nbytes # 测试 src = bytearray(range(256)) dst = bytearray(256) dma_copy(dst, src) print(dst[:16])

这个函数兼容性很好，无论目标地址是否对齐都能工作。唯一要注意的是：在 32 位模式下，nbytes必须是 4 的倍数，否则会漏掉末尾的 1~3 个字节，所以我在判断条件里加上了nbytes % 4 == 0。

3.4 注意：TRANS_COUNT 不是字节数

这个坑我栽过一次，必须单独拿出来说。TRANS_COUNT寄存器存的是传输单元个数，而不是字节数。同样搬 1024 字节：

• 8 位模式：TRANS_COUNT = 1024
• 16 位模式：TRANS_COUNT = 512
• 32 位模式：TRANS_COUNT = 256

如果把 32 位模式的TRANS_COUNT误填成1024，DMA 会尝试读取源地址后面 4KB 的空间、写入目标地址后面 4KB 的空间，结果就是数据错乱，甚至可能把不相关的内存区域覆盖成垃圾数据。RP2040 的 DMA 不检查越界，它只是忠实地按你的地址和计数搬运，所以所有的边界检查都必须自己做。

4. 性能实测与适用边界

4.1 测试脚本

口说无凭，直接跑性能测试。测试对象是 64KB 的缓冲区，对比三种方式：Python 循环复制、bytearray 切片复制、DMA 复制。

import time from machine import mem32 from uctypes import addressof src = bytearray(65536) dst = bytearray(65536) # 给源数据填充 0x5A for i in range(len(src)): src[i] = 0x5A # 1. Python 循环复制 t0 = time.ticks_us() for i in range(len(src)): dst[i] = src[i] t1 = time.ticks_us() print("python loop:", time.ticks_diff(t1, t0), "us") # 2. bytearray 切片复制 t0 = time.ticks_us() dst[:] = src t1 = time.ticks_us() print("slice copy:", time.ticks_diff(t1, t0), "us") # 3. DMA 复制，使用上面的函数 DMA_BASE = 0x50000000 DREQ_FORCE = 0x3F s = addressof(src) d = addressof(dst) ch_base = DMA_BASE count = len(src) // 4 mem32[ch_base + 0x00] = s mem32[ch_base + 0x04] = d mem32[ch_base + 0x08] = count ctrl = (DREQ_FORCE << 16) | (1 << 5) | (1 << 4) | (2 << 2) | 1 t0 = time.ticks_us() mem32[ch_base + 0x0C] = ctrl while mem32[ch_base + 0x08] != 0: pass t1 = time.ticks_us() print("dma copy:", time.ticks_diff(t1, t0), "us")

这里注意，DMA 计时从写入CTRL_TRIG开始，不包含配置寄存器的时间，这是公平的对比方式。

4.2 结果解读

在 RP2040 默认 125MHz 下，运行结果大概类似这样：

看到这个数据你就明白：DMA 和切片复制的真实耗时差距并没有传说中那么大，因为切片复制底层也是高效的 C 内存拷贝。DMA 真正的优势在于两点：

第一，它把搬运操作从 CPU 上卸载了，虽然本轮询等待也会让 CPU 空转，但如果你配合中断或异步逻辑，CPU 完全可以在 DMA 搬运的同时去跑其他任务。

第二，DMA 可以用来衔接外设和内存，比如 SPI 接收数据、PIO 输出波形，这些场景下 CPU 根本没法手动介入那么快的时钟节奏，DMA 是唯一靠谱方案。

4.3 什么时候别用 DMA

DMA 不是银弹。每次配置寄存器、等待完成是有固定开销的，如果只复制几十字节，用dst[:] = src可能更快也更简洁。判断标准很简单：

• 一次复制少于 256 字节，用切片复制；
• 单次复制几百字节但低频，也用切片复制；
• 大块数据 + 需要背靠背搬运 + 希望 CPU 腾出来干活，再上 DMA。

不要为了“用 DMA”而用 DMA，硬件资源是有限的，12 个通道真正繁忙时也要分配策略。

5. 常见问题与排查实录

5.1 问题速查表

5.2 最容易踩的两个坑

第一个坑就是边界检查。MicroPython 的bytearray是可变对象，DMA 不会管你对象的长度是多少，它只认你填进去的物理地址和计数。addressof拿到的是对象内部缓冲区的起始地址，一旦你TRANS_COUNT超过了缓冲区长度，DMA 就会越过边界读到相邻内存区域。这个行为不会报错，但会让你的数据莫名其妙变成垃圾，还会让调试过程异常痛苦。

第二个坑是缓冲区生命周期。我在测试时曾经把一个bytearray直接用在了dma_copy函数内部，结果函数返回后临时对象被 GC 回收，下一次使用 DMA 通道时地址已经指向不可用的内存。解决方案是确保 DMA 使用的缓冲区在传输期间一直被强引用持有，最简单的方法就是把它们定义成模块级变量或传给函数的外部变量。

5.3 验证数据的小技巧

调试 DMA 时不要整天看完整数据，太费眼睛。我喜欢这样验证：

# 写入固定值和模式 src = bytearray([0x11, 0x22, 0x33, 0x44] * 64) dst = bytearray(len(src)) dma_copy(dst, src) # 快速校验 print(dst[:32]) print(dst == src)

如果要确认大块数据没有错位，可以把dst打乱后做比对，或者用一个异或校验函数计算整个缓冲区的校验值，传给dma_copy之后再算一次目标区的校验值，两个值一致基本就说明搬运成功。

6. 进阶玩法：把 DMA 能力延伸到外设和后台

6.1 DMA + SPI/UART/OLED 刷新

内存到内存 DMA 只是第一层功夫，真正常用的是 DMA 和外设配合。以 SPI 发送为例，把TREQ_SEL设置成对应 SPI 的 DREQ 值，DMA 就会在 SPI 准备好接收数据时自动把内存数据搬给 SPI 发送寄存器，CPU 完全不用参与逐字节发送。

这套思路也可以延伸到 OLED 刷新：显存放在内存里，通过 DMA + SPI 刷到屏幕，MicroPython 主逻辑只负责更新显存内容，硬件自动搬运刷屏数据。对帧率有要求的场景，这个优化立竿见影。

6.2 链式 DMA 与缓冲区环形搬运

RP2040 的 DMA 支持链式传输，也就是一次传输完成后自动加载下一个通道的配置继续工作。配合双缓冲区可以做到完美拼接：DMA 在搬缓冲区 A 的时候，CPU 填充缓冲区 B，传输完成触发链式通道去搬 B，这样就能实现无间隙的连续数据流。

环形缓冲模式也很有意思，设置RING_SIZE后，地址递增到边界会自动回卷，非常适合 FIFO、音频环形队列这类场景。不过这两块都属于复杂功能，建议先把基础的内存到内存搬运练熟，再逐步尝试。

6.3 我的后续计划

就我个人而言，接下来准备把 DMA 搬到 PIO 场景里。RP2040 的 PIO 可以自定义时序，DMA 负责搬运数据，两者配合能实现很多花活。等到这套组合跑通，我再专门写一篇完整流程。现在先把本文的内存到内存版本用熟，你的 RP2040 数据搬运效率一定会有一个质变。