STM32硬件SPI驱动AD7124多通道采集：寄存器配置与避坑指南

简介：SPI作为嵌入式系统中应用最广泛的同步串行接口，其时钟极性与相位的正确配置直接决定外设通信成败。在高精度数据采集场景中，24位Σ-Δ ADC的寄存器映射与多通道切换逻辑往往是开发者最容易踩坑的环节。本文以STM32硬件SPI外设驱动AD7124为例，从寄存器读写原语、通道映射配置、滤波建立时间到连续转换模式的数据读取流程，系统梳理一套可复用的多通道采集驱动方案。结合寄存器回读异常、数据低位恒零、通道切换漂移等高频问题进行排查分析，并介绍DMA搬运与外部基准等二次开发方向。适合工业采集、传感器信号调理及多通道数据记录仪开发者参考。

1. 硬件SPI控制AD7124：一个曾被配置表逼疯的多通道读取驱动

做过多通道数据采集的都知道，AD7124 这颗 24 位 Σ-Δ ADC 到手第一周基本都在跟寄存器配置较劲：光初始化就要写复位时序、电源寄存器、配置寄存器和八个通道映射，一不留神 SPI 时序配置错，读回来的数据要么全是 0xFF，要么低 12 位恒定为零，用示波器戳都戳不出问题出在哪。这份资源解决的核心问题就是把 AD7124 的硬件 SPI 读取做成一套可复用的多通道驱动，在 STM32 上通过硬件 SPI 外设完成寄存器读写和 8 通道数据采集，省掉软件模拟 SPI 里那些让时序充满玄学的忙等逻辑。适合正在做工业采集、传感器信号调理或多通道数据记录仪的开发者，读完能直接照着接线、移植配置表、跑通一次真实转换。

2. 整体框架与硬件设计：从引脚定义到寄存器布局

2.1 AD7124 的寄存器体系：先看懂通讯地图

AD7124 的所有操作都是通过 SPI 寄存器读写完成的，芯片内部寄存器分成两组：通讯寄存器（0x00）和配置/数据寄存器（0x01 到 0x25）。通讯寄存器本身是写入操作的入口，任何一次读或写寄存器的动作，都要先向总线发一个通讯寄存器字节，告诉芯片接下来要访问哪个寄存器、是读还是写、是连续操作还是单次操作。

通讯寄存器字节的位定义是固定的：最高位 0 表示后续是写寄存器操作，1 表示读；低五位是目标寄存器地址；而位 5 和位 6 组合决定操作模式是单次还是连续。很多第一次接触这颗芯片的人会把通讯寄存器当作普通寄存器去读，结果读回来的字节根本不是状态，而是一个回显，这就是对地址映射理解错了。

寄存器空间里，真正和采集强相关的是这几个：电源控制寄存器（0x07）控制 ADC 的使能和内部参考源；配置寄存器（0x09 到 0x0F）决定增益、滤波和单端/差分模式；通道映射寄存器（0x10 到 0x17）把模拟输入引脚分配到通道；数据寄存器（0x04 到 0x05）存放转换结果，但实际读取时用的是 0x04 复用的连续读地址。

2.2 硬件连接：DIN、DOUT、SCLK、CS 与 RDY

AD7124 的 SPI 接口有五个关键引脚：SCLK 是串行时钟，DIN 是命令和数据写入线，DOUT/ADIN 是数据输出线，CS 是片选，DOUT/RDY 引脚在转换完成时会拉低表示数据就绪。STM32 这边我用的是 SPI2 外设，四根线与 AD7124 一一对应，唯一要额外处理的是 RDY 信号——它既能当作 GPIO 中断源，也可以直接轮询读取。

接线建议按“主从共地、SPI 引脚直连、RDY 单独拉一个 GPIO 输入”的方式排布：

SCLK 的速率不建议一上来就拉到 10MHz，AD7124 虽然支持最高 16MHz 的时序，但布线稍长或者电平转换电路没做好的情况下高速率非常容易丢位。我通常先设 1MHz 跑通一遍寄存器回读测试，确认所有寄存器都能正确读写后再逐步提速到 5MHz，这样排查问题会容易很多。

