树莓派 Pico 跑 MicroPython日常写写 GPIO、传感器、小屏幕都挺顺手可一旦涉及大批量内存搬运比如从传感器缓冲拷数据、刷新显示缓冲、往 SPI 里塞一屏图像你大概率会有一种“这也太肉了”的感觉。Python 的 for 循环逐字节拷贝慢是原罪而且最要命的是 CPU 全程被占着外面来个中断还得等它搬完。这个局怎么破答案就是标题里那个词DMADirect Memory Access直接内存访问。这篇教程我打算不做任何保留从为什么需要 DMA 讲起带你把 RP2040 的 DMA 控制器寄存器逐个捋清楚再直接上手用 Micropython 的machine.mem32操作底层寄存器实现真正意义上的内存到内存mem2mem数据传输。你会看到一次完整的 1KB、64KB 数据搬运怎么写、怎么验证、怎么测速、有什么坑最后我会把中断、批量传输和几个容易翻车的疑难杂症一并聊掉。适合谁看适合刚入门树莓派 Pico、对 MicroPython 有一定了解、但还没碰过底层 DMA 的开发者也适合那些在其他单片机比如 STM32、ESP32-S3上写过 DMA想看看 RP2040 在 MicroPython 里怎么玩的工程师。内容偏底层但你只要初中数学水平就能跟上我会把寄存器和进制换算掰开揉碎地讲。1. 为什么需要 DMA内存搬运为什么要单独学1.1 从 CPU 逐字节拷贝到 DMA 搬运的思维转变先算一笔账。RP2040 是 Cortex-M0 双核主频 133MHz理论上每秒可以执行上亿条指令。但 MicroPython 的解释器跑在 Python 字节码层一条 Python 赋值语句可能要经过解释、对象查找、类型检查、字节码 dispatch 等一堆流程实际吞吐率远远到不了硬件的峰值。我在 Pico 上实测用纯 Python 循环把 64KB 数据从一块bytearray拷到另一块大概要花 40 到 60 毫秒。这个数字在交互式脚本里可能感觉不到但放到实时性要求高的场景里比如 240x240 的屏幕刷新一帧就要 100 多毫秒直接卡成幻灯片。而 DMA 控制器是硬件模块它有自己的总线接口负责按照你配置好的源地址、目标地址、传输长度和控制模式自动地把数据搬完全程不需要 CPU 逐条执行指令。RP2040 内部有 12 个 DMA 通道可以由软件触发也可以由外设事件触发还能在通道间串联chaining。内存到内存是最简单也最实用的一种你把源指针、目标指针、长度往寄存器里一填再用一个控制字“拉一下闸”DMA 就自己跑起来了CPU 可以去算别的、处理中断、甚至休眠等传输完成再回来看结果。你得知道DMA 不是“优化 Python 循环”的工具它改变的是整个系统的并发模型拷贝这件事从 CPU 的负担变成了硬件的外设行为。这就是为什么嵌入式里很多高性能驱动 —— 音频采集、显示刷新、串口收发、ADC 连续采样 —— 全都离不开 DMA。1.2 在 MicroPython 里操作 RP2040 DMA 的几种方案在 MicroPython 生态里要驱动 RP2040 的 DMA大体有三条路我按推荐程度排个序。第一种直接用machine.mem32读写 DMA 寄存器。这是最底层、最通用、也最可控的方式。寄存器的地址和位定义在 RP2040 数据手册里写得很清楚所有第三方封装底层其实都是这么干的。好处是你不依赖任何额外的库官方固件开箱即用而且这套寄存器操作方法放到其他带 DMA 的单片机上思路完全通用换型号只是换手册和地址的事。第二种找现成的 MicroPython DMA 库。GitHub 上确实有人做过rp2_dma、pico_dma之类的第三方封装有的还做成了uPy可导入的模块。但我个人的态度是如果是学习非常不建议上来就套库。很多库只封了某一种传输场景字节模式、长度对齐、通道复用、中断处理都可能藏着坑一旦出问题你没法 debug因为你根本没见过底层寄存器。把它们当成参考实现可以当成黑盒直接用会吃亏。第三种写 C 扩展或用 C 代码直接操作 DMA再通过 MicroPython 调用。Pico SDK 里面有完整的dma.h封装性能最好但开发和部署成本高需要交叉编译.mpy或.a不适用于大多数脚本化开发场景。而且既然我们能通过寄存器实现也就没必要为了一个 memcpy 去启动一套 C 工具链。所以这篇教程选第一种方案专治各种想搞懂底层的人。你把这套东西学会了以后再去看 PIO、I2S、SPI 传输发现全是同一个套路一通百通。2. 寄存器级 DMA 基础把 RP2040 的 DMA 手册读薄2.1 DMA 控制器的总体结构和地址布局RP2040 内部 SRAM 一共 264KB地址从0x20000000开始。DMA 控制器作为一个 AHB 主设备可以直接读写这块内存区域也可以读写各个外设的 FIFO 数据寄存器比如 SPI、UART、I2S、PIO 的收发缓冲区。我们做内存到内存传输只需要知道源地址和目标地址都落在 SRAM 或外设缓冲区地址范围里就行不需要申请什么特殊内存。RP2040 的 DMA 控制器编号为 CH0 到 CH11一共 12 个通道每个通道的寄存器组尺寸是0x4064 字节。通道 0 的基址就是 DMA 控制器的基址0x50000000通道 1 就是0x50000040以此类推。这片区域可直接用machine.mem32[地址]访问。通道 0 的 4 个核心寄存器地址和用途我给你列个表后面所有代码都靠这几个地址干活。寄存器通道0地址作用READ_ADDR0x50000000读取的源内存地址WRITE_ADDR0x50000004写入的目标内存地址TRANS_COUNT0x50000008待传输的数据元素数量启动后递减到 0CTRL_TRIG0x5000000C控制配置字写入后立即触发传输注意DMA 传输的计数单位是“数据元素数量”不是字节数。你在字节模式下可以把它理解为字节数但字模式下就是字数。这个细节我在踩坑章节会重点展开。2.2 CTRL_TRIG 里最关键的几个控制位CTRL_TRIG 是一个 32 位寄存器既有配置功能又有触发功能是 DMA 操作的核心。MicroPython 里写这个寄存器的最低一个字也就是整个 32 位就会触发传输。对内存到内存来说我不需要把每一位都背下来但你至少要清楚下面这几个关键位。位段名称作用bit0EN1 使能并启动传输传输完成后硬件自动清零bits[3:2]SIZE0 字节1 半字16bit2 字32bitbit4INCR_WRITE1 表示每次传输后写地址递增0 表示固定地址bit5INCR_READ1 表示每次传输后读地址递增0 表示固定地址bit8DREQ_EN0 表示由软件触发不依赖外设请求mem2mem 必须为 0bits[24:21]CHAIN_TO链式传输的下一个通道号不用链式就写 0bit31AHB_ERROR总线错误时硬件置位软件可以读取判断是否出错这里我画个重点mem2mem 传输务必把 DREQ_EN 设置成 0。DREQ_EN 是“外设数据请求使能”位如果置 1DMA 会等待外设 DREQ 信号不会立刻开始搬数据。很多新手困惑“我明明写了 CTRL_TRIG 为什么 DMA 不动”十有八九是这里设错了。另外一个值得花时间理解的是 SIZE 和 INCR 的组合。SIZE 决定 DMA 一次搬运几个字节INCR 决定源地址或目标地址是否步进递增。比如你要把一块bytearray完整复制到另一块应该选择 SIZE0字节、INCR_READ1、INCR_WRITE1这样源和目标都一个字节一个字节地往前走直到 TRANS_COUNT 减到零。改成 SIZE232 位字后源和目标都按 4 字节步进性能和总线效率更高但要求缓冲区首地址天然 4 字节对齐总长度也必须是 4 的倍数。2.3 mem2mem 和外设触发方式的简单区分除了软件触发把 CTRL_TRIG 写一次就启动DMA 通道还可以配置成由外设事件触发比如 UART 收到数据、SPI 发送 FIFO 有空位、PIO 状态机产生数据DMA 就会被“拉一把”然后搬一定数量的数据。这种模式下 DREQ_EN 要置 1同时 TREQ_SEL 选对应的外设请求线。本篇教程专注软件触发的 mem2mem但后面第 5 章我会提一提外设触发的配置要点方便你以后扩展到串口 DMA 接收、SPI 刷屏这类应用。3. 保姆级实操MicroPython 里让 DMA 跑起来3.1 环境准备与基础验证硬件方面就一块树莓派 Pico 或 Pico WMicroPython 固件建议刷到 1.20 以上我用的版本是 1.23实测没问题。固件刷机很简单按住 Pico 上的 BOOTSEL 键插 USB把下载好的.uf2文件拖进出现的移动盘自动重启后固件就写好了。连接方面用 Thonny 或任何串口终端都可以我习惯用screen /dev/ttyACM0 115200在 Windows 上推荐用 Thonny方便直接跑代码看输出。先验证一下你的固件和machine.mem32import sys, machine print(sys.implementation) print(mem32 is, machine.mem32)如果能看到版本信息并且mem32没有报错说明环境没问题。machine.mem32是 MicroPython 暴露的 32 位内存读写接口它把地址当作下标写一个整数进去就完成 32 位写入读一个地址就返回 32 位整数值。3.2 分配源/目标缓冲区并取得内存地址MicroPython 里的bytearray是一段连续内存ctypes.addressof()可以拿到它在内存中的物理地址。很多 Python 程序员听到“拿地址”可能会觉得是非法操作但嵌入式 MicroPython 里这是常规手段因为 DMA 要的就是裸地址。import ctypes BLOCK 1024 src bytearray(BLOCK) dst bytearray(BLOCK) # 给源缓冲区填上测试数据 for i in range(BLOCK): src[i] i 0xFF # 目标先把 0xAA 填满一会用来验证 for i in range(BLOCK): dst[i] 0xAA src_addr ctypes.addressof(src) dst_addr ctypes.addressof(dst) print(src addr:, hex(src_addr)) print(dst addr:, hex(dst_addr)) print(expect src[0..3]:, src[0], src[1], src[2], src[3])输出里你会看到类似0x2000xxxx的地址这就是 SRAM 的真实地址很好认。这里有一个 MicroPython 的特性你可能需要知道它的 GC垃圾回收是非移动式的意思是对象一旦分配地址在它存活期间不会因为 GC 被搬走。所以就这个应用场景来说用ctypes.addressof()拿地址是安全的。如果实在怕某些 fork 固件动了 GC 策略可以在传输期间调用gc.lock()锁住垃圾回收传完再gc.unlock()。提示不要用id()去拿地址id()返回的是对象标识符虽然有些 MicroPython 版本里它恰好等于地址但这是实现细节不能依赖。ctypes.addressof()才是官方、可靠的方式。3.3 第一次 DMA 传输搬运 1KB 字节数据现在开始动真格。我们要配置通道 0把 src 里的 1024 个字节搬到 dst。按照寄存器规范先写源地址再写目标地址再写传输计数最后写控制触发字。为什么顺序不能乱因为 CTRL_TRIG 一旦被写入DMA 就可能立即启动如果你还没把地址和长度写好DMA 就会用之前的脏数据去搬轻则搬错重则 AHB 总线错误。所以规矩是最后再写 CTRL_TRIG。DMA_BASE 0x50000000 CH0_READ_ADDR DMA_BASE 0x00 CH0_WRITE_ADDR DMA_BASE 0x04 CH0_TRANS_COUNT DMA_BASE 0x08 CH0_CTRL_TRIG DMA_BASE 0x0C # 先往目标里写 0xAA便于观察是否被覆盖 for i in range(BLOCK): dst[i] 0xAA # 1) 写源地址 machine.mem32[CH0_READ_ADDR] src_addr # 2) 写目标地址 machine.mem32[CH0_WRITE_ADDR] dst_addr # 3) 写搬运元素数量字节模式下就是字节数 machine.mem32[CH0_TRANS_COUNT] BLOCK # 4) 配置控制字并触发 # bit0 EN1 # bit5 INCR_READ1 # bit4 INCR_WRITE1 # 其余位保持 0DREQ_EN0SIZE0字节模式 ctrl (1 0) | (1 4) | (1 5) machine.mem32[CH0_CTRL_TRIG] ctrl # 等待完成EN 位会被硬件自动清零 while machine.mem32[CH0_CTRL_TRIG] 0x01: pass if machine.mem32[CH0_CTRL_TRIG] 0x80000000: print(AHB error! Address error or bus error.) else: print(dma done, equal:, bytes(dst) bytes(src))这段代码跑完如果输出dma done, equal: True恭喜你你的 Pico 已经在 MicroPython 里完成了第一次 DMA mem2mem 搬运。我们来复盘一下这里控制字ctrl等于二进制的0b00110001换算成十六进制就是0x31。bit1 被忽略了bit2 和 bit3 是 SIZE都为 0所以是字节模式bit4、bit5 置 1地址递增bit0 置 1启动传输。DREQ_ENbit8是 0因此 DMA 不需要等外设请求直接开始搬。等待完成的方式是不断读CTRL_TRIG这个寄存器检查最低位 EN。启动瞬间 EN1传输完成时硬件自动把它清掉于是循环退出。有的资料会教你读 AL1_CTRL 或 BUSY 位在这个场景下 EN 位是最直观的我一直这么用稳定可靠。3.4 进阶32 位字传输与对齐问题字节模式什么都能搬但效率不如 32 位字模式。原因是 DMA 每次搬运的总线事务越大单位时间搬的数据越多你如果每次都只搬 1 字节带宽会被大大浪费。在 RP2040 上做 64KB 数据搬运我会优先切到 SIZE2 的字模式。字模式有几个硬性前提一是源地址和目标地址都必须 4 字节对齐二是传输的元素数量要按“字”来计算三是 TRANS_COUNT 填的应该是总字节数除以 4。你可以用array(I)来创建天然的 32 位数组它保证元素按 4 字节对齐。from array import array import time N_WORDS 64 * 1024 // 4 # 64KB按字算就是 16384 个字 src_w array(I, range(N_WORDS)) dst_w array(I, [0]) * N_WORDS src_w_addr ctypes.addressof(src_w) dst_w_addr ctypes.addressof(dst_w) print(src_w addr:, hex(src_w_addr), aligned:, src_w_addr % 4 0) print(dst_w addr:, hex(dst_w_addr), aligned:, dst_w_addr % 4 0) # 字模式下TRANS_COUNT 是字数 machine.mem32[CH0_READ_ADDR] src_w_addr machine.mem32[CH0_WRITE_ADDR] dst_w_addr machine.mem32[CH0_TRANS_COUNT] N_WORDS # SIZE2即 bits[3:2] 0b10 ctrl (1 0) | (2 2) | (1 4) | (1 5) machine.mem32[CH0_CTRL_TRIG] ctrl while machine.mem32[CH0_CTRL_TRIG] 0x01: pass print(word dma done, equal:, bytes(dst_w) bytes(src_w))控制字算一下(1 0) | (2 2) | (1 4) | (1 5)1 8 16 32 57十六进制就是0x39。跟字节模式0x31对比就差在 SIZE 那两位。我在第一次跑这个代码时犯过傻TRANS_COUNT 直接填了64 * 1024结果 DMA 从数组内存后面多读了很多数据还好 SRAM 没有立刻死机但读出来的数据完全不对。这就是我前面说的字模式下计数单位是字不是字节。你用array(I)时最好直接len(src_w)拿元素个数而不是len(src_w) * 4。3.5 实测性能DMA 到底比 Python 快多少数字最有说服力。在 133MHz 的 RP2040 上我用time.ticks_us()做了一次不严谨但方向明确的测速搬运 64KB 数据分别用纯 Python 循环和 DMA 字模式t0 time.ticks_us() for i in range(len(src_big)): dst_big[i] src_big[i] t1 time.ticks_us() print(python loop us:, time.ticks_diff(t1, t0)) t0 time.ticks_us() # 这里假设已经配置好寄存器只触发一次 DMA machine.mem32[CH0_CTRL_TRIG] 0x39 while machine.mem32[CH0_CTRL_TRIG] 0x01: pass t1 time.ticks_us() print(dma us:, time.ticks_diff(t1, t0))在我板子上Python 循环大约 40 到 60 毫秒DMA 字模式加上 MicroPython 调用开销基本在 1 到 3 毫秒。这个差距背后是架构层面的原因Python 循环是解释器逐条执行每执行一次dst_big[i] src_big[i]都要经历字节码处理、边界检查、对象引用DMA 则是硬件模块以总线事务为单位吞吐只需要初始化时“说一次”搬多长。所以结论很简单大批量内存拷贝别用 Python 写循环DMA 快一个数量级甚至更多。4. 性能实测与异步思维DMA 的价值不只是快4.1 同样的数据量Python 循环 vs DMA 的差距在哪里前面测速直接对比了纯 Python 循环和 DMA 的耗时但这里我想再深挖一层DMA 的加速并不全是因为“硬件搬得比 CPU 快”。RP2040 的 DMA 本身工作在系统时钟下理论上你手动写汇编 unroll 循环也能搬得很快真正的原因在于 DMA 释放了 CPU 的每一条指令周期。你用 Python 循环时CPU 每搬一个字节都要同时负担解释器的开销用 DMA 时CPU 只需要花几百微秒做配置和查询剩下的时间完全空闲下来。就好比你要把十个箱子从一楼搬到二楼。自己爬楼搬每一步都要你亲自走叫一台电梯搬你在楼下按个按钮剩下的时间可以去写报表。这就是“异步”的价值。4.2 别让 CPU 干等启动 DMA 后继续执行其他任务我前面所有代码都在轮询 EN 位这其实还是同步等待CPU 在整个传输期间没法干别的事只是等待方式省了逐字节的手工搬运。真正发挥 DMA 优势的用法是启动之后让 CPU 去做其他计算回来再看结果。def dma_start_memcpy(dst, src, nbytes, channel0): base DMA_BASE channel * 0x40 machine.mem32[base 0x00] ctypes.addressof(src) machine.mem32[base 0x04] ctypes.addressof(dst) machine.mem32[base 0x08] nbytes # 默认按字节模式触发 machine.mem32[base 0x0C] 0x31 # 启动 64KB 传输后不等待先去算点东西 dma_start_memcpy(dst_big, src_big, len(src_big)) dummy 0 for i in range(10000): dummy i # 回来检查传输是否完成 while machine.mem32[CH0_CTRL_TRIG] 0x01: pass print(dma finished, dummy value:, dummy)这个模式特别适合音频、图像处理流水线ADC 采样数据进 DMA → CPU 处理前一段 → DMA 已经把后一段准备好 → CPU 再来拿两块缓冲交替使用。你不需要自己写memcpy硬件已经把数据按你的预期放好了。5. 从“能跑”到“实用”中断批量与疑难杂症5.1 用 DMA 中断标志代替忙等轮询 EN 位虽然简单但它在整个传输过程中把 CPU 绑死在循环里和同步等待没本质区别。如果希望 CPU 在传输期间彻底去睡或处理其他任务更专业的做法是使用 DMA 中断标志。RP2040 的 DMA 控制器有一个总中断状态寄存器INTR地址0x50000400每通道完成传输时会把对应位置 1另外还有INTE0地址0x50000404用于使能对应通道向 Cortex-M0 的中断线输出。MicroPython 里挂硬件中断回调也可以但在简单场景下我更推荐先用INTR的轮询标志因为它不依赖回调环境逻辑更可控INTR 0x50000400 INTE0 0x50000404 # 使能通道 0 中断状态输出 machine.mem32[INTE0] 1 dma_start_memcpy(dst_big, src_big, len(src_big)) # 一边干别的一边等 INTR 置 1 while not (machine.mem32[INTR] 0x01): pass print(INTR raised, DMA finished)比忙等 EN 位更强的地方在于INTR位在传输完成瞬间被硬件置位不会受到 MicroPython 解释器调度的影响而 EN 位清零和INTR置位在时序上是一样的只是你读取的目标寄存器不同。真要完全异步可以在这里配合machine.disable_irq()或注册回调去打断主循环但那是另一个话题了。5.2 批量搬运的思路链式通道和多段拷贝有时候你要连续搬运好几段数据比如把内存里两个不同来源的缓冲拼接到一起。你可以来回触发单通道但 RP2040 DMA 还提供了链式传输 CHAIN_TO 特性一个通道传输完成后自动去触发另一个通道。CTRL_TRIG 的CHAIN_TO字段就是干这个的把通道 0 的 CHAIN_TO 设置成通道 1通道 1 的 CHAIN_TO 设置成通道 2你只要触发通道 0整个链条就会按顺序执行。在 MicroPython 里配置多个通道并不复杂每个通道基址差0x40封装一个带通道号的启动函数即可。我上面dma_start_memcpy函数已经带了channel参数你可以为每次待搬运的数据段分别配置不同通道再把 CHAIN_TO 串起来这样一次触发就能搬完一整串缓冲区。链式的细节和中断联动用起来比较绕三言两语说不完我以后的教程会专门开一篇这里你先知道有这回事。5.3 新手最容易踩的 5 个坑我把这段时间在 MicroPython DMA 上遇到的和看见别人踩过的坑整理成一张表每一行都是血泪教训。现象原因排查/解决配置完 CTRL_TRIG 后 DMA 不启动DREQ_EN 被错误置 1DMA 在等外设请求确保 bit8 为 0CTRL 值用 0x31 或 0x39数据搬完但内容完全不对TRANS_COUNT 填错单位字模式下填了字节数字模式下传len(src_w)不要乘 4字模式一跑就报 AHB_ERROR源或目标地址不是 4 字节对齐用array(I)代替bytearray检查地址% 4 0DMA 运行期间 Python 崩溃或 HC传输未结束就修改/释放了缓冲区等 EN 位清零后再改 src/dst或锁 GC 防止对象销毁结果全是第一个字节的内容忘了设 INCR_READ 或 INCR_WRITE地址没有递增确认 bit4、bit5 都置 1这五个坑里最隐蔽的是缓冲区生命周期问题。MicroPython 里如果你用一个局部变量tmp bytearray(1024)启动 DMA同时在 DMA 还没搬完时函数返回这个bytearray可能被 GC 回收内存被重新分配给别人。DMA 往已释放的内存里写轻则数据错乱重则写坏堆结构导致 Crash。我的习惯是所有 DMA 用到的源和目的一律放在模块级全局变量或者在函数里启动前gc.lock()传完再解锁。5.4 多通道并行传输一个通道不够用怎么办RP2040 有 12 个 DMA 通道但并非所有场景都需要同时开多个。真正需要多通道的时候比如一边要 ADC 采集数据另一边要 SPI 刷新屏幕这时两个通道可以互不干扰地独立工作。在 MicroPython 里只需要把通道号传入基址计算不同的寄存器位置即可我把函数再升级一下def dma_start_ch(channel, dst, src, nbytes, size0): base DMA_BASE channel * 0x40 machine.mem32[base 0x00] ctypes.addressof(src) machine.mem32[base 0x04] ctypes.addressof(dst) machine.mem32[base 0x08] nbytes ctrl 0x01 | (0x10 if True else 0) | (0x20 if True else 0) | ((size 0x3) 2) machine.mem32[base 0x0C] ctrl这个函数里我把 SIZE 参数暴露出来默认字节模式。批量场景下你可以分别配置通道 1、通道 2然后在主循环里统一查询多个通道的 EN 位直到全部归零。注意通道是独立资源同一通道在传输完成前不要重复触发否则寄存器会被第二次配置覆盖乱成一片。6. 扩展思路这套 DMA 操作能用在哪些场景6.1 从 mem2mem 到外设传输OLED 刷新、串口收发、ADC 采样的共同套路内存到内存是 DMA 的一种特殊形态但它背后那套“配置寄存器 最后触发”的套路在外设传输里完全通用。举个例子你想给 SPI 接口的 OLED 刷一屏图像如果只用 Python 往 SPI 读写缓冲区里逐字节写一帧 1024x8 的数据都能卡到人麻如果配置一个 DMA 通道把源地址指向图像缓冲区目标地址指向 SPI 的 TX FIFO 数据寄存器大小设为显存长度触发一次DMA 就自己按 FIFO 的节奏把一屏图像送过去了CPU 全程只负责上下帧的预处理。RP2040 的 SPI0 基址是0x4003C000SPI1 是0x40040000FIFO 数据寄存器是0x04偏移这个配置和 mem2mem 唯一的区别就是把 WRITE_ADDR 从 SRAM 地址换成了 FIFO 地址同时 DREQ_EN 要置 1TREQ_SEL 选 SPI 的 DREQ 编号。串口 DMA 接收不定长数据也可以套这个思路DMA 把 UART RX FIFO 里的数据搬到内存缓冲区配合空闲中断判断一帧数据结束这在 STM32 生态里是标准用法在 RP2040 上同样成立。你一旦明白了 DMA 只是在“源地址-目标地址”之间按指定长度搬运就会意识到所谓外设传输不过是把某一端地址换成外设 FIFO 而已。6.2 其他芯片上的 MicroPython DMA思路可复制如果你手头也有 ESP32-S3 这类开发板会发现在 MicroPython 里虽然没有完全统一的 DMA 标准 API但寄存器操作的思路是一样的。ESP32-S3 的 GDMA 控制器地址、描述符格式和 RP2040 不同但核心要素仍然相同源地址、目标地址、传输长度、控制位、触发方式。你带着 RP2040 这套经验去看 ESP32-S3 的GDMA章节会感觉像是换了一种方言写同一句问候语上手速度快得多。所以我不建议把这篇教程当成“Pico 专属技巧”它其实是一种方法论当你需要在 MicroPython 里处理性能敏感的数据搬运与其到处找第三方库不如翻开芯片手册找到 DMA 寄存器那一章用machine.mem32直接说话。这不一定是最快的开发路径但一定是你最能掌控全局的路径。我个人在实际操作中的体会是这样的第一次看到 EN 位清零、两块内存内容完全一致的瞬间那种“我绕过解释器直接碰硬件”的满足感比跑通任何高级库都强烈。后来我无论做 OLED 刷屏、音频采集还是给 PIO 数据写 DMA 缓冲都靠这套基本功兜底。这篇教程只是一个开始你真正把 DMA 用顺之后会时不时想起那句老话硬件能替你干的活就别让 CPU 熬夜。 树莓派Pico MicroPython底层DMA内存搬运实战
树莓派 Pico 跑 MicroPython日常写写 GPIO、传感器、小屏幕都挺顺手可一旦涉及大批量内存搬运比如从传感器缓冲拷数据、刷新显示缓冲、往 SPI 里塞一屏图像你大概率会有一种“这也太肉了”的感觉。Python 的 for 循环逐字节拷贝慢是原罪而且最要命的是 CPU 全程被占着外面来个中断还得等它搬完。这个局怎么破答案就是标题里那个词DMADirect Memory Access直接内存访问。这篇教程我打算不做任何保留从为什么需要 DMA 讲起带你把 RP2040 的 DMA 控制器寄存器逐个捋清楚再直接上手用 Micropython 的machine.mem32操作底层寄存器实现真正意义上的内存到内存mem2mem数据传输。你会看到一次完整的 1KB、64KB 数据搬运怎么写、怎么验证、怎么测速、有什么坑最后我会把中断、批量传输和几个容易翻车的疑难杂症一并聊掉。适合谁看适合刚入门树莓派 Pico、对 MicroPython 有一定了解、但还没碰过底层 DMA 的开发者也适合那些在其他单片机比如 STM32、ESP32-S3上写过 DMA想看看 RP2040 在 MicroPython 里怎么玩的工程师。内容偏底层但你只要初中数学水平就能跟上我会把寄存器和进制换算掰开揉碎地讲。1. 为什么需要 DMA内存搬运为什么要单独学1.1 从 CPU 逐字节拷贝到 DMA 搬运的思维转变先算一笔账。RP2040 是 Cortex-M0 双核主频 133MHz理论上每秒可以执行上亿条指令。但 MicroPython 的解释器跑在 Python 字节码层一条 Python 赋值语句可能要经过解释、对象查找、类型检查、字节码 dispatch 等一堆流程实际吞吐率远远到不了硬件的峰值。我在 Pico 上实测用纯 Python 循环把 64KB 数据从一块bytearray拷到另一块大概要花 40 到 60 毫秒。这个数字在交互式脚本里可能感觉不到但放到实时性要求高的场景里比如 240x240 的屏幕刷新一帧就要 100 多毫秒直接卡成幻灯片。而 DMA 控制器是硬件模块它有自己的总线接口负责按照你配置好的源地址、目标地址、传输长度和控制模式自动地把数据搬完全程不需要 CPU 逐条执行指令。RP2040 内部有 12 个 DMA 通道可以由软件触发也可以由外设事件触发还能在通道间串联chaining。内存到内存是最简单也最实用的一种你把源指针、目标指针、长度往寄存器里一填再用一个控制字“拉一下闸”DMA 就自己跑起来了CPU 可以去算别的、处理中断、甚至休眠等传输完成再回来看结果。你得知道DMA 不是“优化 Python 循环”的工具它改变的是整个系统的并发模型拷贝这件事从 CPU 的负担变成了硬件的外设行为。这就是为什么嵌入式里很多高性能驱动 —— 音频采集、显示刷新、串口收发、ADC 连续采样 —— 全都离不开 DMA。1.2 在 MicroPython 里操作 RP2040 DMA 的几种方案在 MicroPython 生态里要驱动 RP2040 的 DMA大体有三条路我按推荐程度排个序。第一种直接用machine.mem32读写 DMA 寄存器。这是最底层、最通用、也最可控的方式。寄存器的地址和位定义在 RP2040 数据手册里写得很清楚所有第三方封装底层其实都是这么干的。好处是你不依赖任何额外的库官方固件开箱即用而且这套寄存器操作方法放到其他带 DMA 的单片机上思路完全通用换型号只是换手册和地址的事。第二种找现成的 MicroPython DMA 库。GitHub 上确实有人做过rp2_dma、pico_dma之类的第三方封装有的还做成了uPy可导入的模块。但我个人的态度是如果是学习非常不建议上来就套库。很多库只封了某一种传输场景字节模式、长度对齐、通道复用、中断处理都可能藏着坑一旦出问题你没法 debug因为你根本没见过底层寄存器。把它们当成参考实现可以当成黑盒直接用会吃亏。第三种写 C 扩展或用 C 代码直接操作 DMA再通过 MicroPython 调用。Pico SDK 里面有完整的dma.h封装性能最好但开发和部署成本高需要交叉编译.mpy或.a不适用于大多数脚本化开发场景。而且既然我们能通过寄存器实现也就没必要为了一个 memcpy 去启动一套 C 工具链。所以这篇教程选第一种方案专治各种想搞懂底层的人。你把这套东西学会了以后再去看 PIO、I2S、SPI 传输发现全是同一个套路一通百通。2. 寄存器级 DMA 基础把 RP2040 的 DMA 手册读薄2.1 DMA 控制器的总体结构和地址布局RP2040 内部 SRAM 一共 264KB地址从0x20000000开始。DMA 控制器作为一个 AHB 主设备可以直接读写这块内存区域也可以读写各个外设的 FIFO 数据寄存器比如 SPI、UART、I2S、PIO 的收发缓冲区。我们做内存到内存传输只需要知道源地址和目标地址都落在 SRAM 或外设缓冲区地址范围里就行不需要申请什么特殊内存。RP2040 的 DMA 控制器编号为 CH0 到 CH11一共 12 个通道每个通道的寄存器组尺寸是0x4064 字节。通道 0 的基址就是 DMA 控制器的基址0x50000000通道 1 就是0x50000040以此类推。这片区域可直接用machine.mem32[地址]访问。通道 0 的 4 个核心寄存器地址和用途我给你列个表后面所有代码都靠这几个地址干活。寄存器通道0地址作用READ_ADDR0x50000000读取的源内存地址WRITE_ADDR0x50000004写入的目标内存地址TRANS_COUNT0x50000008待传输的数据元素数量启动后递减到 0CTRL_TRIG0x5000000C控制配置字写入后立即触发传输注意DMA 传输的计数单位是“数据元素数量”不是字节数。你在字节模式下可以把它理解为字节数但字模式下就是字数。这个细节我在踩坑章节会重点展开。2.2 CTRL_TRIG 里最关键的几个控制位CTRL_TRIG 是一个 32 位寄存器既有配置功能又有触发功能是 DMA 操作的核心。MicroPython 里写这个寄存器的最低一个字也就是整个 32 位就会触发传输。对内存到内存来说我不需要把每一位都背下来但你至少要清楚下面这几个关键位。位段名称作用bit0EN1 使能并启动传输传输完成后硬件自动清零bits[3:2]SIZE0 字节1 半字16bit2 字32bitbit4INCR_WRITE1 表示每次传输后写地址递增0 表示固定地址bit5INCR_READ1 表示每次传输后读地址递增0 表示固定地址bit8DREQ_EN0 表示由软件触发不依赖外设请求mem2mem 必须为 0bits[24:21]CHAIN_TO链式传输的下一个通道号不用链式就写 0bit31AHB_ERROR总线错误时硬件置位软件可以读取判断是否出错这里我画个重点mem2mem 传输务必把 DREQ_EN 设置成 0。DREQ_EN 是“外设数据请求使能”位如果置 1DMA 会等待外设 DREQ 信号不会立刻开始搬数据。很多新手困惑“我明明写了 CTRL_TRIG 为什么 DMA 不动”十有八九是这里设错了。另外一个值得花时间理解的是 SIZE 和 INCR 的组合。SIZE 决定 DMA 一次搬运几个字节INCR 决定源地址或目标地址是否步进递增。比如你要把一块bytearray完整复制到另一块应该选择 SIZE0字节、INCR_READ1、INCR_WRITE1这样源和目标都一个字节一个字节地往前走直到 TRANS_COUNT 减到零。改成 SIZE232 位字后源和目标都按 4 字节步进性能和总线效率更高但要求缓冲区首地址天然 4 字节对齐总长度也必须是 4 的倍数。2.3 mem2mem 和外设触发方式的简单区分除了软件触发把 CTRL_TRIG 写一次就启动DMA 通道还可以配置成由外设事件触发比如 UART 收到数据、SPI 发送 FIFO 有空位、PIO 状态机产生数据DMA 就会被“拉一把”然后搬一定数量的数据。这种模式下 DREQ_EN 要置 1同时 TREQ_SEL 选对应的外设请求线。本篇教程专注软件触发的 mem2mem但后面第 5 章我会提一提外设触发的配置要点方便你以后扩展到串口 DMA 接收、SPI 刷屏这类应用。3. 保姆级实操MicroPython 里让 DMA 跑起来3.1 环境准备与基础验证硬件方面就一块树莓派 Pico 或 Pico WMicroPython 固件建议刷到 1.20 以上我用的版本是 1.23实测没问题。固件刷机很简单按住 Pico 上的 BOOTSEL 键插 USB把下载好的.uf2文件拖进出现的移动盘自动重启后固件就写好了。连接方面用 Thonny 或任何串口终端都可以我习惯用screen /dev/ttyACM0 115200在 Windows 上推荐用 Thonny方便直接跑代码看输出。先验证一下你的固件和machine.mem32import sys, machine print(sys.implementation) print(mem32 is, machine.mem32)如果能看到版本信息并且mem32没有报错说明环境没问题。machine.mem32是 MicroPython 暴露的 32 位内存读写接口它把地址当作下标写一个整数进去就完成 32 位写入读一个地址就返回 32 位整数值。3.2 分配源/目标缓冲区并取得内存地址MicroPython 里的bytearray是一段连续内存ctypes.addressof()可以拿到它在内存中的物理地址。很多 Python 程序员听到“拿地址”可能会觉得是非法操作但嵌入式 MicroPython 里这是常规手段因为 DMA 要的就是裸地址。import ctypes BLOCK 1024 src bytearray(BLOCK) dst bytearray(BLOCK) # 给源缓冲区填上测试数据 for i in range(BLOCK): src[i] i 0xFF # 目标先把 0xAA 填满一会用来验证 for i in range(BLOCK): dst[i] 0xAA src_addr ctypes.addressof(src) dst_addr ctypes.addressof(dst) print(src addr:, hex(src_addr)) print(dst addr:, hex(dst_addr)) print(expect src[0..3]:, src[0], src[1], src[2], src[3])输出里你会看到类似0x2000xxxx的地址这就是 SRAM 的真实地址很好认。这里有一个 MicroPython 的特性你可能需要知道它的 GC垃圾回收是非移动式的意思是对象一旦分配地址在它存活期间不会因为 GC 被搬走。所以就这个应用场景来说用ctypes.addressof()拿地址是安全的。如果实在怕某些 fork 固件动了 GC 策略可以在传输期间调用gc.lock()锁住垃圾回收传完再gc.unlock()。提示不要用id()去拿地址id()返回的是对象标识符虽然有些 MicroPython 版本里它恰好等于地址但这是实现细节不能依赖。ctypes.addressof()才是官方、可靠的方式。3.3 第一次 DMA 传输搬运 1KB 字节数据现在开始动真格。我们要配置通道 0把 src 里的 1024 个字节搬到 dst。按照寄存器规范先写源地址再写目标地址再写传输计数最后写控制触发字。为什么顺序不能乱因为 CTRL_TRIG 一旦被写入DMA 就可能立即启动如果你还没把地址和长度写好DMA 就会用之前的脏数据去搬轻则搬错重则 AHB 总线错误。所以规矩是最后再写 CTRL_TRIG。DMA_BASE 0x50000000 CH0_READ_ADDR DMA_BASE 0x00 CH0_WRITE_ADDR DMA_BASE 0x04 CH0_TRANS_COUNT DMA_BASE 0x08 CH0_CTRL_TRIG DMA_BASE 0x0C # 先往目标里写 0xAA便于观察是否被覆盖 for i in range(BLOCK): dst[i] 0xAA # 1) 写源地址 machine.mem32[CH0_READ_ADDR] src_addr # 2) 写目标地址 machine.mem32[CH0_WRITE_ADDR] dst_addr # 3) 写搬运元素数量字节模式下就是字节数 machine.mem32[CH0_TRANS_COUNT] BLOCK # 4) 配置控制字并触发 # bit0 EN1 # bit5 INCR_READ1 # bit4 INCR_WRITE1 # 其余位保持 0DREQ_EN0SIZE0字节模式 ctrl (1 0) | (1 4) | (1 5) machine.mem32[CH0_CTRL_TRIG] ctrl # 等待完成EN 位会被硬件自动清零 while machine.mem32[CH0_CTRL_TRIG] 0x01: pass if machine.mem32[CH0_CTRL_TRIG] 0x80000000: print(AHB error! Address error or bus error.) else: print(dma done, equal:, bytes(dst) bytes(src))这段代码跑完如果输出dma done, equal: True恭喜你你的 Pico 已经在 MicroPython 里完成了第一次 DMA mem2mem 搬运。我们来复盘一下这里控制字ctrl等于二进制的0b00110001换算成十六进制就是0x31。bit1 被忽略了bit2 和 bit3 是 SIZE都为 0所以是字节模式bit4、bit5 置 1地址递增bit0 置 1启动传输。DREQ_ENbit8是 0因此 DMA 不需要等外设请求直接开始搬。等待完成的方式是不断读CTRL_TRIG这个寄存器检查最低位 EN。启动瞬间 EN1传输完成时硬件自动把它清掉于是循环退出。有的资料会教你读 AL1_CTRL 或 BUSY 位在这个场景下 EN 位是最直观的我一直这么用稳定可靠。3.4 进阶32 位字传输与对齐问题字节模式什么都能搬但效率不如 32 位字模式。原因是 DMA 每次搬运的总线事务越大单位时间搬的数据越多你如果每次都只搬 1 字节带宽会被大大浪费。在 RP2040 上做 64KB 数据搬运我会优先切到 SIZE2 的字模式。字模式有几个硬性前提一是源地址和目标地址都必须 4 字节对齐二是传输的元素数量要按“字”来计算三是 TRANS_COUNT 填的应该是总字节数除以 4。你可以用array(I)来创建天然的 32 位数组它保证元素按 4 字节对齐。from array import array import time N_WORDS 64 * 1024 // 4 # 64KB按字算就是 16384 个字 src_w array(I, range(N_WORDS)) dst_w array(I, [0]) * N_WORDS src_w_addr ctypes.addressof(src_w) dst_w_addr ctypes.addressof(dst_w) print(src_w addr:, hex(src_w_addr), aligned:, src_w_addr % 4 0) print(dst_w addr:, hex(dst_w_addr), aligned:, dst_w_addr % 4 0) # 字模式下TRANS_COUNT 是字数 machine.mem32[CH0_READ_ADDR] src_w_addr machine.mem32[CH0_WRITE_ADDR] dst_w_addr machine.mem32[CH0_TRANS_COUNT] N_WORDS # SIZE2即 bits[3:2] 0b10 ctrl (1 0) | (2 2) | (1 4) | (1 5) machine.mem32[CH0_CTRL_TRIG] ctrl while machine.mem32[CH0_CTRL_TRIG] 0x01: pass print(word dma done, equal:, bytes(dst_w) bytes(src_w))控制字算一下(1 0) | (2 2) | (1 4) | (1 5)1 8 16 32 57十六进制就是0x39。跟字节模式0x31对比就差在 SIZE 那两位。我在第一次跑这个代码时犯过傻TRANS_COUNT 直接填了64 * 1024结果 DMA 从数组内存后面多读了很多数据还好 SRAM 没有立刻死机但读出来的数据完全不对。这就是我前面说的字模式下计数单位是字不是字节。你用array(I)时最好直接len(src_w)拿元素个数而不是len(src_w) * 4。3.5 实测性能DMA 到底比 Python 快多少数字最有说服力。在 133MHz 的 RP2040 上我用time.ticks_us()做了一次不严谨但方向明确的测速搬运 64KB 数据分别用纯 Python 循环和 DMA 字模式t0 time.ticks_us() for i in range(len(src_big)): dst_big[i] src_big[i] t1 time.ticks_us() print(python loop us:, time.ticks_diff(t1, t0)) t0 time.ticks_us() # 这里假设已经配置好寄存器只触发一次 DMA machine.mem32[CH0_CTRL_TRIG] 0x39 while machine.mem32[CH0_CTRL_TRIG] 0x01: pass t1 time.ticks_us() print(dma us:, time.ticks_diff(t1, t0))在我板子上Python 循环大约 40 到 60 毫秒DMA 字模式加上 MicroPython 调用开销基本在 1 到 3 毫秒。这个差距背后是架构层面的原因Python 循环是解释器逐条执行每执行一次dst_big[i] src_big[i]都要经历字节码处理、边界检查、对象引用DMA 则是硬件模块以总线事务为单位吞吐只需要初始化时“说一次”搬多长。所以结论很简单大批量内存拷贝别用 Python 写循环DMA 快一个数量级甚至更多。4. 性能实测与异步思维DMA 的价值不只是快4.1 同样的数据量Python 循环 vs DMA 的差距在哪里前面测速直接对比了纯 Python 循环和 DMA 的耗时但这里我想再深挖一层DMA 的加速并不全是因为“硬件搬得比 CPU 快”。RP2040 的 DMA 本身工作在系统时钟下理论上你手动写汇编 unroll 循环也能搬得很快真正的原因在于 DMA 释放了 CPU 的每一条指令周期。你用 Python 循环时CPU 每搬一个字节都要同时负担解释器的开销用 DMA 时CPU 只需要花几百微秒做配置和查询剩下的时间完全空闲下来。就好比你要把十个箱子从一楼搬到二楼。自己爬楼搬每一步都要你亲自走叫一台电梯搬你在楼下按个按钮剩下的时间可以去写报表。这就是“异步”的价值。4.2 别让 CPU 干等启动 DMA 后继续执行其他任务我前面所有代码都在轮询 EN 位这其实还是同步等待CPU 在整个传输期间没法干别的事只是等待方式省了逐字节的手工搬运。真正发挥 DMA 优势的用法是启动之后让 CPU 去做其他计算回来再看结果。def dma_start_memcpy(dst, src, nbytes, channel0): base DMA_BASE channel * 0x40 machine.mem32[base 0x00] ctypes.addressof(src) machine.mem32[base 0x04] ctypes.addressof(dst) machine.mem32[base 0x08] nbytes # 默认按字节模式触发 machine.mem32[base 0x0C] 0x31 # 启动 64KB 传输后不等待先去算点东西 dma_start_memcpy(dst_big, src_big, len(src_big)) dummy 0 for i in range(10000): dummy i # 回来检查传输是否完成 while machine.mem32[CH0_CTRL_TRIG] 0x01: pass print(dma finished, dummy value:, dummy)这个模式特别适合音频、图像处理流水线ADC 采样数据进 DMA → CPU 处理前一段 → DMA 已经把后一段准备好 → CPU 再来拿两块缓冲交替使用。你不需要自己写memcpy硬件已经把数据按你的预期放好了。5. 从“能跑”到“实用”中断批量与疑难杂症5.1 用 DMA 中断标志代替忙等轮询 EN 位虽然简单但它在整个传输过程中把 CPU 绑死在循环里和同步等待没本质区别。如果希望 CPU 在传输期间彻底去睡或处理其他任务更专业的做法是使用 DMA 中断标志。RP2040 的 DMA 控制器有一个总中断状态寄存器INTR地址0x50000400每通道完成传输时会把对应位置 1另外还有INTE0地址0x50000404用于使能对应通道向 Cortex-M0 的中断线输出。MicroPython 里挂硬件中断回调也可以但在简单场景下我更推荐先用INTR的轮询标志因为它不依赖回调环境逻辑更可控INTR 0x50000400 INTE0 0x50000404 # 使能通道 0 中断状态输出 machine.mem32[INTE0] 1 dma_start_memcpy(dst_big, src_big, len(src_big)) # 一边干别的一边等 INTR 置 1 while not (machine.mem32[INTR] 0x01): pass print(INTR raised, DMA finished)比忙等 EN 位更强的地方在于INTR位在传输完成瞬间被硬件置位不会受到 MicroPython 解释器调度的影响而 EN 位清零和INTR置位在时序上是一样的只是你读取的目标寄存器不同。真要完全异步可以在这里配合machine.disable_irq()或注册回调去打断主循环但那是另一个话题了。5.2 批量搬运的思路链式通道和多段拷贝有时候你要连续搬运好几段数据比如把内存里两个不同来源的缓冲拼接到一起。你可以来回触发单通道但 RP2040 DMA 还提供了链式传输 CHAIN_TO 特性一个通道传输完成后自动去触发另一个通道。CTRL_TRIG 的CHAIN_TO字段就是干这个的把通道 0 的 CHAIN_TO 设置成通道 1通道 1 的 CHAIN_TO 设置成通道 2你只要触发通道 0整个链条就会按顺序执行。在 MicroPython 里配置多个通道并不复杂每个通道基址差0x40封装一个带通道号的启动函数即可。我上面dma_start_memcpy函数已经带了channel参数你可以为每次待搬运的数据段分别配置不同通道再把 CHAIN_TO 串起来这样一次触发就能搬完一整串缓冲区。链式的细节和中断联动用起来比较绕三言两语说不完我以后的教程会专门开一篇这里你先知道有这回事。5.3 新手最容易踩的 5 个坑我把这段时间在 MicroPython DMA 上遇到的和看见别人踩过的坑整理成一张表每一行都是血泪教训。现象原因排查/解决配置完 CTRL_TRIG 后 DMA 不启动DREQ_EN 被错误置 1DMA 在等外设请求确保 bit8 为 0CTRL 值用 0x31 或 0x39数据搬完但内容完全不对TRANS_COUNT 填错单位字模式下填了字节数字模式下传len(src_w)不要乘 4字模式一跑就报 AHB_ERROR源或目标地址不是 4 字节对齐用array(I)代替bytearray检查地址% 4 0DMA 运行期间 Python 崩溃或 HC传输未结束就修改/释放了缓冲区等 EN 位清零后再改 src/dst或锁 GC 防止对象销毁结果全是第一个字节的内容忘了设 INCR_READ 或 INCR_WRITE地址没有递增确认 bit4、bit5 都置 1这五个坑里最隐蔽的是缓冲区生命周期问题。MicroPython 里如果你用一个局部变量tmp bytearray(1024)启动 DMA同时在 DMA 还没搬完时函数返回这个bytearray可能被 GC 回收内存被重新分配给别人。DMA 往已释放的内存里写轻则数据错乱重则写坏堆结构导致 Crash。我的习惯是所有 DMA 用到的源和目的一律放在模块级全局变量或者在函数里启动前gc.lock()传完再解锁。5.4 多通道并行传输一个通道不够用怎么办RP2040 有 12 个 DMA 通道但并非所有场景都需要同时开多个。真正需要多通道的时候比如一边要 ADC 采集数据另一边要 SPI 刷新屏幕这时两个通道可以互不干扰地独立工作。在 MicroPython 里只需要把通道号传入基址计算不同的寄存器位置即可我把函数再升级一下def dma_start_ch(channel, dst, src, nbytes, size0): base DMA_BASE channel * 0x40 machine.mem32[base 0x00] ctypes.addressof(src) machine.mem32[base 0x04] ctypes.addressof(dst) machine.mem32[base 0x08] nbytes ctrl 0x01 | (0x10 if True else 0) | (0x20 if True else 0) | ((size 0x3) 2) machine.mem32[base 0x0C] ctrl这个函数里我把 SIZE 参数暴露出来默认字节模式。批量场景下你可以分别配置通道 1、通道 2然后在主循环里统一查询多个通道的 EN 位直到全部归零。注意通道是独立资源同一通道在传输完成前不要重复触发否则寄存器会被第二次配置覆盖乱成一片。6. 扩展思路这套 DMA 操作能用在哪些场景6.1 从 mem2mem 到外设传输OLED 刷新、串口收发、ADC 采样的共同套路内存到内存是 DMA 的一种特殊形态但它背后那套“配置寄存器 最后触发”的套路在外设传输里完全通用。举个例子你想给 SPI 接口的 OLED 刷一屏图像如果只用 Python 往 SPI 读写缓冲区里逐字节写一帧 1024x8 的数据都能卡到人麻如果配置一个 DMA 通道把源地址指向图像缓冲区目标地址指向 SPI 的 TX FIFO 数据寄存器大小设为显存长度触发一次DMA 就自己按 FIFO 的节奏把一屏图像送过去了CPU 全程只负责上下帧的预处理。RP2040 的 SPI0 基址是0x4003C000SPI1 是0x40040000FIFO 数据寄存器是0x04偏移这个配置和 mem2mem 唯一的区别就是把 WRITE_ADDR 从 SRAM 地址换成了 FIFO 地址同时 DREQ_EN 要置 1TREQ_SEL 选 SPI 的 DREQ 编号。串口 DMA 接收不定长数据也可以套这个思路DMA 把 UART RX FIFO 里的数据搬到内存缓冲区配合空闲中断判断一帧数据结束这在 STM32 生态里是标准用法在 RP2040 上同样成立。你一旦明白了 DMA 只是在“源地址-目标地址”之间按指定长度搬运就会意识到所谓外设传输不过是把某一端地址换成外设 FIFO 而已。6.2 其他芯片上的 MicroPython DMA思路可复制如果你手头也有 ESP32-S3 这类开发板会发现在 MicroPython 里虽然没有完全统一的 DMA 标准 API但寄存器操作的思路是一样的。ESP32-S3 的 GDMA 控制器地址、描述符格式和 RP2040 不同但核心要素仍然相同源地址、目标地址、传输长度、控制位、触发方式。你带着 RP2040 这套经验去看 ESP32-S3 的GDMA章节会感觉像是换了一种方言写同一句问候语上手速度快得多。所以我不建议把这篇教程当成“Pico 专属技巧”它其实是一种方法论当你需要在 MicroPython 里处理性能敏感的数据搬运与其到处找第三方库不如翻开芯片手册找到 DMA 寄存器那一章用machine.mem32直接说话。这不一定是最快的开发路径但一定是你最能掌控全局的路径。我个人在实际操作中的体会是这样的第一次看到 EN 位清零、两块内存内容完全一致的瞬间那种“我绕过解释器直接碰硬件”的满足感比跑通任何高级库都强烈。后来我无论做 OLED 刷屏、音频采集还是给 PIO 数据写 DMA 缓冲都靠这套基本功兜底。这篇教程只是一个开始你真正把 DMA 用顺之后会时不时想起那句老话硬件能替你干的活就别让 CPU 熬夜。