尧图网站建设 
1. 先搞清楚 rp2.DMA 到底是个什么东西在嵌入式开发里DMA 这个缩写出现的频率不低全称是 Direct Memory Access直译过来就是“直接存储器访问”。名字听着有点绕但它的核心作用其实很简单——帮 CPU 分担搬数据的活。举个生活化的例子厨房里只有一个厨师CPU他既要炒菜又要递菜、洗碗、擦桌子。如果每道菜都要他亲自端着从灶台走到水槽再走回来那他的炒菜效率肯定高不了。DMA 就是那个专门负责端盘子、洗碗的帮工CPU 只需要在开始的时候说一句“帮我把这批数据从 A 搬到 B”然后就继续专心炒菜跑主逻辑搬数据的过程完全由 DMA 自己完成搬完了再通知 CPU 一声。在树莓派 Pico 以及 Pico W 使用的 RP2040 芯片上DMA 控制器一共有 12 个独立的通道channel编号从 0 到 11。每个通道都可以单独配置数据源地址、目标地址、搬运长度以及搬运完成后的动作。也就是说你完全可以让其中几个通道专门负责从外设接收数据另外几个负责把数据从内存送到外设各干各的互不干扰。这里要特别说明一下标题里的 “rp2.DMA” 是 MicroPython 环境下访问 RP2040 DMA 控制器的模块路径。也就是说我们并不是在用 C 语言写 RP2040 的 SDK而是在 MicroPython 的解释器里通过rp2这个模块来操控 DMA。这样做的好处很明显——写代码快调试方便而且 MicroPython 官方已经把底层寄存器操作封装好了我们不需要去翻那本几百页的 RP2040 Datasheet 逐位配置寄存器只要把 API 的每个参数搞清楚就能把 DMA 用起来。1.1 什么时候真的需要用到 DMA在很多入门教程里DMA 往往被当成一个“进阶特性”来介绍导致不少初学者觉得它离自己很远。但实际上只要你的项目满足下面任一情况就值得认真考虑引入 DMA需要高速、连续地从外设读取数据比如 ADC 采样、UART 接收、SPI 从设备接收数据。需要把一块较大的数据从内存搬到外设发送比如用 SPI 驱动 LCD 屏幕刷新、用 PIO 发送大量波形数据。主循环里已经有比较重的计算任务不希望因为频繁的中断和外设读写拖慢节奏。需要精确控制数据搬运的时序不希望受 CPU 调度和中断延迟影响。以我个人的经验来看最典型的场景就是 ADC 连续采样。如果你在主循环里用adc.read_u16()循环采样会发现 CPU 几乎被占满了而且在采样间隔内做不了任何其他事。但如果你配一个 DMA 通道让 ADC 的结果直接写入内存缓冲区那么 CPU 在 DMA 搬运数据的过程中完全可以去处理别的事情比如刷新屏幕、响应按键、跑 PID 控制算法。采样完成后 DMA 触发一次中断主逻辑只要读缓冲区里的数据就行。另一个常见场景是 PIO 配合 DMA。RP2040 的 PIO 状态机非常适合做各种协议模拟比如 WS2812 灯带、DHT11 温湿度传感器、红外遥控发射等。PIO 的数据 FIFO 只有 8 个 32 位字的深度如果要发送很长的数据序列CPU 就得不停地往 FIFO 里填数据这同样会很占时间。用 DMA 往 PIO 的 TX FIFO 里自动搬运数据就能做到“填满一次剩下全交给 DMA”主循环几乎不参与。1.2 MicroPython 环境下能看到什么在 MicroPython 的 RP2040 移植版中rp2模块里确实包含了DMA类。如果你在 REPL 里输入下面的命令import rp2 print(dir(rp2))运行结果里会有一个DMA类。这个类提供了构造对象、配置通道、启动传输、等待完成等基础方法。当然由于 MicroPython 的封装层相对较薄很多底层的细节比如触发源选择、字节序、传输宽度都需要通过参数显式指定这既是好事也是坏事——好事是灵活坏事是如果文档没吃透配置起来容易踩坑。我在刚开始用的时候最大的困惑是这个rp2.DMA和machine模块里的mem32有什么关系答案是DMA 负责“搬运”mem32负责“直接访问寄存器”。很多时候你想让 DMA 从某个外设寄存器连续读数这时你就得先通过mem32获取那个寄存器的地址再把这个地址传给 DMA 的配置参数。换句话说mem32是获取地址的工具rp2.DMA是按地址搬运的工具两者配合使用是常态。2. rp2.DMA 核心 API 逐一拆解MicroPython 的rp2.DMA类 API 数量不算多但每个方法涉及的概念都不少。我把最常用的几个方法拿出来逐一说明尽量把每个参数的含义和典型值都讲清楚。2.1 创建 DMA 通道对象创建 DMA 通道对象的语法很简单dma rp2.DMA()不传入任何参数时MicroPython 会自动从 12 个通道里挑一个空闲的分配给这个对象。如果你想显式指定用哪一个通道可以传入通道编号dma rp2.DMA(3) # 显式使用通道 3我个人的习惯是优先让系统自动分配因为 RP2040 的 DMA 通道数量只有 12 个如果项目里同时用了 WiFi 驱动、ADC 采样、SPI LCD通道资源会比较紧张。手动指定通道确实更可控但前提是你得非常清楚哪些驱动已经占用了哪些通道。如果你用了 PIO 加 DMA 的组合还要特别小心PIO 的 0 号状态机对应的 DMA 请求往往和特定通道绑定不同状态机需要不同的 DREQ 编号这个后面会详细说。创建对象后还有一个常见操作是释放通道dma.close()close()方法会释放当前占用的 DMA 通道让其他代码可以重新使用它。这是一个很容易被忽略的操作尤其是在长时间运行的程序里频繁创建 DMA 对象而不释放最终会导致通道耗尽程序报错的时候还一脸茫然。2.2 配置传输参数config 方法与参数详解config()是rp2.DMA最核心的方法几乎所有关键行为都由它决定。一个典型的配置代码如下dma.config( read_addrsource_buffer, write_addrtarget_buffer, countlen(source_buffer), triggerrp2.DMA.REQ_PIO0_TX0, data_sizerp2.DMA.SIZE_32, ring_selrp2.DMA.RING_NONE, ring_size0, high_priTrue, )这一堆参数看着吓人其实拆开来看就清楚了。read_addr是数据源地址write_addr是数据目标地址。在 MicroPython 里你可以直接传入bytearray、array这类 buffer 对象也可以传入通过machine.mem32获取的寄存器地址。如果是后者通常需要配合read_incFalse或write_incFalse来固定地址因为外设寄存器地址一般来说是不应该自增的你总不能读一个寄存器读着读着蹦到下一个寄存器去。count表示传输的数据单元个数。注意不是字节数而是“数据单元”的个数。比如data_sizerp2.DMA.SIZE_32那count100就表示传输 100 个 32 位数据总共 400 字节。如果你把data_size设为SIZE_16那count100就是 100 个 16 位数据总共 200 字节。这一点非常容易搞混我见过不少人在配置 DMA 搬运音频数据时把count直接填成缓冲区字节数结果搬运了一半就触发了完成中断数据只有一半是有效的。trigger是 DMA 的触发源也就是“什么时候开始搬一个数据单元”。RP2040 的 DMA 支持很多触发源最典型的有rp2.DMA.REQ_ALWAYS无条件连续搬运配置完成后立刻开始搬直到count归零。rp2.DMA.REQ_PIO0_TX0PIO0 状态机 0 的 TX FIFO 非满时触发。rp2.DMA.REQ_PIO0_RX0PIO0 状态机 0 的 RX FIFO 非空时触发。rp2.DMA.REQ_ADCADC 转换完成时触发。举个例子如果 ADC 配置成连续采样模式并且你希望每次 ADC 转换完成后自动把一个 16 位结果搬到内存那trigger就应该选rp2.DMA.REQ_ADCdata_size选SIZE_16write_addr指向内存缓冲区write_incTrue让地址自动递增。ring_sel和ring_size是环形缓冲区相关参数。ring_sel可以选rp2.DMA.RING_NONE不使用环形缓冲、RING_READ读地址按环形回绕、RING_WRITE写地址按环形回绕。ring_size是环形缓冲的大小单位是 2 的幂次。比如ring_size10表示缓冲区大小是 2 的 10 次方也就是 1024 字节地址回绕时掩码会作用于低 10 位。这个功能在连续采样场景下非常有用比如你用 DMA 不断往一个 4KB 的缓冲区里写 ADC 数据写满后自动回到缓冲区开头不会越界也不需要 CPU 去复位地址。high_pri表示是否为高优先级通道。RP2040 的 DMA 控制器在多个通道同时请求时会有一个仲裁机制。高优先级通道总是优先获得总线访问权。如果你有一个对实时性要求极高的数据搬运任务可以把它设为True其他的设为False。但注意不要把 12 个通道全设成高优先级那样就失去了优先级的意义。2.3 启动与控制active、wait 与 irq配置完成后最常用的启动方式有两个。第一个是直接设置active属性为Truedma.active(True)第二个是调用dma.wait()阻塞等待传输完成dma.active(True) dma.wait()wait()会阻塞当前线程直到当前传输完成。在 MicroPython 的 RP2040 移植版里这个方法存在并且使用简单。但如果你的项目里同时跑了多线程_thread我建议尽量少用阻塞式wait()因为 DMA 传输在搬运大量数据时还是需要一点时间的阻塞期间如果有其他线程要用 CPU会被活活卡住。更好的做法是使用 DMA 完成中断或者定时查询active状态。irq()方法用于设置中断回调dma.irq(lambda dma: print(DMA done))但这里要提醒一句MicroPython 的rp2.DMA.irq()在不同固件版本中的行为并不完全一致某些版本不支持直接用 lambda 注册需要配合machine.irq或底层 IRQ 标志来使用。如果你在 REPL 里测试dma.irq(...)报错不要慌先查一下当前固件版本的源码或帮助文档。dma.close()除了释放通道资源还会尝试禁用中断并清除标志位。这是一个比较干净利落的收尾操作。2.4 地址自增与外设访问read_inc 和 write_incconfig()里还有两个参数没细说read_inc和write_inc。这两个参数单独拿出来讲是因为我确实在它们上面吃过亏。read_addr指向的地址每次传输完一个数据单元后是否自动递增由read_inc控制。默认情况下它是True也就是读地址自动递增。当你从一个内存数组读取数据、搬运到外设发送时这个默认值是对的。但当你从一个外设寄存器读取数据时比如mem32[PIO0_BASE | 0x00]你肯定不希望读地址每读一次就往高地址蹦一蹦这时候就要把read_inc设为False。write_inc同理控制写地址是否自动递增。往内存缓冲区连续写数据时通常希望递增往固定寄存器注入数据时就要禁止递增。举个反例如果写地址指向 GPIO 输出寄存器你想通过 DMA 持续输出一组高低电平结果忘了把write_inc设为False那么第一个数据写到了 GPIO 寄存器第二个数据就会写到 GPIO 寄存器的下一个地址——那个地址可能完全不是你想要的寄存器轻则输出异常重则直接导致外设状态错乱。这个细节在官方文档里往往只是提一句但实际编码时非常致命。我在一次 SPI LCD 刷新项目里就曾把write_inc漏掉结果屏幕出现了一条明显的异常彩条排查了大半天才发现问题根源。3. 配置避坑指南那些最容易翻车的细节讲完 API 本身接下来重点说说配置过程中最容易踩的坑。这些坑我基本都亲身踩过有些是查了 RP2040 Datasheet 才恍然大悟有些是反复试错才摸清规律。3.1 传输宽度与数据大小SIZE_8、SIZE_16、SIZE_32 的抉择RP2040 的 DMA 支持三种数据宽度8 位、16 位、32 位。在 MicroPython 中对应rp2.DMA.SIZE_8rp2.DMA.SIZE_16rp2.DMA.SIZE_32选错宽度最典型的后果是数据错位或丢数据。举个例子如果外设每次产生一个 8 位的数据但你用了SIZE_32那么 DMA 会尝试一次读取 4 个字节外设可能根本没有那么多数据可给读出来的内容就是错乱的。还有一点需要注意RP2040 的 DMA 在传输宽度不同时自动地址递增的步长也不同。SIZE_8每传一个数据单元地址加 1SIZE_16加 2SIZE_32加 4。这个步长是硬件自动处理的不需要你手动计算但你心里要有数否则count和缓冲区大小的关系容易算错。我常用的判断标准是看数据源产生的原始数据宽度。比如 ADC 默认转换结果是 12 位有效数据但寄存器是按 16 位存放的所以优先选SIZE_16普通内存之间的复制如果没有特殊需求直接选SIZE_32效率最高PIO 的 FIFO 是 32 位的所以往 PIO TX FIFO 搬运数据时大概率选SIZE_32。3.2 触发源选不对传输就是不走DMA 配置好之后最常见的“症状”是明明设置了active(True)但数据就是不搬。绝大多数情况问题出在trigger上。trigger决定了 DMA 在什么条件下搬运一个数据单元。如果你把trigger设成了rp2.DMA.REQ_ALWAYS那么 DMA 会尽最大努力连续搬运直到count归零。这种模式适用于内存到内存的复制或者在传输开始前数据已经全部就绪的场景。但如果你把trigger设成了某个外设请求比如REQ_ADC那么 DMA 必须等待 ADC 产生一次转换完成请求才会搬一个数据单元。如果 ADC 没有被正确配置为连续采样或者采样频率太低你会觉得 DMA “卡住了”其实不是卡住只是在等下一个触发源。这里有一个非常隐蔽的坑有些外设的 DMA 请求信号在没有实际数据时并不会拉高。比如 PIO 的 RX FIFO 为空时接收请求信号就没有PIO 的 TX FIFO 为满时发送请求信号也没有。因此你必须先确保外设侧已经准备好接收或产生数据再启动 DMA否则就会一直等。还有一种情况是通道选错了触发源。RP2040 的 PIO 共有两个 PIO 模块PIO0 和 PIO1每个模块有 4 个状态机每个状态机的 TX/RX FIFO 都有独立的 DMA 请求号。你如果往 PIO0 的 TX FIFO 发数据却选了REQ_PIO1_TX0那 DMA 就会去等 PIO1 状态机 0 的 TX FIFO 信号而那边可能压根没跑程序结果就是 DMA 一动不动。3.3 地址对齐与内存访问的隐藏限制RP2040 的 DMA 对地址对齐有一些限制尤其是使用SIZE_32时。官方 Datasheet 里提到如果传输宽度是 32 位建议缓冲区地址按 4 字节对齐传输宽度是 16 位建议按 2 字节对齐。虽然很多情况下不对齐也能工作但可能会出现效率下降极端情况下会触发出错行为。在 MicroPython 中创建bytearray时内存对齐通常由解释器管理一般能保证基本对齐。但如果你用array模块创建数组from array import array buf array(I, [0] * 100) # 无符号32位整型数组这个array(I)里的每个元素是 4 字节底层地址大概率是 4 字节对齐的用SIZE_32比较合适。如果你要操作的是bytearray并且需要 32 位宽度传输我建议你把bytearray的容量设为 4 的整数倍同时注意元素顺序。bytearray是按字节存储的如果你把一个 32 位整数写入bytearray需要手动处理小端序问题。最简单的做法是直接使用array(I)或array(H)让解释器帮你处理整数的内存布局。3.4 内存视图与缓冲区嵌套MicroPython 中经常用到memoryview来避免数据复制。memoryview本身是支持被 DMA 当作 buffer 读取的但你要小心memoryview的类型布局format可能会影响 DMA 对数据的解释。举个例子buf bytearray(1024) view memoryview(buf)[0:512] # 取前512字节把view传给read_addr时DMA 实际访问的是buf的前 512 字节。这个没问题。但如果你创建的是一个多维内存视图比如memoryview(buf).cast(I)那它的底层仍然是一个连续的 32 位整数数组可以配合SIZE_32使用。需要注意的是cast 后的 memoryview 长度是按新元素个数计的count也要相应调整。还有一个小技巧如果你希望 DMA 从一个较大缓冲区的某个偏移位置开始读取不需要额外创建新 buffer直接传切片即可dma.config( read_addrbuf[10:100], write_addrtarget, count90, data_sizerp2.DMA.SIZE_8, )这里的buf[10:100]会生成一个新的字节串对象DMA 读取的就是这个字节串。这种写法简单直观缺点是会复制一份数据。如果缓冲区很大且你不希望复制应该用memoryview切片。3.5 通道资源与其他驱动打架RP2040 的 12 个 DMA 通道虽然看起来不少但在复杂项目里并不充裕。特别是当你使用 MicroPython 的一些高级库时它们底层可能已经在偷偷使用 DMA 了。比如某些显示驱动库、SD 卡读写库、WiFi 驱动Pico W、甚至 PIO 的某些实现都会占用 DMA 通道。如果你的程序突然出现 DMA 相关的报错或者某个外设莫名其妙停止工作先检查两件事第一是不是自己在代码里创建了多个 DMA 对象而忘了close()第二是不是某个第三方库底层已经占了某个通道你手动指定通道时和它冲突了。我建议在代码的初始化阶段打印一下当前可用通道import rp2 for i in range(12): ch rp2.DMA(i) try: print(i, ok) except Exception as e: print(i, fail, e) finally: ch.close()这段代码能帮你快速探测 12 个通道中哪些可以正常创建。如果某个通道创建失败或报错说明它大概率已经被占用了。4. 实操案例一用 rp2.DMA 搬运 ADC 连续采样数据前面基础讲了不少现在用一个实际可运行的例子把配置逻辑串起来。这个例子的目标是用 ADC 以连续采样模式采集模拟信号DMA 自动把转换结果搬到一个缓冲区全程不占用 CPU 主循环采样结束后打印出缓冲区里的部分数据。4.1 硬件连接我使用的板子是树莓派 PicoADC 输入接在 GP26ADC0上用一个电位器提供 0 到 3.3V 的模拟电压。接线很简单电位器两端分别接 3.3V 和 GND。电位器中间抽头接 GP26。如果你没有电位器直接用一根杜邦线把 GP26 接到 3.3V 或 GND 也行只是为了验证最终数据是否变化。4.2 完整代码import rp2 import machine import time # 1. 配置 ADC adc machine.ADC(26) # GP26 对应 ADC0 adc_sample_rate 500_000 # 目标是 500kHz 采样率 # 注意MicroPython 的 ADC 没有直接设置采样率的 API # 但可以通过设置时钟分频来间接控制。这里我们先用默认配置。 # 2. 创建缓冲区 from array import array sample_count 512 buf array(H, [0] * sample_count) # 16位无符号整数每个元素2字节 # 3. 创建 DMA 通道 dma rp2.DMA() # 4. 配置 DMA dma.config( read_addrmachine.mem32[0x4004c008], # ADC FIFO 寄存器地址仅作为示例 write_addrbuf, # 写入内存缓冲区 countsample_count, triggerrp2.DMA.REQ_ADC, # ADC 转换完成后触发 data_sizerp2.DMA.SIZE_16, # ADC 结果是 16 位存储 read_incFalse, # 固定读地址 write_incTrue, # 写入地址自动递增 ) # 5. 启动 ADC 连续采样 machine.mem32[0x4004c000] | (1 13) # ADC 连续采样使能仅示意 # 6. 启动 DMA dma.active(True) # 7. 等待传输完成 dma.wait() # 8. 打印部分采样数据 for i in range(0, 16): print(fsample[{i}] {buf[i]}) dma.close()这里需要说明几点第一我代码里直接写了 ADC 寄存器的地址这是为了让读者看到mem32与 DMA 配合的真实用法。实际项目中这些地址可以查阅 RP2040 Datasheet 中的 ADC 章节来确认。MicroPython 官方并没有把 ADC 的采样率设置暴露成简单 API所以这种底层操作是必要的。第二machine.mem32[0x4004c008]是 ADC FIFO 数据寄存器的地址。当 ADC 完成一次转换结果会进入 FIFO而 DMA 在每次触发后从这个寄存器读走一个 16 位数据写入buf。由于read_incFalse每次读的都是同一个寄存器所以数据不会乱跳。第三triggerrp2.DMA.REQ_ADC表示 DMA 必须等待 ADC 产生转换完成请求。如果 ADC 没有正确启动DMA 就会一直等dma.wait()也会一直阻塞。所以一定要确保 ADC 侧配置正确。4.3 运行结果与验证把程序跑起来后串口终端会打印 16 个采样值。如果电位器在某一个固定位置这 16 个值会在一个小范围内波动属正常现象。如果你转动电位器采样值会随之变化。这个例子里最核心的一点是在主循环的dma.wait()之前CPU 实际上没有任何工作要处理。如果让你用普通轮询方式实现同样长度的采样CPU 就要一遍遍检查 ADC 标志位把大量时间浪费在等待上。而用 DMA 之后主循环只需要等待一个完成信号这种差异在采样点数多时尤其明显。5. 实操案例二DMA PIO 驱动 WS2812 灯带如果说 ADC 采样是 DMA 的经典入口那 PIO 加 DMDA 就是 RP2040 的高阶玩法。这个案例我选 WS2812 灯带因为网上关于 PIO 驱动 WS2812 的代码很多但很多版本没有用到 DMA而是靠 CPU 逐字节填充 PIO FIFO。在灯带数量比较多的场合那个版本的 CPU 占用率会高得离谱。本例的目标用 PIO 状态机产生 WS2812 时序DMA 负责从内存中的颜色数据缓冲区搬运数据到 PIO 的 TX FIFO实现完全“放手”的灯带控制。5.1 PIO 程序先写一个简单的 PIO 汇编程序。WS2812 的时序要求是每 bit 大约 0.4us 到 0.8us 的高电平再根据 bit 值决定低电平长度。在 RP2040 的 PIO 里最常用的方案是用系统时钟频率 125MHz 来编写精确延迟。下面是一份常见且稳定的 WS2812 PIO 程序我直接写出核心内容from rp2 import PIO, StateMachine, asm_pio asm_pio(sideset_initPIO.OUT_LOW, out_shiftdirPIO.SHIFT_LEFT, autopullTrue, pull_thresh24) def ws2812(): wrap_target() bitloop: out(x, 1) .side(0) [2] jmp(not_x, do_zero) .side(1) [1] jmp(bitloop) .side(1) [3] do_zero: nop() .side(1) [2] nop() .side(0) [2] wrap()这段 PIO 程序比较经典核心逻辑是从输出移位寄存器OSR中移出 1 bit根据 bit 值决定输出高电平的持续时间。autopullTrue和pull_thresh24表示自动从 TX FIFO 拉取数据每次拉取 24 位也就是 3 字节正好一个 WS2812 灯珠的颜色数据。wrap_target()和wrap()将程序包裹成循环持续输出灯带时序。5.2 配置 DMA 搬运颜色数据WS2812 的每个灯珠需要 24 位数据GRB 顺序每色 8 位。假设你有 30 个灯珠颜色数据就是30 * 24位也就是 90 字节。为了让 DMA 高效搬运我们通常把这个颜色数据放到一个bytearray里然后让 DMA 以SIZE_8或SIZE_32的方式循环往 PIO TX FIFO 里灌。但这里有一个细节autopull每次从 TX FIFO 中拉取 4 个字节32 位而我们的有效数据只有 3 个字节24 位。所以在填充bytearray时一定要保持数据按 4 字节对齐每 4 字节中低 3 字节是有效颜色数据第 4 字节可以填 0。如果漏掉这个填充颜色顺序会完全错乱。下面我给出一个最简单的 DMA 搬运实现每次手动刷新时重新搬运一次颜色数据import rp2 import machine from rp2 import PIO, StateMachine, asm_pio # 1. 定义灯带参数 LED_COUNT 30 # 每个灯珠3字节补1字节填充共4字节 buffer_size LED_COUNT * 4 led_buffer bytearray(buffer_size) # 2. 初始化颜色数据这里先全亮白色 for i in range(LED_COUNT): base i * 4 led_buffer[base] 0x10 # G led_buffer[base 1] 0x10 # R led_buffer[base 2] 0x10 # B led_buffer[base 3] 0x00 # 填充 # 3. 初始化 PIO 状态机 sm StateMachine(0, ws2812, freq800_000, sideset_basemachine.Pin(16)) sm.active(1) # 4. 创建 DMA 通道目标是 PIO0 TX FIFO dma rp2.DMA() dma.config( read_addrled_buffer, write_addrmachine.mem32[0x50200000], # PIO0 的 TX FIFO 地址基于 base 0x50200000 countlen(led_buffer), triggerrp2.DMA.REQ_PIO0_TX0, # 状态机0的TX请求 data_sizerp2.DMA.SIZE_8, read_incTrue, write_incFalse, ) # 5. 启动 DMA自动搬运数据到 PIO dma.active(True)这里machine.mem32[0x50200000]是 PIO0 的 TX FIFO 映射地址状态机 0 对应偏移 0x00。RP2040 Datasheet 中 PIO0 基址是0x50200000FIFO 地址按状态机偏移。这个写法在很多 MicroPython 例程中都能看到。5.3 实际效果与坑跑起来之后灯带应该全部亮起白色。如果你修改led_buffer里的颜色值然后重新启动 DMA就能改变灯带颜色。不过你一定要记得DMA 在搬运完count个数据后会自动停止如果你希望灯带持续显示需要重新配置并启动 DMA或者让count设置成循环模式。如果你发现灯带颜色错乱多半是填充字节没做对或者data_size选错了。WS2812 要求数据按位发送PIO 程序通过autopull自动从 TX FIFO 中拉取数据时一次拉取 4 字节但只有低 3 字节有效。所以每个灯珠的 4 字节里如果第 4 字节不是 0PIO 会把多余的数据也发送出去导致时序错乱。这是非常经典的一个坑。另外PIO 状态机的频率最好在 800kHz 左右因为 WS2812 的时序要求高电平 350ns、低电平 800ns 或反相频率太高太低都可能让灯带不出颜色。如果你发现灯带完全没反应先用逻辑分析仪确认 PIO 输出引脚有没有信号再排查 DMA 是否已经搬运完数据。6. 中断方式与多通道协同进阶用法前面两个案例都是“配置一次搬完即止”。实际项目里更常见的需求是 DMA 持续工作或者多个通道协同完成复杂的数据流处理。这一节我简要讲两个进阶方向。6.1 用中断代替阻塞等待dma.wait()虽然简单但在需要并发处理其他任务时不合适。解决方案是使用中断。MicroPython 的rp2.DMA提供了irq()方法可以注册一个回调函数在 DMA 传输完成时被调用。但是不同版本的 MicroPython 对DMA.irq()的支持情况不太一致。如果你发现dma.irq(callback)不可用可以退一步用machine模块的 IRQ 框架直接操作 DMA 的 IRQ 标志。这需要更低层的寄存器操作我在这里不展开建议你查看所用固件源码中rp2.dma模块的实现。一个可用的替代方案是在主循环里轮询dma.active的状态或者检查 DMA 通道的完成标志位。例如while dma.active(): # 做其他事情比如处理网络数据 time.sleep_ms(10) print(DMA done)这种方式不会占用大量 CPU在大多数场景下足够了。6.2 多通道流水线当数据流比较复杂时比如“外设A - DMA通道0 - 中间缓冲区 - DMA通道1 - 外设B”你需要两个 DMA 通道协同。RP2040 支持在 DMA 传输完成后触发另一个 DMA 通道开始传输。这个功能在寄存器层面是通过CHAIN_TO字段实现的但 MicroPython 的rp2.DMA.config()是否直接暴露了链式传输参数取决于固件版本。如果不支持链式传输你可以在 DMA 完成中断回调中手动启动下一个通道。虽然响应时间比硬件链式稍慢但胜在代码清晰、易于调试。我对这个方式的建议是先在单个通道上验证每个阶段的搬运是否正确再串成流水线否则出了问题很难定位。6.3 多缓冲区交替Ping-Pong Buffer连续采样场景下一个常见的痛点是DMA 正在往缓冲区 A 写数据时主逻辑也想读缓冲区 A就会发生数据竞争。解决办法是使用双缓冲区方案DMA 先写 A写完触发中断主逻辑在中断中把目标地址切换到 B同时开始处理 A 的数据等 B 写满再切回 A。这种交替方式被称为 Ping-Pong Buffer。在rp2.DMA中实现 Ping-Pong 的关键是在中断回调里重新调用config()把write_addr指向另一个缓冲区并重新设置count然后再次active(True)。这里要注意重新配置前最好先active(False)停掉当前传输避免配置冲突。我个人的经验是Ping-Pong Buffer 对中断回调的执行速度有一定要求回调里不要做耗时操作比如不要直接打印调试信息或做复杂的计算否则可能导致数据丢失。更稳妥的做法是只把缓冲区就绪标志位设好主循环检测到标志位后再处理数据。7. 常见问题速查表与排查思路最后把我在实际使用中遇到的典型问题整理成速查表方便大家遇到问题时快速定位。现象可能原因排查方法DMA 启动后完全不搬运trigger 触发源不对或外设没有产生请求检查外设是否使能尝试用REQ_ALWAYS验证 DMA 本身是否正常搬运的数据错位data_size与数据源宽度不匹配对照外设数据寄存器宽度选择SIZE_8/16/32地址自增导致读到奇怪数据读取外设寄存器时忘了设read_incFalse检查配置参数确保外设寄存器地址固定写入外设时数据乱跳写外设寄存器时忘了设write_incFalse同上检查写地址自增参数搬运不完整数据只有一半count单位是数据单元而不是字节确认count是否等于字节数除以数据宽度缓冲区越界写入导致崩溃缓冲区大小小于count * 数据宽度提前计算内存占用尽量用array分配精确大小通道创建失败或报错DMA 通道已被其他库占用检查是否忘了close()或用探测代码打印通道占用情况PIO DMA 灯带颜色错乱数据填充格式不对或SIZE选错确认每 4 字节中低 3 字节为 GRB 数据高字节填 0中断回调不触发固件版本不支持DMA.irq()或中断标志未清除查看固件源码改用轮询或底层 IRQ 标志在排查 DMA 问题时我有一个习惯性动作先用最简单的内存到内存搬运测试 DMA 本身的正确性再逐步引入外设。也就是说把read_addr指向一个已知内容的bytearraywrite_addr指向另一个空bytearraytrigger设为REQ_ALWAYS跑一次看目标缓冲区内容是否和源一致。如果这都出错说明配置参数有问题如果这步通过再换外设触发源问题范围就小很多。这个方法看似笨拙但在各种奇怪 bug 面前真的非常高效。如果dma.config()里某个参数名称在你当前固件版本中不存在多半是版本差异。MicroPython 的 RP2040 移植版更新较快建议在使用前先运行help(rp2.DMA)查看当前固件支持的完整方法列表和参数说明。再配合 REPL 里逐条测试基本能避开绝大多数版本兼容问题。8. 最后分享一点我的个人体会在 RP2040 上用 DMA最难的不是学会某个 API而是建立一种“把数据搬运交给硬件”的思维方式。很多初学者习惯事必躬亲读一个寄存器、存一个变量、再写一个寄存器每一步都要 CPU 亲自来一遍。这种思路在简单项目里没问题可一旦涉及高速连续数据流CPU 根本忙不过来。DMA 的价值就在于它让你把“数据从哪里来、到哪里去、搬多少、搬完怎么办”这几个核心问题一次性配置好然后把剩余的时间留给真正的业务逻辑。我在多次项目里体会到DMA 相关 bug 的排查成本往往比编写成本高得多。因为问题不会直接告诉你“你在配置 DMA 时把参数填错了”而是表现为“数据乱了”“灯带颜色不对”“串口偶尔丢一帧”这样的间接症状。只有熟悉每个参数背后的硬件行为才能在这些模糊症状中快速定位方向。如果你正在做一个涉及高频采样、大块数据搬运或复杂外设通信的项目非常建议先把rp2.DMA的基础 API 吃透再从简单的内存拷贝开始做实验最后再加外设触发源。这条路虽然看起来绕但走完之后你对 DMA 的理解会比直接照抄复杂例程扎实得多。 树莓派Pico的rp2.DMA模块详解与实战
1. 先搞清楚 rp2.DMA 到底是个什么东西在嵌入式开发里DMA 这个缩写出现的频率不低全称是 Direct Memory Access直译过来就是“直接存储器访问”。名字听着有点绕但它的核心作用其实很简单——帮 CPU 分担搬数据的活。举个生活化的例子厨房里只有一个厨师CPU他既要炒菜又要递菜、洗碗、擦桌子。如果每道菜都要他亲自端着从灶台走到水槽再走回来那他的炒菜效率肯定高不了。DMA 就是那个专门负责端盘子、洗碗的帮工CPU 只需要在开始的时候说一句“帮我把这批数据从 A 搬到 B”然后就继续专心炒菜跑主逻辑搬数据的过程完全由 DMA 自己完成搬完了再通知 CPU 一声。在树莓派 Pico 以及 Pico W 使用的 RP2040 芯片上DMA 控制器一共有 12 个独立的通道channel编号从 0 到 11。每个通道都可以单独配置数据源地址、目标地址、搬运长度以及搬运完成后的动作。也就是说你完全可以让其中几个通道专门负责从外设接收数据另外几个负责把数据从内存送到外设各干各的互不干扰。这里要特别说明一下标题里的 “rp2.DMA” 是 MicroPython 环境下访问 RP2040 DMA 控制器的模块路径。也就是说我们并不是在用 C 语言写 RP2040 的 SDK而是在 MicroPython 的解释器里通过rp2这个模块来操控 DMA。这样做的好处很明显——写代码快调试方便而且 MicroPython 官方已经把底层寄存器操作封装好了我们不需要去翻那本几百页的 RP2040 Datasheet 逐位配置寄存器只要把 API 的每个参数搞清楚就能把 DMA 用起来。1.1 什么时候真的需要用到 DMA在很多入门教程里DMA 往往被当成一个“进阶特性”来介绍导致不少初学者觉得它离自己很远。但实际上只要你的项目满足下面任一情况就值得认真考虑引入 DMA需要高速、连续地从外设读取数据比如 ADC 采样、UART 接收、SPI 从设备接收数据。需要把一块较大的数据从内存搬到外设发送比如用 SPI 驱动 LCD 屏幕刷新、用 PIO 发送大量波形数据。主循环里已经有比较重的计算任务不希望因为频繁的中断和外设读写拖慢节奏。需要精确控制数据搬运的时序不希望受 CPU 调度和中断延迟影响。以我个人的经验来看最典型的场景就是 ADC 连续采样。如果你在主循环里用adc.read_u16()循环采样会发现 CPU 几乎被占满了而且在采样间隔内做不了任何其他事。但如果你配一个 DMA 通道让 ADC 的结果直接写入内存缓冲区那么 CPU 在 DMA 搬运数据的过程中完全可以去处理别的事情比如刷新屏幕、响应按键、跑 PID 控制算法。采样完成后 DMA 触发一次中断主逻辑只要读缓冲区里的数据就行。另一个常见场景是 PIO 配合 DMA。RP2040 的 PIO 状态机非常适合做各种协议模拟比如 WS2812 灯带、DHT11 温湿度传感器、红外遥控发射等。PIO 的数据 FIFO 只有 8 个 32 位字的深度如果要发送很长的数据序列CPU 就得不停地往 FIFO 里填数据这同样会很占时间。用 DMA 往 PIO 的 TX FIFO 里自动搬运数据就能做到“填满一次剩下全交给 DMA”主循环几乎不参与。1.2 MicroPython 环境下能看到什么在 MicroPython 的 RP2040 移植版中rp2模块里确实包含了DMA类。如果你在 REPL 里输入下面的命令import rp2 print(dir(rp2))运行结果里会有一个DMA类。这个类提供了构造对象、配置通道、启动传输、等待完成等基础方法。当然由于 MicroPython 的封装层相对较薄很多底层的细节比如触发源选择、字节序、传输宽度都需要通过参数显式指定这既是好事也是坏事——好事是灵活坏事是如果文档没吃透配置起来容易踩坑。我在刚开始用的时候最大的困惑是这个rp2.DMA和machine模块里的mem32有什么关系答案是DMA 负责“搬运”mem32负责“直接访问寄存器”。很多时候你想让 DMA 从某个外设寄存器连续读数这时你就得先通过mem32获取那个寄存器的地址再把这个地址传给 DMA 的配置参数。换句话说mem32是获取地址的工具rp2.DMA是按地址搬运的工具两者配合使用是常态。2. rp2.DMA 核心 API 逐一拆解MicroPython 的rp2.DMA类 API 数量不算多但每个方法涉及的概念都不少。我把最常用的几个方法拿出来逐一说明尽量把每个参数的含义和典型值都讲清楚。2.1 创建 DMA 通道对象创建 DMA 通道对象的语法很简单dma rp2.DMA()不传入任何参数时MicroPython 会自动从 12 个通道里挑一个空闲的分配给这个对象。如果你想显式指定用哪一个通道可以传入通道编号dma rp2.DMA(3) # 显式使用通道 3我个人的习惯是优先让系统自动分配因为 RP2040 的 DMA 通道数量只有 12 个如果项目里同时用了 WiFi 驱动、ADC 采样、SPI LCD通道资源会比较紧张。手动指定通道确实更可控但前提是你得非常清楚哪些驱动已经占用了哪些通道。如果你用了 PIO 加 DMA 的组合还要特别小心PIO 的 0 号状态机对应的 DMA 请求往往和特定通道绑定不同状态机需要不同的 DREQ 编号这个后面会详细说。创建对象后还有一个常见操作是释放通道dma.close()close()方法会释放当前占用的 DMA 通道让其他代码可以重新使用它。这是一个很容易被忽略的操作尤其是在长时间运行的程序里频繁创建 DMA 对象而不释放最终会导致通道耗尽程序报错的时候还一脸茫然。2.2 配置传输参数config 方法与参数详解config()是rp2.DMA最核心的方法几乎所有关键行为都由它决定。一个典型的配置代码如下dma.config( read_addrsource_buffer, write_addrtarget_buffer, countlen(source_buffer), triggerrp2.DMA.REQ_PIO0_TX0, data_sizerp2.DMA.SIZE_32, ring_selrp2.DMA.RING_NONE, ring_size0, high_priTrue, )这一堆参数看着吓人其实拆开来看就清楚了。read_addr是数据源地址write_addr是数据目标地址。在 MicroPython 里你可以直接传入bytearray、array这类 buffer 对象也可以传入通过machine.mem32获取的寄存器地址。如果是后者通常需要配合read_incFalse或write_incFalse来固定地址因为外设寄存器地址一般来说是不应该自增的你总不能读一个寄存器读着读着蹦到下一个寄存器去。count表示传输的数据单元个数。注意不是字节数而是“数据单元”的个数。比如data_sizerp2.DMA.SIZE_32那count100就表示传输 100 个 32 位数据总共 400 字节。如果你把data_size设为SIZE_16那count100就是 100 个 16 位数据总共 200 字节。这一点非常容易搞混我见过不少人在配置 DMA 搬运音频数据时把count直接填成缓冲区字节数结果搬运了一半就触发了完成中断数据只有一半是有效的。trigger是 DMA 的触发源也就是“什么时候开始搬一个数据单元”。RP2040 的 DMA 支持很多触发源最典型的有rp2.DMA.REQ_ALWAYS无条件连续搬运配置完成后立刻开始搬直到count归零。rp2.DMA.REQ_PIO0_TX0PIO0 状态机 0 的 TX FIFO 非满时触发。rp2.DMA.REQ_PIO0_RX0PIO0 状态机 0 的 RX FIFO 非空时触发。rp2.DMA.REQ_ADCADC 转换完成时触发。举个例子如果 ADC 配置成连续采样模式并且你希望每次 ADC 转换完成后自动把一个 16 位结果搬到内存那trigger就应该选rp2.DMA.REQ_ADCdata_size选SIZE_16write_addr指向内存缓冲区write_incTrue让地址自动递增。ring_sel和ring_size是环形缓冲区相关参数。ring_sel可以选rp2.DMA.RING_NONE不使用环形缓冲、RING_READ读地址按环形回绕、RING_WRITE写地址按环形回绕。ring_size是环形缓冲的大小单位是 2 的幂次。比如ring_size10表示缓冲区大小是 2 的 10 次方也就是 1024 字节地址回绕时掩码会作用于低 10 位。这个功能在连续采样场景下非常有用比如你用 DMA 不断往一个 4KB 的缓冲区里写 ADC 数据写满后自动回到缓冲区开头不会越界也不需要 CPU 去复位地址。high_pri表示是否为高优先级通道。RP2040 的 DMA 控制器在多个通道同时请求时会有一个仲裁机制。高优先级通道总是优先获得总线访问权。如果你有一个对实时性要求极高的数据搬运任务可以把它设为True其他的设为False。但注意不要把 12 个通道全设成高优先级那样就失去了优先级的意义。2.3 启动与控制active、wait 与 irq配置完成后最常用的启动方式有两个。第一个是直接设置active属性为Truedma.active(True)第二个是调用dma.wait()阻塞等待传输完成dma.active(True) dma.wait()wait()会阻塞当前线程直到当前传输完成。在 MicroPython 的 RP2040 移植版里这个方法存在并且使用简单。但如果你的项目里同时跑了多线程_thread我建议尽量少用阻塞式wait()因为 DMA 传输在搬运大量数据时还是需要一点时间的阻塞期间如果有其他线程要用 CPU会被活活卡住。更好的做法是使用 DMA 完成中断或者定时查询active状态。irq()方法用于设置中断回调dma.irq(lambda dma: print(DMA done))但这里要提醒一句MicroPython 的rp2.DMA.irq()在不同固件版本中的行为并不完全一致某些版本不支持直接用 lambda 注册需要配合machine.irq或底层 IRQ 标志来使用。如果你在 REPL 里测试dma.irq(...)报错不要慌先查一下当前固件版本的源码或帮助文档。dma.close()除了释放通道资源还会尝试禁用中断并清除标志位。这是一个比较干净利落的收尾操作。2.4 地址自增与外设访问read_inc 和 write_incconfig()里还有两个参数没细说read_inc和write_inc。这两个参数单独拿出来讲是因为我确实在它们上面吃过亏。read_addr指向的地址每次传输完一个数据单元后是否自动递增由read_inc控制。默认情况下它是True也就是读地址自动递增。当你从一个内存数组读取数据、搬运到外设发送时这个默认值是对的。但当你从一个外设寄存器读取数据时比如mem32[PIO0_BASE | 0x00]你肯定不希望读地址每读一次就往高地址蹦一蹦这时候就要把read_inc设为False。write_inc同理控制写地址是否自动递增。往内存缓冲区连续写数据时通常希望递增往固定寄存器注入数据时就要禁止递增。举个反例如果写地址指向 GPIO 输出寄存器你想通过 DMA 持续输出一组高低电平结果忘了把write_inc设为False那么第一个数据写到了 GPIO 寄存器第二个数据就会写到 GPIO 寄存器的下一个地址——那个地址可能完全不是你想要的寄存器轻则输出异常重则直接导致外设状态错乱。这个细节在官方文档里往往只是提一句但实际编码时非常致命。我在一次 SPI LCD 刷新项目里就曾把write_inc漏掉结果屏幕出现了一条明显的异常彩条排查了大半天才发现问题根源。3. 配置避坑指南那些最容易翻车的细节讲完 API 本身接下来重点说说配置过程中最容易踩的坑。这些坑我基本都亲身踩过有些是查了 RP2040 Datasheet 才恍然大悟有些是反复试错才摸清规律。3.1 传输宽度与数据大小SIZE_8、SIZE_16、SIZE_32 的抉择RP2040 的 DMA 支持三种数据宽度8 位、16 位、32 位。在 MicroPython 中对应rp2.DMA.SIZE_8rp2.DMA.SIZE_16rp2.DMA.SIZE_32选错宽度最典型的后果是数据错位或丢数据。举个例子如果外设每次产生一个 8 位的数据但你用了SIZE_32那么 DMA 会尝试一次读取 4 个字节外设可能根本没有那么多数据可给读出来的内容就是错乱的。还有一点需要注意RP2040 的 DMA 在传输宽度不同时自动地址递增的步长也不同。SIZE_8每传一个数据单元地址加 1SIZE_16加 2SIZE_32加 4。这个步长是硬件自动处理的不需要你手动计算但你心里要有数否则count和缓冲区大小的关系容易算错。我常用的判断标准是看数据源产生的原始数据宽度。比如 ADC 默认转换结果是 12 位有效数据但寄存器是按 16 位存放的所以优先选SIZE_16普通内存之间的复制如果没有特殊需求直接选SIZE_32效率最高PIO 的 FIFO 是 32 位的所以往 PIO TX FIFO 搬运数据时大概率选SIZE_32。3.2 触发源选不对传输就是不走DMA 配置好之后最常见的“症状”是明明设置了active(True)但数据就是不搬。绝大多数情况问题出在trigger上。trigger决定了 DMA 在什么条件下搬运一个数据单元。如果你把trigger设成了rp2.DMA.REQ_ALWAYS那么 DMA 会尽最大努力连续搬运直到count归零。这种模式适用于内存到内存的复制或者在传输开始前数据已经全部就绪的场景。但如果你把trigger设成了某个外设请求比如REQ_ADC那么 DMA 必须等待 ADC 产生一次转换完成请求才会搬一个数据单元。如果 ADC 没有被正确配置为连续采样或者采样频率太低你会觉得 DMA “卡住了”其实不是卡住只是在等下一个触发源。这里有一个非常隐蔽的坑有些外设的 DMA 请求信号在没有实际数据时并不会拉高。比如 PIO 的 RX FIFO 为空时接收请求信号就没有PIO 的 TX FIFO 为满时发送请求信号也没有。因此你必须先确保外设侧已经准备好接收或产生数据再启动 DMA否则就会一直等。还有一种情况是通道选错了触发源。RP2040 的 PIO 共有两个 PIO 模块PIO0 和 PIO1每个模块有 4 个状态机每个状态机的 TX/RX FIFO 都有独立的 DMA 请求号。你如果往 PIO0 的 TX FIFO 发数据却选了REQ_PIO1_TX0那 DMA 就会去等 PIO1 状态机 0 的 TX FIFO 信号而那边可能压根没跑程序结果就是 DMA 一动不动。3.3 地址对齐与内存访问的隐藏限制RP2040 的 DMA 对地址对齐有一些限制尤其是使用SIZE_32时。官方 Datasheet 里提到如果传输宽度是 32 位建议缓冲区地址按 4 字节对齐传输宽度是 16 位建议按 2 字节对齐。虽然很多情况下不对齐也能工作但可能会出现效率下降极端情况下会触发出错行为。在 MicroPython 中创建bytearray时内存对齐通常由解释器管理一般能保证基本对齐。但如果你用array模块创建数组from array import array buf array(I, [0] * 100) # 无符号32位整型数组这个array(I)里的每个元素是 4 字节底层地址大概率是 4 字节对齐的用SIZE_32比较合适。如果你要操作的是bytearray并且需要 32 位宽度传输我建议你把bytearray的容量设为 4 的整数倍同时注意元素顺序。bytearray是按字节存储的如果你把一个 32 位整数写入bytearray需要手动处理小端序问题。最简单的做法是直接使用array(I)或array(H)让解释器帮你处理整数的内存布局。3.4 内存视图与缓冲区嵌套MicroPython 中经常用到memoryview来避免数据复制。memoryview本身是支持被 DMA 当作 buffer 读取的但你要小心memoryview的类型布局format可能会影响 DMA 对数据的解释。举个例子buf bytearray(1024) view memoryview(buf)[0:512] # 取前512字节把view传给read_addr时DMA 实际访问的是buf的前 512 字节。这个没问题。但如果你创建的是一个多维内存视图比如memoryview(buf).cast(I)那它的底层仍然是一个连续的 32 位整数数组可以配合SIZE_32使用。需要注意的是cast 后的 memoryview 长度是按新元素个数计的count也要相应调整。还有一个小技巧如果你希望 DMA 从一个较大缓冲区的某个偏移位置开始读取不需要额外创建新 buffer直接传切片即可dma.config( read_addrbuf[10:100], write_addrtarget, count90, data_sizerp2.DMA.SIZE_8, )这里的buf[10:100]会生成一个新的字节串对象DMA 读取的就是这个字节串。这种写法简单直观缺点是会复制一份数据。如果缓冲区很大且你不希望复制应该用memoryview切片。3.5 通道资源与其他驱动打架RP2040 的 12 个 DMA 通道虽然看起来不少但在复杂项目里并不充裕。特别是当你使用 MicroPython 的一些高级库时它们底层可能已经在偷偷使用 DMA 了。比如某些显示驱动库、SD 卡读写库、WiFi 驱动Pico W、甚至 PIO 的某些实现都会占用 DMA 通道。如果你的程序突然出现 DMA 相关的报错或者某个外设莫名其妙停止工作先检查两件事第一是不是自己在代码里创建了多个 DMA 对象而忘了close()第二是不是某个第三方库底层已经占了某个通道你手动指定通道时和它冲突了。我建议在代码的初始化阶段打印一下当前可用通道import rp2 for i in range(12): ch rp2.DMA(i) try: print(i, ok) except Exception as e: print(i, fail, e) finally: ch.close()这段代码能帮你快速探测 12 个通道中哪些可以正常创建。如果某个通道创建失败或报错说明它大概率已经被占用了。4. 实操案例一用 rp2.DMA 搬运 ADC 连续采样数据前面基础讲了不少现在用一个实际可运行的例子把配置逻辑串起来。这个例子的目标是用 ADC 以连续采样模式采集模拟信号DMA 自动把转换结果搬到一个缓冲区全程不占用 CPU 主循环采样结束后打印出缓冲区里的部分数据。4.1 硬件连接我使用的板子是树莓派 PicoADC 输入接在 GP26ADC0上用一个电位器提供 0 到 3.3V 的模拟电压。接线很简单电位器两端分别接 3.3V 和 GND。电位器中间抽头接 GP26。如果你没有电位器直接用一根杜邦线把 GP26 接到 3.3V 或 GND 也行只是为了验证最终数据是否变化。4.2 完整代码import rp2 import machine import time # 1. 配置 ADC adc machine.ADC(26) # GP26 对应 ADC0 adc_sample_rate 500_000 # 目标是 500kHz 采样率 # 注意MicroPython 的 ADC 没有直接设置采样率的 API # 但可以通过设置时钟分频来间接控制。这里我们先用默认配置。 # 2. 创建缓冲区 from array import array sample_count 512 buf array(H, [0] * sample_count) # 16位无符号整数每个元素2字节 # 3. 创建 DMA 通道 dma rp2.DMA() # 4. 配置 DMA dma.config( read_addrmachine.mem32[0x4004c008], # ADC FIFO 寄存器地址仅作为示例 write_addrbuf, # 写入内存缓冲区 countsample_count, triggerrp2.DMA.REQ_ADC, # ADC 转换完成后触发 data_sizerp2.DMA.SIZE_16, # ADC 结果是 16 位存储 read_incFalse, # 固定读地址 write_incTrue, # 写入地址自动递增 ) # 5. 启动 ADC 连续采样 machine.mem32[0x4004c000] | (1 13) # ADC 连续采样使能仅示意 # 6. 启动 DMA dma.active(True) # 7. 等待传输完成 dma.wait() # 8. 打印部分采样数据 for i in range(0, 16): print(fsample[{i}] {buf[i]}) dma.close()这里需要说明几点第一我代码里直接写了 ADC 寄存器的地址这是为了让读者看到mem32与 DMA 配合的真实用法。实际项目中这些地址可以查阅 RP2040 Datasheet 中的 ADC 章节来确认。MicroPython 官方并没有把 ADC 的采样率设置暴露成简单 API所以这种底层操作是必要的。第二machine.mem32[0x4004c008]是 ADC FIFO 数据寄存器的地址。当 ADC 完成一次转换结果会进入 FIFO而 DMA 在每次触发后从这个寄存器读走一个 16 位数据写入buf。由于read_incFalse每次读的都是同一个寄存器所以数据不会乱跳。第三triggerrp2.DMA.REQ_ADC表示 DMA 必须等待 ADC 产生转换完成请求。如果 ADC 没有正确启动DMA 就会一直等dma.wait()也会一直阻塞。所以一定要确保 ADC 侧配置正确。4.3 运行结果与验证把程序跑起来后串口终端会打印 16 个采样值。如果电位器在某一个固定位置这 16 个值会在一个小范围内波动属正常现象。如果你转动电位器采样值会随之变化。这个例子里最核心的一点是在主循环的dma.wait()之前CPU 实际上没有任何工作要处理。如果让你用普通轮询方式实现同样长度的采样CPU 就要一遍遍检查 ADC 标志位把大量时间浪费在等待上。而用 DMA 之后主循环只需要等待一个完成信号这种差异在采样点数多时尤其明显。5. 实操案例二DMA PIO 驱动 WS2812 灯带如果说 ADC 采样是 DMA 的经典入口那 PIO 加 DMDA 就是 RP2040 的高阶玩法。这个案例我选 WS2812 灯带因为网上关于 PIO 驱动 WS2812 的代码很多但很多版本没有用到 DMA而是靠 CPU 逐字节填充 PIO FIFO。在灯带数量比较多的场合那个版本的 CPU 占用率会高得离谱。本例的目标用 PIO 状态机产生 WS2812 时序DMA 负责从内存中的颜色数据缓冲区搬运数据到 PIO 的 TX FIFO实现完全“放手”的灯带控制。5.1 PIO 程序先写一个简单的 PIO 汇编程序。WS2812 的时序要求是每 bit 大约 0.4us 到 0.8us 的高电平再根据 bit 值决定低电平长度。在 RP2040 的 PIO 里最常用的方案是用系统时钟频率 125MHz 来编写精确延迟。下面是一份常见且稳定的 WS2812 PIO 程序我直接写出核心内容from rp2 import PIO, StateMachine, asm_pio asm_pio(sideset_initPIO.OUT_LOW, out_shiftdirPIO.SHIFT_LEFT, autopullTrue, pull_thresh24) def ws2812(): wrap_target() bitloop: out(x, 1) .side(0) [2] jmp(not_x, do_zero) .side(1) [1] jmp(bitloop) .side(1) [3] do_zero: nop() .side(1) [2] nop() .side(0) [2] wrap()这段 PIO 程序比较经典核心逻辑是从输出移位寄存器OSR中移出 1 bit根据 bit 值决定输出高电平的持续时间。autopullTrue和pull_thresh24表示自动从 TX FIFO 拉取数据每次拉取 24 位也就是 3 字节正好一个 WS2812 灯珠的颜色数据。wrap_target()和wrap()将程序包裹成循环持续输出灯带时序。5.2 配置 DMA 搬运颜色数据WS2812 的每个灯珠需要 24 位数据GRB 顺序每色 8 位。假设你有 30 个灯珠颜色数据就是30 * 24位也就是 90 字节。为了让 DMA 高效搬运我们通常把这个颜色数据放到一个bytearray里然后让 DMA 以SIZE_8或SIZE_32的方式循环往 PIO TX FIFO 里灌。但这里有一个细节autopull每次从 TX FIFO 中拉取 4 个字节32 位而我们的有效数据只有 3 个字节24 位。所以在填充bytearray时一定要保持数据按 4 字节对齐每 4 字节中低 3 字节是有效颜色数据第 4 字节可以填 0。如果漏掉这个填充颜色顺序会完全错乱。下面我给出一个最简单的 DMA 搬运实现每次手动刷新时重新搬运一次颜色数据import rp2 import machine from rp2 import PIO, StateMachine, asm_pio # 1. 定义灯带参数 LED_COUNT 30 # 每个灯珠3字节补1字节填充共4字节 buffer_size LED_COUNT * 4 led_buffer bytearray(buffer_size) # 2. 初始化颜色数据这里先全亮白色 for i in range(LED_COUNT): base i * 4 led_buffer[base] 0x10 # G led_buffer[base 1] 0x10 # R led_buffer[base 2] 0x10 # B led_buffer[base 3] 0x00 # 填充 # 3. 初始化 PIO 状态机 sm StateMachine(0, ws2812, freq800_000, sideset_basemachine.Pin(16)) sm.active(1) # 4. 创建 DMA 通道目标是 PIO0 TX FIFO dma rp2.DMA() dma.config( read_addrled_buffer, write_addrmachine.mem32[0x50200000], # PIO0 的 TX FIFO 地址基于 base 0x50200000 countlen(led_buffer), triggerrp2.DMA.REQ_PIO0_TX0, # 状态机0的TX请求 data_sizerp2.DMA.SIZE_8, read_incTrue, write_incFalse, ) # 5. 启动 DMA自动搬运数据到 PIO dma.active(True)这里machine.mem32[0x50200000]是 PIO0 的 TX FIFO 映射地址状态机 0 对应偏移 0x00。RP2040 Datasheet 中 PIO0 基址是0x50200000FIFO 地址按状态机偏移。这个写法在很多 MicroPython 例程中都能看到。5.3 实际效果与坑跑起来之后灯带应该全部亮起白色。如果你修改led_buffer里的颜色值然后重新启动 DMA就能改变灯带颜色。不过你一定要记得DMA 在搬运完count个数据后会自动停止如果你希望灯带持续显示需要重新配置并启动 DMA或者让count设置成循环模式。如果你发现灯带颜色错乱多半是填充字节没做对或者data_size选错了。WS2812 要求数据按位发送PIO 程序通过autopull自动从 TX FIFO 中拉取数据时一次拉取 4 字节但只有低 3 字节有效。所以每个灯珠的 4 字节里如果第 4 字节不是 0PIO 会把多余的数据也发送出去导致时序错乱。这是非常经典的一个坑。另外PIO 状态机的频率最好在 800kHz 左右因为 WS2812 的时序要求高电平 350ns、低电平 800ns 或反相频率太高太低都可能让灯带不出颜色。如果你发现灯带完全没反应先用逻辑分析仪确认 PIO 输出引脚有没有信号再排查 DMA 是否已经搬运完数据。6. 中断方式与多通道协同进阶用法前面两个案例都是“配置一次搬完即止”。实际项目里更常见的需求是 DMA 持续工作或者多个通道协同完成复杂的数据流处理。这一节我简要讲两个进阶方向。6.1 用中断代替阻塞等待dma.wait()虽然简单但在需要并发处理其他任务时不合适。解决方案是使用中断。MicroPython 的rp2.DMA提供了irq()方法可以注册一个回调函数在 DMA 传输完成时被调用。但是不同版本的 MicroPython 对DMA.irq()的支持情况不太一致。如果你发现dma.irq(callback)不可用可以退一步用machine模块的 IRQ 框架直接操作 DMA 的 IRQ 标志。这需要更低层的寄存器操作我在这里不展开建议你查看所用固件源码中rp2.dma模块的实现。一个可用的替代方案是在主循环里轮询dma.active的状态或者检查 DMA 通道的完成标志位。例如while dma.active(): # 做其他事情比如处理网络数据 time.sleep_ms(10) print(DMA done)这种方式不会占用大量 CPU在大多数场景下足够了。6.2 多通道流水线当数据流比较复杂时比如“外设A - DMA通道0 - 中间缓冲区 - DMA通道1 - 外设B”你需要两个 DMA 通道协同。RP2040 支持在 DMA 传输完成后触发另一个 DMA 通道开始传输。这个功能在寄存器层面是通过CHAIN_TO字段实现的但 MicroPython 的rp2.DMA.config()是否直接暴露了链式传输参数取决于固件版本。如果不支持链式传输你可以在 DMA 完成中断回调中手动启动下一个通道。虽然响应时间比硬件链式稍慢但胜在代码清晰、易于调试。我对这个方式的建议是先在单个通道上验证每个阶段的搬运是否正确再串成流水线否则出了问题很难定位。6.3 多缓冲区交替Ping-Pong Buffer连续采样场景下一个常见的痛点是DMA 正在往缓冲区 A 写数据时主逻辑也想读缓冲区 A就会发生数据竞争。解决办法是使用双缓冲区方案DMA 先写 A写完触发中断主逻辑在中断中把目标地址切换到 B同时开始处理 A 的数据等 B 写满再切回 A。这种交替方式被称为 Ping-Pong Buffer。在rp2.DMA中实现 Ping-Pong 的关键是在中断回调里重新调用config()把write_addr指向另一个缓冲区并重新设置count然后再次active(True)。这里要注意重新配置前最好先active(False)停掉当前传输避免配置冲突。我个人的经验是Ping-Pong Buffer 对中断回调的执行速度有一定要求回调里不要做耗时操作比如不要直接打印调试信息或做复杂的计算否则可能导致数据丢失。更稳妥的做法是只把缓冲区就绪标志位设好主循环检测到标志位后再处理数据。7. 常见问题速查表与排查思路最后把我在实际使用中遇到的典型问题整理成速查表方便大家遇到问题时快速定位。现象可能原因排查方法DMA 启动后完全不搬运trigger 触发源不对或外设没有产生请求检查外设是否使能尝试用REQ_ALWAYS验证 DMA 本身是否正常搬运的数据错位data_size与数据源宽度不匹配对照外设数据寄存器宽度选择SIZE_8/16/32地址自增导致读到奇怪数据读取外设寄存器时忘了设read_incFalse检查配置参数确保外设寄存器地址固定写入外设时数据乱跳写外设寄存器时忘了设write_incFalse同上检查写地址自增参数搬运不完整数据只有一半count单位是数据单元而不是字节确认count是否等于字节数除以数据宽度缓冲区越界写入导致崩溃缓冲区大小小于count * 数据宽度提前计算内存占用尽量用array分配精确大小通道创建失败或报错DMA 通道已被其他库占用检查是否忘了close()或用探测代码打印通道占用情况PIO DMA 灯带颜色错乱数据填充格式不对或SIZE选错确认每 4 字节中低 3 字节为 GRB 数据高字节填 0中断回调不触发固件版本不支持DMA.irq()或中断标志未清除查看固件源码改用轮询或底层 IRQ 标志在排查 DMA 问题时我有一个习惯性动作先用最简单的内存到内存搬运测试 DMA 本身的正确性再逐步引入外设。也就是说把read_addr指向一个已知内容的bytearraywrite_addr指向另一个空bytearraytrigger设为REQ_ALWAYS跑一次看目标缓冲区内容是否和源一致。如果这都出错说明配置参数有问题如果这步通过再换外设触发源问题范围就小很多。这个方法看似笨拙但在各种奇怪 bug 面前真的非常高效。如果dma.config()里某个参数名称在你当前固件版本中不存在多半是版本差异。MicroPython 的 RP2040 移植版更新较快建议在使用前先运行help(rp2.DMA)查看当前固件支持的完整方法列表和参数说明。再配合 REPL 里逐条测试基本能避开绝大多数版本兼容问题。8. 最后分享一点我的个人体会在 RP2040 上用 DMA最难的不是学会某个 API而是建立一种“把数据搬运交给硬件”的思维方式。很多初学者习惯事必躬亲读一个寄存器、存一个变量、再写一个寄存器每一步都要 CPU 亲自来一遍。这种思路在简单项目里没问题可一旦涉及高速连续数据流CPU 根本忙不过来。DMA 的价值就在于它让你把“数据从哪里来、到哪里去、搬多少、搬完怎么办”这几个核心问题一次性配置好然后把剩余的时间留给真正的业务逻辑。我在多次项目里体会到DMA 相关 bug 的排查成本往往比编写成本高得多。因为问题不会直接告诉你“你在配置 DMA 时把参数填错了”而是表现为“数据乱了”“灯带颜色不对”“串口偶尔丢一帧”这样的间接症状。只有熟悉每个参数背后的硬件行为才能在这些模糊症状中快速定位方向。如果你正在做一个涉及高频采样、大块数据搬运或复杂外设通信的项目非常建议先把rp2.DMA的基础 API 吃透再从简单的内存拷贝开始做实验最后再加外设触发源。这条路虽然看起来绕但走完之后你对 DMA 的理解会比直接照抄复杂例程扎实得多。