做高速数据采集这套东西我前前后后折腾了大半年最后沉淀下来的代码框架就叫hs_dma_framework。刚开始只是想解决一个 FPGA 采样数据怎么才能不丢包地送进 ARM 核的问题结果做着做着就成了一个 FPGA Linux ARM64 的一体化平台。这个标题里的每一个词都有它存在的意义——FPGA 管数据入口ARM64 跑 Linux 负责控制、处理和分发而 DMA 是把两者拧在一起的那根传动轴。这篇文章我就把这套框架的来龙去脉、踩过的坑和可以直接抄作业的配置全部摊开来讲。这套东西能解决什么问题呢本质上只有一个核心矛盾高速数据采集产生的数据量太大传统的“FPGA 采集一下、CPU 用中断去读寄存器”的玩法根本顶不住。举个例子一个 4 通道、每通道 200MSPS、16bit 的 ADC持续采样的原始速率就有 12.8Gbps每秒钟 1.6GB 数据。靠 CPU 中断去搬门儿都没有。hs_dma_framework 的思路是让 FPGA 把数据通过 DMA 直接写进 DDR 内存Linux 用户在应用层用 mmap 零拷贝读取把 CPU 中断频率从每秒几百万次降到了每秒两三次。我写这篇总结的受众很明确手里有 FPGA 开发板想在上面跑 Linux ARM64又要接高速 ADC 或者高速接口的朋友。你不用把里面的例子当成唯一答案但我会把方案选型的思考过程、DMA 参数怎么定、设备树怎么写、中断怎么调节拍、性能卡在哪几个点上全部讲透。看完你至少能省下两三个月的试错时间。1. 整体架构设计与方案选型设计这套框架之前我最关心的一直不是“怎么让 Linux 跑起来”而是“哪条路能把数据从采样端稳定搬到用户态”。这个问题的答案决定了整个平台长什么样。我先说结论再讲为什么。1.1 高速数据采集绕不开的三个核心矛盾先把问题抽象出来。任何高速采集系统真正要面对的是三个矛盾。第一个是采集速率与总线带宽的矛盾。ADC 一秒钟吐出来的数据量非常大你必须找一个带宽比它还大的数据通路。DDR 总线、AXI 总线、PCIe 这些“大水管”才是搬运工而连接 FPGA 与 CPU 的普通 IO 口、UART、SPI 这些“小水管”连提鞋都不配。第二个是中断频率与 CPU 处理能力的矛盾。如果每个采样周期都触发一次 CPU 中断CPU 大部分时间都在保存现场、跳转、恢复现场真正处理数据的时间所剩无几。经典的做法是 DMA 完成一段连续搬运后再中断一次把中断频率降下去。第三个是数据连续性与缓存一致性的矛盾。数据从 FPGA 到 DDR 是一批批来的如果用户程序还要把数据在内存里再拷贝一次再处理那带宽浪费了一半。这个问题要靠 mmap 和设备树里的 dma-coherent 属性共同解决。这三个矛盾不是靠某一个 IP 核就能全解决的得从架构层面做系统性设计。这也是我最终没有选纯 FPGA 方案、也没有选纯 ARM 方案的原因。1.2 三种主流平台路线的横向对比做高速采集业内一般有三条路线MCUDDR、DSPFPGA、FPGAARM SoC Linux。我在项目初期把这三条路线都仔细捋了一遍。MCUDDR 方案适合数据率在几十 Mbps 以内的场景因为 MCU 主频不高内存带宽也有限而且纯中断驱动模式下很容易丢数。但它开发简单如果你采集率确实不高杀鸡用牛刀反而没必要。DSPFPGA 方案在实时信号处理领域很常见FPGA 做前端预处理DSP 做算法两边的优势和劣势都很明显。但这里有个现实问题DSP 上跑复杂控制逻辑和网络协议栈很痛苦生态闭源工程师的调音经验也相对小众。如果你只是想快速出数据、上应用这条链路太重了。FPGAARM SoC Linux 是这几年的主流像 Xilinx Zynq UltraScale 这种片子一个 die 里塞了 ARM Cortex-A53 核和 FPGA 逻辑。ARM 侧跑 Linux所有网络、存储、文件系统、调试工具全都有现成的FPGA 侧负责高实时性的采集和搬运两边通过片内 AXI 互联紧密咬合。数据不需要跨芯片走 PCB延迟和功耗都好看。我在框架里选的就是第三条。要不要上 Linux 这个问题我再补充两句——如果你的应用只需要在一个裸机循环里搬数据裸机当然更快但只要涉及动态加载、远程升级、多任务调度、网络交互Linux 带来的工程效率是裸机没法比的。hs_dma_framework 里用到的 mmap、UIO、中断亲和性这些东西全部依赖 Linux 的成熟机制。方案对比项MCU DDRDSP FPGAFPGA ARM SoC Linux数据通路带宽低中高开发生态MCU 简单DSP 工具链小众丰富完全开源实时性中断响应较高很好满意配合 PREEMPT_RT 可进一步优化系统扩展性弱中极强团队招聘难度简单较难普通嵌入式/Linux 工程师即可1.3 hs_dma_framework 的最终架构定下 FPFAARM SoC 这条路线之后整个框架就清晰了。hs_dma_framework 分成四层第一层是采样前端也就是 ADC 或高速 IO负责把模拟信号变成数字流。第二层是FPGA 数据通路内含跨时钟域 FIFO、数据格式化逻辑和 AXI DMA 引擎负责把数据搬进片外 DDR。第三层是ARM64 运行环境跑 Linux通过设备树描述硬件通过驱动把 DMA 能力暴露给用户态。第四层是应用层使用者只需要用 mmap 拿到内存指针按协议解析数据即可。这个四层结构是有意为之每一层的边界都定义得很清楚调试的时候可以横向定位。FPGA 侧波形不对就查 FIFO 和 AXI 接口内存里数据不对就查 DMA 描述符和设备树应用层解析出错就在用户态校验帧头帧尾。项目里我的 DTS设备树源码写得很保守先保证单通道搬运千兆级别数据再逐步开放多通道后面我会展开说设备树的写法。2. FPGA 侧数据链路与 DMA 引擎设计框架的“心脏”是 AXI DMA。很多人从 Xilinx 的官方 demo 里导出一个 AXI DMA IP配置完就以为万事大吉了实际上最花时间的不是 IP 配置而是你给 DMA 喂数据的那条链路上的时序问题。2.1 前端采样接口的时序处理从 LVDS 到并行总线我先说数据是怎么进来的。我在这套框架里用的是高速 ADC走的是 LVDS 接口DDR 模式下一条差分线在一个时钟周期里传两个比特。数据到达 FPGA 之后首先得做两件事跨时钟域同步和位对齐。跨时钟域是 FPGA 设计里出问题最多的区域尤其是 ADC 自己产生采样时钟的场景。ADC 的采样时钟通常用 LVDS 时钟对直接进 FPGA这时候你就得犹豫一下要不要把这个时钟直接用作逻辑时钟我的经验是中间一定要过 PLL锁相环或者 MMCM混合模式时钟管理器对外部时钟做一次相位调整和频率综合再给后端逻辑用。直接拿外部时钟驱动逻辑小数点级别的抖动就可能让你偶发读错数据。位对齐这一块容易踩坑。LVDS 进 FPGA 之后每个通道内比特的窗口位置会有细微偏差不做调整的话数据线读出来全是错位的。我在链路里加入了硬对齐模块利用 ADC 输出的同步头信号在 FPGA 里检测一段特定的同步码对齐窗口后锁定数据。这个逻辑不复杂但要注意当你切换模拟增益或通道数时同步头时序会变所以对齐状态机必须能在运行中重新训练。跨时钟域之后把串行比特流转成并行总线。这时候你会看到一个很关键的机会数据宽度越宽后端总线频率就越低时序压力就越小。我的后端 AXI 数据宽度是 512bit也就是 64 字节一拍。如果原始数据是 16bit × 4 通道并行输出频率只需要设计得当后面基本不用担心时序收敛问题。2.2 片内 FIFO 深度与水位设计一个经常被忽略的数学题数据经过对齐和串并转换后下一步是往 FIFO 里灌。FIFO 在这条链路里起两个作用缓冲瞬时流量和做跨时钟域。FIFO 深度的计算是真正的数学题。假设你每采集 100 个时钟周期会产生 10 个周期的突发数据突发速率是 25.6GbpsDMA 搬到 DDR 的平均速率可能只有 12.8Gbps。那么每一个突发周期FIFO 都会净增加 10/100 × (25.6 - 12.8)Gbps 的数据量。如果 DMA 的响应延迟是 1 微秒你就需要预留至少 1 微秒 × 这个净增加速率才能保证不溢出。这个计算看似简单但实际中 DMA 启动延迟、DDR 刷新周期、AXI 总线上其它主设备的抢占都会引入不确定的等待时间。我的建议是FIFO 深度至少要留出三倍的理论余量即“理论需求深度 × 3”。代价是片上资源变多换来的是你永远不会在深夜收到“丢数”的报警消息。FIFO 水位watermark也要花心思。水位设得太高DMA 每次搬运的数据块就很大中断频率低但首字节延迟高水位设得太低中断频繁CPU 开销上去吞吐反而下降。我在这套框架里把水位设为 FIFO 容量的 3/4实测在中等速率下 CPU 占用和延迟的平衡点不错。如果你想极致压中断可以把水位设成 7/8然后用 DMA 的“最后一次突发”机制做长传输。2.3 AXI DMA 参数与 Stream 接口配置庖丁解牛接着是连接 FIFO 和 DDR 的 AXI DMA IP。Xilinx 的 AXI DMA 配置界面里有几个参数容易被嫖过去我来逐个说清楚。第一个是地址宽度直接选 40bit 或 44bit别选 32bit。为什么你的系统 DDR 容量往往超过 4GB并且 DMA 描述符和缓冲区最好是物理地址连续的越大的寻址范围越不容易限制你找连续内存。第二个是突发长度Burst Length。AXI DMA 单次突发最长可以到 256 拍数据宽度 512bit 时一次突发就是 64 字节 × 256 16KB。突发越长总线的利用率越高但太长也会霸占总线导致其他主设备饥饿。这里要平衡我用的是 128 拍约 8KB 一次突发几次实测下来总线效率和实时性都比较理想。第三个是 Stream 接口的数据宽度配置成和 FIFO 输出的位宽一致。如果 DMA 入口宽度和你的总线宽度不一致IP 会自动生成 CDC 逻辑但多一层逻辑就多一分出错风险。能对齐就对齐省心。还有一点要特别提醒AXI DMA 的缓冲区地址必须是基地址对齐的我用的是 4KB 对齐。设备树里如果给驱动分配了不小心的地址DMA 报错会让你排查到怀疑人生。这点在后面的驱动部分会再串起来讲。2.4 触发方式帧中断还是流中断这一步设计完之后DMA 的搬运策略有两种实现方式要么每次写满一定长度就触发一次中断要么等待外部触发信号比如采集开始命令才开始搬。hs_dma_framework 里我做了两种模式的兼容。第一种是“连续流模式”适合长时间采集ADC 一直在跑DMA 把环形缓冲区写完一轮就中断一次应用层应用层直接读最新数据。第二种是“单次帧模式”适合示波器、瞬态信号记录这类场景收到外部触发后DMA 按预设长度采样搬完立刻停数据留在内存里交给应用层慢慢分析。在 FPGA 侧实现这两种模式实质上是 DMA 的 Soure 端被包了一层控制状态机。连续流模式就是一直允许 DMA 读取单次帧模式则是控制一个“门”门开后恰好让 FIFO 流出固定字节数然后关门。这个状态机的状态迁移并不复杂真正要小心的是关门后 FIFO 里剩下的残余数据要不要丢弃——我把支持清零的残余数据清掉了免得下一次触发时混进旧数据。3. ARM64 侧 Linux 集成与驱动实现FPGA 侧把数据搬进 DDR 还只是完成了第一步如果用户态程序拿不到这些数据前面全白干。这个章节讲 ARM64 跑 Linux 之后怎么通过设备树描述硬件、怎么用驱动做零拷贝、怎么调中断让性能最大化。3.1 设备树与地址空间规划把自己当系统架构师Linux 启动后硬件怎么被发现靠设备树。我在 dts 里给 AXI DMA 节点做了这样的基本骨架axi_dma_0: dmaa0010000 { compatible xlnx,axi-dma-1.00.a; reg 0x0 0xa0010000 0x0 0x1000; dma-channels 1; interrupts 0x0 0x59 0x4; xlnx,addrwidth 40; xlnx,include-sg 0x1; dma-coherent; };这里最该留意的是dma-coherent属性。它的意思是 DMA 和 CPU 共享的内存是硬件保证 cache 一致性的Linux 不需要额外做 cache clean/invalidate。你要是忘了写这个属性轻则性能打折重则 DMA 写入的数据在 CPU 看到时不完整调试起来非常恼火。还有中断号。这个0x59不是我瞎填的是在 FPGA 工程里管脚分配时确认的。Zynq UltraScale 的中断控制器有一大堆 SPI 中断号每个 AXI DMA 的完成中断需要映射到具体的 GIC 中断编号上。这里的偏差常见得离谱——编号错一位驱动程序 request_irq 直接报“IRQ not found”排查到凌晨的案子我见过好几回。地址空间规划同样要做全局考虑。我习惯让 DMA 缓冲的地址落在 DDR 高位区域腾出低位给 Linux 内核和应用程序的常规使用。连续内存CMA区域单独预留避免内核频繁页面迁移影响大块内存的可用性。3.2 零拷贝是怎么实现的mmap 与连续物理内存用户态要读取 DMA 搬进来的数据常规做法是 read() 系统调用但这会在内核态和用户态之间拷贝一次数据。100Gbps 的数据流、一次 8KB 的缓冲区拷贝一次就有 8KB 的带宽浪费。零拷贝的核心就是把 DMA 缓冲区直接映射到用户态进程的地址空间。具体做法是驱动分配一块物理连续内存CMA 或者预留内存池把这块内存的物理地址告诉 DMA 硬件同时通过 mmap 把同一块物理内存映射到用户态。应用层拿到 mmap 返回的指针后直接读写这块内存不再经过内核拷贝。驱动里 mmap 的核心代码大致长这样static int dma_framework_mmap(struct file *fp, struct vm_area_struct *vma) { unsigned long size vma-vm_end - vma-vm_start; if (size dma_buf_size) return -EINVAL; vma-vm_page_prot pgprot_noncached(vma-vm_page_prot); if (remap_pfn_range(vma, vma-vm_start, dma_phys_addr PAGE_SHIFT, size, vma-vm_page_prot)) return -EAGAIN; return 0; }这里我特意用了pgprot_noncached。在带有dma-coherent的平台上Cache 一致性由硬件保证用普通 cached 映射也能跑但我在实际项目中还是关闭了缓存。原因很简单关闭缓存后数据写到内存的可见性是确定的调试时不存在“缓存里是旧数据、内存里是新数据”这种灵异事件。代价是每次 DMA 完成中断刷一次缓存但高速采集的典型吞吐下CPU 开销依旧在可接受范围内。3.3 中断合并与 CPU 亲和性调优DMA 中断来了之后Linux 中断子系统要处理一个中断描述符的完整生命周期。如果每秒中断几十万次CPU 大部分时间都在中断上下文里用户态程序根本抢不到时间去处理数据。所以中断调优是性能的胜负手。我在这套框架里做了两个方向的调整。第一是中断合并。AXI DMA 的 Tail Descriptor 更新机制允许驱动在处理完一个描述符后不马上通知硬件继续而是攒够 N 个描述符一起提交。这样中断频率可以从几十万一路降到几百。代价是延迟变大但绝大多数高速采集场景的延迟容忍度都在毫秒级中断频率几百的情况下单次延迟最多也就几十微秒完全够用。第二是 CPU 亲和性。我把 DMA 中断绑定到 CPU2 上把用户态数据处理线程绑定到 CPU3 上。这样避免了中断处理和数据处理在同一个核上互相打架。用 taskset 做线程绑定是一个很朴素但效果立竿见影的手段配置方式我放在后面的性能测试章节里展开。还有人问过我用 UIO 还是 VFIO。我更倾向于 UIO理由很实在UIO 驱动写起来快应用层用 mmap 就能访问寄存器内置的 uio_pdrv_genirq 框架自动处理中断屏蔽与触发对中小团队足够友好。VFIO 适合要跑虚拟化或者需要更严格隔离的场景工程复杂度也高一个量级。hs_dma_framework 里我默认用的是 UIO 方式配合自己写的 mmap 和 ioctl 控制命令。4. 性能测试、瓶颈分析与实测数据部件都通了接下来就是拿数据说话的时刻。这个过程让我把很多概念性的理解变成了工程上的确定值。4.1 测试方法不能只测“峰值带宽”我见过很多人都拿 DMA 一次搬运 1MB 数据的时间去除以 1MB声称达到了 8GB/s 的带宽。这个数字有意义吗有但只是“一次突发”的带宽不是“持续有数据进来”的带宽。高速采集系统的性能瓶颈通常在于持续吞吐量而不是单次突发带宽。持续吞吐量要考虑 DMA 准备好下一段搬运的时间、中断处理的时间、应用层读取的时间。我测试的场景是一个持续伪随机波形的发生器模拟 ADC 以 12.8Gbps 的码率连续输出系统需要把这个速率稳定接入 DDR 并让应用层以不丢帧的方式读到数据。测试的核心指标有两个吞吐率和数据完整性。数据完整性我用了两种方式验证一种是在 FPGA 侧对数据流插入帧号应用层检查帧号是否连续另一种是 DMA 搬运完成后由硬件对一段数据生成 CRC应用层比对 CRC。帧号法最简单CRC 法更能暴露隐蔽的错误。我强烈建议测试脚本里两种都做。4.2 实测数据一组让我满意的数字我用框架在 Zynq UltraScale 平台上做了几组实测数据如下项数值FPGA 到 DDR 持续写入吞吐12.4 Gbps中断频率366 次/秒用户态到 FPGA 寄存器配置延迟 2 μsCPU 占用4核 A53约 0.8 核DMA 缓冲区一次搬运的字节数8KB数据校验错误0持续运行 24 小时12.4Gbps 对片内 AXI 总线来说远不是极限但已经超过了我们项目的需求。中断频率被压到每秒几百次之后CPU 几乎不忙碌这意味着应用层还能再去跑协议栈、做处理算法、写文件整个系统“游刃有余”。这组数据的意义是高速数据采集平台不用“跛脚”——CPU 在能干很多别的事情的同时数据也能稳定流入。硬件平台的瓶颈已经不是总线带宽而是应用层拿到数据之后怎么消化。4.3 瓶颈分析从 DDR 写到应用层读到的完整链路计算从数据流角度一条完整链路要经过这些关卡LVDS 接收、FIFO、AXI DMA 写 DDR、DDR 读回 CPU 缓存/内存、用户态 mmap 读取、应用解析。每一个关卡都可能成为理论瓶颈你要逐个核算。以我测试的配置举例数据宽度 512bit总线工作时钟 250MHzAXI 理论带宽 512bit × 250MHz 128Gbps。DDR4 带宽按 2400MT/s、64bit 位宽算理论带宽约 19.2Gbps加上刷新损失和行切换开销实际可用约 14~15Gbps。而我的采入数据是 12.4GbpsDDR 侧还能承受。CPU 侧呢一次中断从发生到处理完大约 30~40μs每秒 366 次中断的 CPU 开销只有约 1.5%。mmap 读取这块内存时由于关闭了缓存应用层读取速度会略低于缓存读取但我用的提法是“数据到达”即读取实测应用层 1 秒钟可以从 mmap 区搬走 12Gbps 数据而不丢。瓶颈算下来确实不在 DMA、也不在 DDR而在更上游的 LVDS 前端和 FIFO 水位配置。这也反向验证了一个结论设计高速采集系统时要把预算从数据源头开始做而不是只盯着 DMA 的峰值带宽。如果你的 ADC 只提供 1Gbps你用 128Gbps 的 DMA 带宽来配那是大炮打蚊子但你的 FIFO 深度如果按 1Gbps 去配实际需求可能因为突发到达而到 5Gbps那丢数就不可避免。5. 常见问题与排错实录这部分我把这套框架开发和调试过程中踩过的坑全部整理出来。5.1 中断号对不上导致的“无法注册中断”症状是驱动加载时 request_irq 失败报 -EINVAL。排查时先用cat /proc/interrupts查看可用的中断列表再去确认设备树里写的 SPI 中断号是否和 FGPA 侧的实际中断连接一致。Zynq 系列有个规律第一颗 SPI 中断号不是从 1 开始而是从 121 起跳对 GIC 而言写设备树时容易把裸中断号当成 SPI 号直接写。我当时出的错是把 FPGA 里管脚编号等于 89 的接了一个中断设备树里也写了 89但实际 Linux 内核里中断号需要换算成硬件中断号。最后对照原理图、核对xlnx,axi-dma的生成 block design 连线才定位到。几十个项目下来这类问题占了中断类 bug 的一半以上。5.2 FIFO 溢出导致的数据丢帧靠水位和环形缓冲共同解决丢帧的排查思路是先看 FPGA 侧 FIFO 的 overflow 信号有没有拉高。如果拉高说明灌进来的数据超过 FIFO 容量原因是 DMA 没有及时把数据搬走。这种情况要查三个方面DMA 有没有在持续提交描述符、DDR 有没有被其他 master 长期占用、FIFO 深度和水位是否合理。我初期遇到溢出时第一反应是加大 FIFO512KB 改到 2MB结果只缓解了没根治。真正原因是我用环形描述符时每次中断都清理全部描述符导致 DMA 有一段时间处于“无描述符可搬”的空窗。优化方法是一次维护两段环形中断处理只清理已经搬完的部分同时预先填充下一段描述符。这个改动之后FIFO 再没飘红过。5.3 数据错位、字节乱跳先查串行对齐再查缓存一致性如果你看到 DMA 搬进内存的数据前面几个字节是对的但中间有几个字节总是错乱大概率不是 DMA 的问题而是数据源端串行对齐没做好。LVDS 上每个通道的 bit 窗口都是独立的必须回训练对齐。我之前在一次改版中把同步头检测阈值改了结果大量数据错位表现就是读出来的波形完全“花”了。如果数据“偶尔”错一次那就更可能是缓存一致性问题了。硬件不支持 dma-coherent 的时候驱动侧必须对缓冲区做 cache invalidate并且要在 DMA 读内存之前和写内存之后都做一次。漏一个 invalidate 就可能读到旧数据。我建议调试阶段先在驱动里加个调试宏记录 DMA done 和 cache invalidate 的时间戳保证 invalidate 一定发生在 DMA 写回之后。这点排错时极其有用。5.4 CPU 占用过高先查是不是在轮询而不是在中断有一个非常隐蔽的性能陷阱如果驱动在 while 循环里不断查询 DMA 状态寄存器那么用户态看起来“没干正经事”的 CPU 会飙到 100%。有工程师为了绕过中断处理的复杂度直接轮询结果 CPU 占用率永远降不下去。轮询本身可以用于调试无可厚非但跑性能测试时必须切回中断模式。hs_dma_framework 里我加了一个编译选项轮询和中断模式可以在驱动加载时指定。默认中断调试时轮询。5.5 性能上不去先查这几个位置如果实测吞吐只有理论值的一半我建议按这个顺序检查地址对齐DMA 缓冲区物理地址是否按 AXI 突发长度对齐。未对齐时总线会拆成多个小突发效率骤降。描述符链深度描述符太少会让 DMA 反复等待驱动补充我用的是 64 个描述符每个对应 8KB 缓冲区。中断线程化如果驱动把中断处理写得太重中断会卡住后续传输。中断里只做必要操作其他都投递到 workqueue 或 tasklet。DDR 访问模式多个通道写入 DDR 同一行地址时会产生大量行冲突尽量让 DMA 缓冲区分散在不同 bank。按这个顺序查大多数时候在前两步就能找到问题。最后再分享一个实际体会做这套框架最大的感受是高速数据采集系统的问题从来不会只出现在某一层。FPGA 工程师觉得是驱动的问题驱动工程师觉得是 FPGA 的问题这类扯皮我见得太多了。hs_dma_framework 的价值就在于把每一层的接口都定义得清清楚楚FPGA 侧只要保证 Stream 接口按协议出数驱动侧只要保证描述符和中断能正常流转应用层只要管好 mmap 的内存。这个边界一旦清晰排查问题就变成了“哪一层不符合接口约定”的判断题。另外给你的建议是设计初期就预留好调试接口。我在 FPGA 逻辑里放了计数器能统计总采集点数、FIFO 溢出次数、DMA 完成次数驱动里放了 debugfs 节点能实时查看中断次数、描述符状态和缓冲区水位。这些“望远镜”在系统出问题的时候比什么逻辑分析仪都管用。现在这套框架跑在好几个项目里有的做相控阵信号采集有的做图像传输有的做软件无线电换一个场景只需要换前端数据格式和 DMA 配置参数后面再扩展多通道、多 DMA 引擎互斥时也有了一个可靠的地基。