2.3 SPI 外设初始化：时钟极性和相位不能猜

硬件 SPI 和软件模拟 SPI 最大的区别在于，极性（CPOL）和相位（CPHA）一旦配错，整条链路没有一个字节是对的。AD7124 的时序要求在 CPOL=1、CPHA=1 这一组上可以正常工作，也就是 SCLK 空闲时为高电平，数据在第二个边沿采样。不同驱动版本有人写 0x00，有人写 0x03，区别就在 SPI_CR1 寄存器的这两位配置。

STM32 HAL 库的初始化配置长这样：

SPI_HandleTypeDef hspi2; void AD7124_SPI_Init(void) { hspi2.Instance = SPI2; hspi2.Init.Mode = SPI_MODE_MASTER; hspi2.Init.Direction = SPI_DIRECTION_2LINES; hspi2.Init.DataSize = SPI_DATASIZE_8BIT; hspi2.Init.CLKPolarity = SPI_POLARITY_HIGH; // CPOL = 1 hspi2.Init.CLKPhase = SPI_PHASE_2EDGE; // CPHA = 1 hspi2.Init.NSS = SPI_NSS_SOFT; hspi2.Init.BaudRatePrescaler = SPI_BAUDRATEPRESCALER_32; hspi2.Init.FirstBit = SPI_FIRSTBIT_MSB; HAL_SPI_Init(&hspi2); }

BaudRatePrescaler 取 32 意味着如果 SPI2 挂在 APB1 上且时钟为 42MHz，SCLK 实际是 1.3125MHz，这个速率在调试阶段非常安全。CLKPolarity 和 CLKPhase 是这组初始化里最不能抄错的两行——很多人拿其它 SPI 器件的初始化代码直接套用，读 AD7124 的 ID 寄存器永远失败，问题不是芯片坏了，是时序相位根本不对。代码里 Direction 用了双线模式而不是半双工，因为 AD7124 的 DIN 和 DOUT 是独立的，读写可以同时进行，虽然单次操作只使用其中一个方向的数据，但双线设置能避免在 DMA 场景下切换方向时的额外开销。

2.4 复位时序：用 64 个 DIN 高电平把芯片拉回已知状态

AD7124 上电后寄存器状态并不保证是全零，尤其是配置寄存器的默认值可能和期望值不一致。可靠的做法是在初始化前执行一次软件复位，方法是让 DIN 引脚持续输出 64 个 SCLK 周期的高电平，然后等待至少 500ms 让芯片完成内部复位。这里的坑是：64 个高电平必须连续发送，中间不能插入寄存器操作，否则芯片会把它误判为非法命令。

复位实现的常规写法是循环发送一个字节 0xFF，同时保证 SCLK 在期间连续翻转：

void AD7124_SoftReset(void) { uint8_t reset_bytes[8] = {0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF}; AD7124_CS_LOW(); for (int i = 0; i < 8; i++) { HAL_SPI_Transmit(&hspi2, &reset_bytes[i], 1, 100); } AD7124_CS_HIGH(); HAL_Delay(600); // 等待内部复位完成 }

这里发送 8 个字节共 64 位，完全覆盖数据手册要求的 64 个 SCLK 周期。CS 在整个复位序列中保持低电平，期间不能有任何其它 SPI 操作，否则复位序列被打断，芯片可能进入未知状态——这类问题在调试时表现特别诡异，表现为后续写配置寄存器时有时成功有时失败。复位完成后的 600ms 延时是个保守值，实测 200ms 通常也能工作，但在高温或电源波动场景下我给足了裕量，驱动上线后不需要再因为启动时序问题返工。

3. 核心代码拆解：寄存器读写原语与初始化链路

3.1 寄存器读写原语：一字节命令加 N 字节数据的固定格式

AD7124 的任何一次操作都遵守同一个 SPI 帧结构：先发一字节通讯寄存器命令，再发目标寄存器的数据字节。读操作是命令后直接读 MISO，写操作是命令后继续往 MOSI 发数据。封装成底层原语之后，上层配置代码不需要每次关心通讯寄存器怎么拼。

uint8_t AD7124_ReadRegister(uint8_t reg_addr) { uint8_t cmd = 0x40 | (reg_addr & 0x3F); // 读命令: bit6=1 uint8_t rx_data = 0; AD7124_CS_LOW(); HAL_SPI_Transmit(&hspi2, &cmd, 1, 100); HAL_SPI_Receive(&hspi2, &rx_data, 1, 100); AD7124_CS_HIGH(); return rx_data; } void AD7124_WriteRegister(uint8_t reg_addr, uint8_t value) { uint8_t cmd = 0x00 | (reg_addr & 0x3F); // 写命令: bit6=0 uint8_t tx_buf[2] = {cmd, value}; AD7124_CS_LOW(); HAL_SPI_Transmit(&hspi2, tx_buf, 2, 100); AD7124_CS_HIGH(); }

写寄存器时把命令字节和数据字节一并发送，CS 在整帧传输期间保持拉低，完成后拉高。读操作则拆成 transmit 和 receive 两步，原因是 HAL 库的全双工收发函数需要预先准备接收缓冲，而这里接收缓冲只有一个字节，分开写逻辑更清晰。参数里 reg_addr 取值 0x00 到 0x25，不超过 6 位所以直接与 0x3F 做掩码。CS 每次操作都要重新拉低拉高，这能让芯片在每个操作结束后回到命令等待状态，避免连续操作模式下地址指针错位。

3.2 通道配置：CHMAP 寄存器的位级拼装

多通道读取版的核心不在读数据而在通道配置。AD7124 每个通道对应一个通道映射寄存器 CHMAP0 到 CHMAP7，8 位内容里 bit7 使能通道，bit6 和 bit5 选择正输入引脚（AIN0 到 AIN7），bit4 选择负输入引脚（AIN0 到 AIN3 或参考地）。单端模式里负端统一选 AINCOM，需要把 bit4 设 0。

下面是一个把第 0 到第 7 通道统一配置成单端输入的循环写法：

typedef struct { uint8_t enable; uint8_t positive_pin; // 0~7 -> AIN0~AIN7 uint8_t negative_pin; // 0~3 -> AIN0~AIN3, 0xFF -> AINCOM uint8_t config_index; // 关联 CONFIG0~CONFIG7 } AD7124_ChannelConfig; void AD7124_ConfigChannel(uint8_t ch, AD7124_ChannelConfig *cfg) { uint8_t chmap = 0x00; if (cfg->enable) chmap |= 0x80; if (cfg->negative_pin == 0xFF) chmap |= (0x00 << 4); // AINCOM else chmap |= ((cfg->negative_pin & 0x03) << 4); chmap |= ((cfg->positive_pin & 0x07) << 1); chmap |= (cfg->config_index & 0x01); // 每个通道可指定 CONFIG 序号 AD7124_WriteRegister(0x09 + ch, chmap); }

这里 0x09 + ch 的地址偏移对应寄存器映射表，CHMAP0 的地址是 0x10，但因为驱动在写寄存器原语里已经用 0x00 开头做写命令，实际传给 WriteRegister 的地址是寄存器编号 0x09 加通道号，底层会再拼成带 bit6=0 的通讯命令字节。逻辑上要特别注意 positive_pin 的移位是左移 1 位而不是左移 0 位，CHMAP 的位分配是 bit7 使能、bit6-5 负输入、bit4-1 正输入、bit0 配置序号——很多人把正输入直接塞进 bit0 导致通道映射完全错乱。

配置完成后，通道并不会自动开始转换，还需要在电源控制寄存器里把对应通道的 enable 位打开，也就是将通道映射寄存器的 bit7 写 1。上面的代码里 enable 字段会在 chmap 里体现，但如果你在运行中动态切换通道，需要把旧通道禁用、新通道启用，并在禁用后等待一个滤波周期再启用，否则前一个通道的残余电荷会影响新通道的首次采样。

3.3 滤波与建立时间：配置寄存器里的二进制陷阱

AD7124 的配置寄存器 CONFIG0 到 CONFIG7 控制增益、滤波字和参考源。滤波字直接影响输出数据速率和建立时间，而建立时间是多通道采集里最容易被低估的参数。滤波字存在 CONFIG 寄存器的低 10 位，数值与输出速率成反比：滤波字越大，滤波器截止频率越低，对应的建立时间越长。

很多驱动里直接用默认滤波字就跑多通道，结果就是通道切换后读到的数据前几十个点还在“漂”。配置寄存器写入代码的一个典型片段如下：

#define AD7124_CONFIG_BIPOLAR (0x00 << 2) // 双极性 #define AD7124_CONFIG_UNIPOLAR (0x01 << 2) // 单极性 #define AD7124_CONFIG_GAIN_1 (0x00 << 5) #define AD7124_CONFIG_GAIN_128 (0x07 << 5) void AD7124_SetConfig(uint8_t cfg_index, uint8_t gain, uint8_t filter_word_lsb, uint8_t filter_word_msb) { uint16_t config_val = 0x0000; config_val |= (gain & 0x07) << 5; config_val |= (filter_word_lsb & 0x0F); config_val |= (filter_word_msb & 0x03) << 8; uint8_t buf[2]; buf[0] = (config_val >> 8) & 0xFF; buf[1] = config_val & 0xFF; AD7124_WriteRegister(0x19 + cfg_index, buf[0]); AD7124_WriteRegister(0x1A + cfg_index, buf[1]); }

配置寄存器的地址被拆分成两个字节分别写入，因为 AD7124 的寄存器宽度是 16 位，写操作需要两字节。增益放在 bit7 到 bit5，滤波字的低 4 位放在 bit3 到 bit0，高 2 位在 bit9 到 bit8——这里的位偏移非常容易搞混，一旦写错增益和滤波字就会错位，采集到的数据和实际值差一个固定的倍数。建立时间的计算通常直接用滤波器建立时间 + 一个安全裕量，如果滤波字配置导致建立时间超过 100ms，多通道轮询周期就必须拉长，否则上一个通道的数据会污染下一个通道的读取。

3.4 数据读取：状态字节与 24 位有效数据的拼接

转换结果在 DATA 寄存器里占 3 字节，但读取时实际会额外返回一个状态字节，放在数据之前。也就是说，一次完整的数据读取需要连续读出 4 字节：第一个字节是状态（bit6 是通道错误标志，低 4 位是当前通道编号），后三个字节才是 24 位转换值。

uint32_t AD7124_ReadDataWithChannel(uint8_t *channel) { uint8_t cmd = 0x40 | 0x04; // 读 DATA 寄存器 uint8_t rx_buf[4] = {0}; uint32_t raw = 0; AD7124_CS_LOW(); HAL_SPI_Transmit(&hspi2, &cmd, 1, 100); HAL_SPI_Receive(&hspi2, rx_buf, 4, 100); AD7124_CS_HIGH(); *channel = rx_buf[0] & 0x0F; // 状态字节低4位 raw = ((uint32_t)rx_buf[1] << 16) | ((uint32_t)rx_buf[2] << 8) | ((uint32_t)rx_buf[3]); // 双极性模式：24位有符号数转 mV 需根据基准电压换算 return raw; }

状态字节里的通道号在连续转换模式下非常有价值——你可以一次性把多个通道都点开，然后在某个通道的 DOUT/RDY 拉低时读取数据，状态字节会告诉你现在处理的是哪个通道，而不需要靠外部引脚判断。这段代码里 rx_buf[0] 的最高位是 VDD 电源监测位，bit5 是 CRC 错误位，如果使能了 CRC 校验，bit5 为 1 表示本次 SPI 帧传输有错。数据拼接时注意位移方向，rx_buf[1] 是最高字节所以要左移 16 位，这个细节一旦写错，读出来的数值会混乱成完全无规律的状态，且这种错误在调试器里看起来像接触不良，很难定位。

4. 多通道读取流程：从轮询到一次完整采集循环

4.1 单次转换模式与连续转换模式的选择

AD7124 支持单次转换和连续转换两种模式。单次转换适合低功耗场景，每次需要读取时先写 ADC 控制寄存器触发一次转换，然后等待 DOUT/RDY 拉低再读数据。连续转换则适合多通道快速采集，所有已使能的通道会按顺序自动转换，每次数据准备好后 DOUT/RDY 都会拉低一次。

多通道读取版选择了连续转换模式，核心原因是避免单次模式里频繁写触发命令带来的 SPI 总线开销。通道使能后，芯片内部的通道序列器会自动依次完成每个通道的转换，输出一个 4 字节帧后就进入下一个通道。这个过程中 SPI 主机不需要干预，只需要在每一次 DOUT/RDY 下降沿读取一帧数据即可。

连续模式初始化代码：

void AD7124_StartContinuous(void) { // ADC 控制寄存器地址 0x01 // bit7 内部参考使能，bit6 参考缓冲使能 // bit4-2 操作模式：101 为连续转换 uint8_t adc_ctrl = 0x80 | 0x00 | (0x05 << 2); AD7124_WriteRegister(0x01, adc_ctrl); }

ADC 控制寄存器被写成 0x80 使能内部 2.5V 参考，加上 101b 的模式位。如果使用外部参考，bit7 写 0 即可。模式位是 bit4 到 bit2，连续转换模式的二进制是 101，单次转换是 000。这里最容易翻车的是把 bit1 和 bit0 当作模式位，那是保留位，写错不会报错但芯片的行为会完全不符合预期。

4.2 通道序列的切换机制：不是你想切换就立刻切换

连续模式下，芯片内部序列器的工作方式是：从通道 0 开始，检测到使能位为 1 的通道就执行转换，完成后跳到下一个使能的通道；如果某个通道的使能位为 0，直接跳过。这个机制意味着如果你在运行中修改了通道映射，修改并不会在下一个转换周期立即生效——通道序列器已经完成了当前的扫描循环，修改会在下一轮扫描开始后反映。

轮询读取多通道的完整循环长这样：

void AD7124_PollAllChannels(uint32_t *results, uint8_t ch_count) { for (uint8_t i = 0; i < ch_count; i++) { // 等待当前通道转换完成 while (HAL_GPIO_ReadPin(RDY_GPIO_Port, RDY_Pin) != GPIO_PIN_RESET); uint8_t ch; results[i] = AD7124_ReadDataWithChannel(&ch); // 校验返回的通道号是否与预期一致 if (ch != i) { // 可能原因：通道使能配置不一致或上一帧数据未读走 // 处理方式：丢弃本次数据，重新同步 results[i] = 0; } } }

这里用 RDY 电平判断数据是否就绪是一种朴素但有效的方式。DOUT/RDY 引脚在转换完一个通道后自动拉低，主机读取一帧完整数据后它会回到高电平。如果上一次数据还没读走，新的转换完成后 RDY 会继续保持低电平，这会导致轮询逻辑误判为“新数据来了”，读出旧数据。上面代码里通过状态字节回读的通道号做校验，就是用来抓这种“数据滞后”问题的。

连续模式下最隐蔽的问题是数据同步：如果 SPI 读帧和芯片内部转换完成不同步，比如主机因为中断延迟读迟了，状态字节里的通道号会发生跳变。驱动里用回读通道号和预期通道号对比的方式处理，一旦发现不匹配，就把本次结果置 0 并强制等待当前帧读完后重新对齐。

4.3 多通道数据的通道标识与时间戳

多通道版本与单通道版本最大的差异在数据记录：回读的数据本身没有相对时间信息，只有状态字节里的通道号。如果你的采集系统需要知道每个采样点的精确时间，最好的办法是在驱动层给每帧数据打一个本地时间戳。

typedef struct { uint32_t timestamp_ms; uint8_t channel; int32_t raw_value; } AD7124_Sample; void AD7124_CollectSamples(AD7124_Sample *samples, uint8_t count) { uint32_t start = HAL_GetTick(); for (uint8_t i = 0; i < count; i++) { while (HAL_GPIO_ReadPin(RDY_GPIO_Port, RDY_Pin) != GPIO_PIN_RESET); uint8_t ch; uint32_t raw = AD7124_ReadDataWithChannel(&ch); samples[i].timestamp_ms = HAL_GetTick() - start; samples[i].channel = ch; samples[i].raw_value = (int32_t)(raw << 8) >> 8; // 符号扩展 } }

将 24 位原始值转换成有符号数时用了“先左移 8 位再算术右移 8 位”的技巧，C 语言里对 uint32_t 直接做右移不会有符号扩展，必须借助将 24 位值挪到 int32_t 最高位附近再移回。这段代码在多通道场景里每次采样都携带时间戳和通道号，数据分析时就能直接按通道分组画趋势，不需要再通过循环序号倒推通道来源。使用 HAL_GetTick 作为时间基准在短周期采集里够用，但如果你做的是长时间记录，要考虑 tick 翻转的问题，常见做法是把高 16 位 tick 和低 16 位拼接成 64 位毫秒计数。

5. 避坑指南：AD7124 驱动调试中的四个高频问题

5.1 寄存器回读全是 0xFF 或 0x00

现象：初始化完成后回读任何寄存器都得到 0xFF 或 0x00，不是预期值。

原因排查下来有三个：SCLK 极性相位配错、CS 时序不对、复位序列没有完成。0xFF 通常是 SPI 相位错误导致 MISO 上的数据没有被正确采样，主机读到的是总线空闲电平；0x00 则往往是 CS 被拉低后芯片根本没进入命令接收状态，芯片没有任何响应。

解决方法是先用逻辑分析仪抓一拍 SCLK 和 MOSI 的时序，看通讯寄存器命令字节是否在 SCLK 的对应边沿被采样到。我的调试顺序是：先确认 CS 低有效时间覆盖整个帧，再确认 CPOL/CPHA 与 0x03 组合一致，最后确认复位延时足够。这三个点单独检查都很快，但你如果一上来就怀疑芯片坏了换芯片，大概率换完还是同一个现象。

5.2 读到的数据只有高位在变，低 12 位恒为零

现象：输入电压变化时读到的数值能跟着变化，但精度明显不足，低位全为零。

原因是 SPI 数据帧多读或者少读导致字节错位。很多人读数据时习惯只接收 3 个字节，但 AD7124 的数据寄存器是 4 字节协议（状态 + 数据），如果你只读 3 字节，寄存器指针会停在半截，第二次读数据的帧对齐就乱了。低位恒零的另一个原因是滤波字配置过小，后级数字滤波把噪声全部滤掉的同时也把有效位数削掉了。

解决：固定每次读取 4 字节，且保证命令字节里读地址是 0x04，数据必须从 0x05 地址开始读也可以，但保持统一更重要。滤波方面，建议先把滤波字配到中等位置（比如 1000 附近），观察数据跳动范围是否合理，不要一开始追求极低噪声配大滤波字，那样切换通道时的建立时间会让人崩溃。

5.3 通道切换后前几个点数据漂移严重

现象：多通道轮询时，每次切换通道后前 3 到 5 个采样点数值偏离真实值，之后恢复正常。

这个问题的根源是滤波器建立时间。每个通道的输入源在做通道切换后会经历一次重新建立过程，滤波器需要数个输出周期才能收敛到真实值。如果驱动在切换通道后不等待建立时间直接读取，读到的第一个点基本可以确定是上一个通道的残留。

解决：在通道序列器切换后，主动丢弃前两个数据帧，第三个帧再作为有效数据。更严格的方式是查配置寄存器滤波字对应的建立时间，用延时或丢弃 N 帧的方式保证数据完全建立。我常用做法是加一个 —> 在使能新通道后调用一个 WaitForSettling(channel_config) 函数，内部根据当前滤波字计算需要丢弃的帧数，避免在代码里写死 3 这个魔数。

5.4 使能 CRC 后 SPI 通信全乱

现象：在通讯寄存器或者配置寄存器里开启了 CRC 校验后，原有的读写函数全部失效，回读数据错乱。

AD7124 有内建 CRC 校验，但很多驱动默认不开。一旦开启，每一个 SPI 帧后面都需要额外发/收一个 CRC 字节，原有的“命令 + 数据”两字节帧就变成了“命令 + 数据 + CRC”。如果驱动层没有同步修改帧长度，主机读到的 CRC 字节会被当作下一个寄存器地址，芯片状态机直接跑飞。

解决：如果不需要在物理层检测误码，最简单的方式是干脆不开 CRC。如果为了可靠性必须开，那么底层所有收发函数都要升级成三字节帧，读操作是先发命令，再收数据，再收 CRC，然后计算 CRC 与收到的字节比对。

6. 二次开发：往驱动里加 DMA、外部基准和增益自动调整

拿到这套驱动后再往下走，通常不是改寄存器映射，而是往采集链路上加东西。最实用的一步改造成 DMA 搬运数据：当前轮询方式在高速连续模式下会占用大量 CPU 时间，改成 DMA 后 SPI 外设自动把 4 字节帧搬进内存，CPU 只需要在每个转换完成中断里做通道号校验和滤波计算。

void AD7124_StartDMARead(DMA_HandleTypeDef *hdma, uint8_t *buf, uint16_t len) { // 使能 SPI 的连续读模式 AD7124_WriteRegister(0x01, 0x80 | (0x05 << 2)); // 启动 DMA 传输：底层自动把 RX 数据填满 buf HAL_SPI_Receive_DMA(&hspi2, buf, len); // 在 DMA 完成中断里解析帧： // 每 4 字节为一帧，第 1 字节是状态，后 3 字节是数据 }

DMA 模式下 SPI 外设在每收到一个字节后会自动触发下一次接收，不需要 CPU 干预。唯一需要注意的坑是 DMA 循环里对通道号的同步：如果 DMA 没有在帧边界上启动，首帧可能从数据字节开始而不是状态字节，这时要做一次对齐操作——通过判断某字节低 4 位是否为通道号序列来重新找到帧头。这个对齐操作比 GPIO 轮询要复杂，但它能换来 CPU 从 SPI 等待中完全解放。

第二个值得做的改造是把参考源从内部 2.5V 切换到外部基准，同时加一节增益自动标定的代码。具体思路是利用一个已知的精准电压（比如 1.000V），启动采集并读取原始值，反推实际增益误差，然后在主程序里用这个误差系数修正所有通道的换算公式。这样能消除基准电压漂移带来的系统误差，对需要精度的测量非常有用。

第三个方向是做滤波字的动态调整：初始化时先用大滤波字保证稳定，建立可靠通信后逐步减小滤波字提高响应速度，直到数据噪声在可接受范围内。这种动态调整比固定滤波字更适合既要精度又要多通道切换速度的场景。

每一次在拿到新 AD7124 板卡时，我仍然会先从AD7124_ReadRegister(0x04)回读验证 SPI 链路，再走一遍通道配置、建立时间等待、数据读取三件套，确认示波器上的波形和寄存器值完全对得上才继续往下改。这个习惯曾经帮我快速发现过某块板上 SCLK 上拉电阻导致的电平漂移问题，多通道采集的稳定性往往不在芯片算法，而在这些边界条件下的细心验证。希望这套驱动的拆解能帮你在自己的工程里少走一段弯路。

本文还有配套的精品资源，点击获取