📚 课程目录第3章 DMA描述符与链表配置

3. DMA描述符与链表配置

DMA描述符，说白了就是DMA控制器的工作指令单。你告诉它「从哪搬数据、搬到哪、搬多少、搬完怎么通知我」，它照着做。我见过不少工程师在这上面栽跟头——描述符结构体定义不对齐，链表初始化指针乱飞，中断回调里干耗时操作……嗯，今天咱们就把这些坑一个个填平。

3.1 描述符结构体定义

先看一个典型的DMA描述符结构体。以常见的32位DMA控制器为例：

typedef struct {
    uint32_t    next_desc;      // 下一个描述符地址（物理地址）
    uint32_t    src_addr;       // 源地址
    uint32_t    dst_addr;       // 目标地址
    uint32_t    control;        // 控制字：长度、传输类型、中断使能等
    uint32_t    status;         // 状态字：完成标志、错误标志等
    uint32_t    reserved;       // 保留，用于32字节对齐填充
} dma_desc_t __attribute__((aligned(32)));

这里有个关键点——内存对齐。为什么非要32字节对齐？

核心原因：大多数DMA控制器在读取描述符时，会一次性burst读取整个描述符块。如果地址没对齐，轻则性能下降，重则直接触发总线错误。

我曾在某款ARM Cortex-M7芯片上调试一个音频采集丢数据的bug。查了两天，最后发现描述符地址只做了16字节对齐，而DMA硬件要求32字节对齐。每次描述符读取都会多占一个总线周期，在高频传输时直接导致FIFO溢出。嗯，从那以后我再也不敢忽略对齐属性了。

对齐要求	典型场景	后果（不对齐）
4字节对齐	简单P2P传输	性能下降10-20%
16字节对齐	普通链表模式	偶发总线错误
32字节对齐	高速/多通道传输	严重时系统挂死
64字节对齐	Cache一致性场景	数据一致性问题

个人习惯：不管芯片手册写的是多少，我统一按32字节对齐。多占的填充空间（比如上面结构体里的reserved字段）换来的是稳定性和可移植性。你想想看，一个描述符才多占十几个字节，系统里动辄几百个描述符，这点开销完全可以接受。

3.2 链表初始化

描述符链表，本质上就是一个单向链表。每个节点指向下一个节点，最后一个节点的next_desc指向NULL（或者指向头节点形成环形）。

初始化步骤其实不复杂，但顺序很重要：

分配内存池——在SRAM中划出一片连续区域，按32字节对齐分配
清零所有描述符——防止残留数据干扰
配置每个描述符的传输参数——源地址、目标地址、传输长度
链接指针——desc[i].next_desc = &desc[i+1]
收尾处理——最后一个描述符的next_desc指向头节点（环形）或置NULL
将首地址写入DMA控制器的描述符基址寄存器

看一段实际代码：

#define DESC_NUM    64
dma_desc_t desc_pool[DESC_NUM] __attribute__((aligned(32), section(".sdram")));

void dma_chain_init(void)
{
    int i;
    // 清零
    memset(desc_pool, 0, sizeof(desc_pool));

    for (i = 0; i < DESC_NUM; i++) {
        desc_pool[i].src_addr  = (uint32_t)(src_buf + i * BLOCK_SIZE);
        desc_pool[i].dst_addr  = (uint32_t)(dst_buf + i * BLOCK_SIZE);
        desc_pool[i].control   = BLOCK_SIZE | DMA_CTRL_IE;  // 使能中断
        desc_pool[i].status    = 0;

        // 链接：最后一个指向头节点，形成环形
        if (i == DESC_NUM - 1)
            desc_pool[i].next_desc = (uint32_t)&desc_pool[0];
        else
            desc_pool[i].next_desc = (uint32_t)&desc_pool[i + 1];
    }

    // 将首地址写入DMA寄存器
    DMA->DESC_BASE = (uint32_t)&desc_pool[0];
    DMA->CHAIN_CTRL = DMA_CHAIN_EN;
}

我曾经踩过的坑：描述符池放在DMA控制器不可访问的内存区域。某次我把描述符放在D-Cache使能的区域，但没有做Cache维护。DMA从内存读描述符时读到了Cache里的旧数据，而CPU已经更新了描述符。表现就是——传输行为完全不可预测，有时候正常，有时候数据错位。解决方案：要么把描述符放在非Cache区域，要么每次更新描述符后手动Clean & Invalidate。

3.3 中断回调机制

DMA传输完成后的中断处理，是性能调优的重头戏。很多人的第一反应是在中断里做大量工作——拷贝数据、唤醒任务、更新状态……结果中断延迟飙升，系统吞吐量反而上不去。

我建议的中断回调设计原则：

中断里只做最轻量的事——清标志、读状态、记录完成描述符索引
把耗时操作推给任务级——数据搬运、协议解析、回调通知
使用无锁环形队列——中断往队列里写，任务从队列里读

来看一个实际的中断处理框架：

// 中断服务函数
void DMA_IRQHandler(void)
{
    uint32_t status = DMA->STATUS;
    uint32_t desc_idx = (DMA->CURR_DESC - (uint32_t)desc_pool) / sizeof(dma_desc_t);

    if (status & DMA_STATUS_TC) {
        // 将完成的描述符索引写入环形队列
        if (ringbuf_write(&done_queue, &desc_idx, 1) != 0) {
            // 队列满——丢数据了，记录错误
            error_counter++;
        }
        DMA->STATUS = DMA_STATUS_TC;  // 清中断标志
    }

    // 触发任务级处理（如使用FreeRTOS）
    BaseType_t xHigherPriorityTaskWoken = pdFALSE;
    vTaskNotifyGiveFromISR(xDmaTaskHandle, &xHigherPriorityTaskWoken);
    portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
}

// 任务级处理
void DmaProcessTask(void *param)
{
    uint32_t idx;
    while (1) {
        ulTaskNotifyTake(pdTRUE, portMAX_DELAY);  // 等待中断通知

        while (ringbuf_read(&done_queue, &idx, 1) == 0) {
            // 在这里做真正的数据处理
            process_dma_data(&desc_pool[idx]);
            // 重新配置描述符，放回链表
            desc_pool[idx].control |= DMA_CTRL_IE;
        }
    }
}

性能数据对比：我在一个4路音频采集项目中做过实测。中断里直接处理数据时，每路采样率只能跑到48kHz，CPU占用率85%。改成中断+任务模式后，每路跑到96kHz，CPU占用率反而降到40%。为什么？因为中断里不做复杂运算，中断延迟从15μs降到2μs，DMA传输效率大幅提升。

3.4 知识结构总览

下面这张图把描述符与链表的核心逻辑串起来了。你对照着看，思路会更清晰：

总结三个核心要点：

对齐是命根子——描述符结构体必须按硬件要求对齐，32字节是安全值
链表初始化要闭环——环形链表记得首尾相连，避免DMA跑飞
中断回调要「轻」——中断里只做标志和队列操作，真正的处理交给任务

我个人习惯在项目初期就把描述符链表封装成一个独立的模块，提供init、start、stop、callback_register四个接口。这样后续换芯片、换DMA外设时，只需要改底层实现，上层应用代码几乎不用动。你想想看，这能省多少调试时间？