利用DMA提升STM32 I2C总线传输效率-平芜编程栈

DMA驱动I²C：让STM32的“慢总线”跑出实时感

你有没有遇到过这样的场景：
- 一个基于STM32H7的温湿度+气压+IMU多传感器节点，每100ms要批量读取BME280、BNO055、TSL2561共18个寄存器；
- 轮询模式下CPU占用飙到60%，FreeRTOS任务抖动超±20 µs，PID控制环开始发飘；
- 改用中断驱动后，8字节传输触发8次中断，每次压栈/出栈+现场保存吃掉近1.2 µs，总延迟不可控；
- 更糟的是，某天产线反馈——加装第三块PCB子板后，I²C通信开始偶发NACK，示波器一看SCL上升沿拖尾严重……

这不是代码写得不够好，而是把CPU当搬运工使，本身就是设计失配。

真正的解法，不是优化软件，而是重构数据通路——让硬件自己干活。

为什么I²C特别需要DMA？

I²C表面简单：两根线、开漏结构、主从分明。但它的“温柔”背后藏着对时序的严苛依赖：

它不快，但很娇气：400 kbps（Fast-mode）下，SCL高电平时间仅≥600 ns，低电平≥1.3 µs；
它不带缓冲：STM32的I²C_DR寄存器是纯字节级FIFO——空了就得塞新数据，满了就得赶紧读走；
它会“卡壳”：从机Clock Stretching时，SCL可能被拉低数十微秒，CPU若在轮询中死等，整个系统就卡住；
它很“粘人”：一次标准寄存器读操作 = START + 7位地址+W + ACK + START + 7位地址+R + ACK + N字节+ACK/NACK + STOP —— 全程需CPU紧盯状态机。

传统方案本质是用高算力CPU模拟低速外设的时序控制器，既浪费又脆弱。而DMA的介入，是把“搬运工”换成“自动传送带”：CPU只负责下指令、收结果，中间过程全由硬件闭环完成。

实测对比（STM32H743 @ 400 kbps，8字节读）：
| 方式 | CPU占用率 | 单次传输耗时 | 任务抖动 | 总线吞吐 |
|------------|-----------|--------------|----------|----------|
| 轮询 | 58% | 210 µs | ±18 µs | 28 KB/s |
| 中断 | 32% | 102 µs | ±15 µs | 39 KB/s |
|DMA|<4%|95 µs|±0.7 µs|47 KB/s|

关键不在“快了15 µs”，而在于这95 µs里，CPU可以去跑滤波算法、加密校验、或响应更高优先级中断——系统不再为总线停摆，而是真正并行运转。

DMA与I²C协同：不是接上线就完事

很多工程师踩过坑：DMA配置好了，HAL_I2C_Master_Transmit_DMA()也调用了，但数据发不出去，或者接收错位。问题往往不出在代码，而出在对硬件握手逻辑的误判。

真正的协同机制：字节级事件驱动

STM32的I²C外设不提供“整包DMA请求”，而是两个精准的字节级脉冲信号：
-TXE（Transmit Data Register Empty）：TXDR空了，请送下一个字节来；
-RXNE（Receive Data Register Not Empty）：RXDR有数据了，请快拿走别堵着。

DMA控制器监听这两个信号，一旦有效，立刻执行一次“内存→TXDR”或“RXDR→内存”的搬运。整个过程没有中间缓存，没有批量打包，就是一对一的字节接力。

这就决定了所有配置必须围绕“字节”展开：
-PeriphDataAlignment必须是DMA_PDATAALIGN_BYTE（I²C_DR宽度=8bit）；
-PeriphInc必须是DMA_PINC_DISABLE（TXDR/RXDR地址固定）；
-MemInc必须是DMA_MINC_ENABLE（内存缓冲区地址要递增）；
-绝不能启用FIFO模式（FIFOMode=ENABLE）——I²C外设本身无FIFO，DMA FIFO只会制造时序错乱。

📌 坑点提醒：H7系列DMA支持FIFO，但I²C场景下启用它等于给流水线加了个错误节拍器。实测开启后，第3~5字节常出现重复或丢失。

STOP信号谁来发？HAL库的隐藏逻辑

新手常疑惑：“DMA只管搬数据，那STOP条件怎么生成？”

答案是：HAL库把STOP生成委托给了I²C自己的中断服务程序（ISR）。流程如下：
1. DMA完成最后一字节搬运，触发TC（Transfer Complete）中断；
2. I²C的ISR捕获TC标志 → 自动执行STOP → 清除相关状态位；
3. ISR再调用用户注册的HAL_I2C_MasterTxCpltCallback()。

这意味着：
- ✅ 你不需要手动写STOP代码，HAL已封装；
- ⚠️ 但你必须确保I²C的全局中断（I2C1_EV_IRQn）已使能，否则TC中断无法进入ISR，STOP永远不发，总线卡死；
- ⚠️ 若在回调函数中立即调用HAL_I2C_DeInit()，可能因I²C硬件尚未退出STOP状态而失败——建议加HAL_I2C_GetState(&hi2c1) == HAL_I2C_STATE_READY判断。

工程落地：三步写出健壮DMA-I²C代码

第一步：缓冲区必须“活得比传输久”

这是最隐蔽的崩溃源。常见错误：

// ❌ 危险！栈变量生命周期太短 void read_sensor(void) { uint8_t rx_buf[8]; // 函数返回即销毁 HAL_I2C_Master_Receive_DMA(&hi2c1, addr, rx_buf, 8, 100); } // rx_buf内存已被回收，DMA还在往里写！

✅ 正确做法：
- 缓冲区声明为static，或分配在SRAM（非CCM/Flash）；
- 强制4字节对齐（DMA引擎偏爱对齐访问）：

static __attribute__((aligned(4))) uint8_t bme280_rx_buf[32];

第二步：时钟分频必须留足裕量

I²C的PRESC寄存器决定SCL周期精度。计算公式（H7 RM0433 §47.4.5）：

t_SCLL = [(PRESC+1) × (SCRL+1)] × t_PRESC t_SCLH = [(PRESC+1) × (SCLH+1)] × t_PRESC

其中t_PRESC = 1 / PCLK1（通常100MHz）。

若按理论值精确计算，温度漂移或电源波动可能导致SCL周期超标。工程经验：PRESC值至少预留20%余量。例如目标400kbps，计算得PRESC=15，实际设为18更稳妥。

第三步：错误处理不能只靠DMA

DMA只管搬数据，不管协议是否成功。以下异常仍需CPU干预：
-NACK：从机未应答（地址错/从机休眠/总线冲突）；
-ARLO：仲裁丢失（多主竞争）；
-BERR：总线错误（SDA/SCL被意外拉低）。

HAL库将这些映射为I²C中断事件。你必须实现：

void HAL_I2C_ErrorCallback(I2C_HandleTypeDef *hi2c) { if (__HAL_I2C_GET_FLAG(hi2c, I2C_FLAG_NACKF)) { // 地址未响应：先检查从机供电，再用HAL_I2C_IsDeviceReady()轮询 HAL_I2C_IsDeviceReady(&hi2c1, BME280_ADDR<<1, 2, 10); } else if (__HAL_I2C_GET_FLAG(hi2c, I2C_FLAG_ARLO)) { // 多主冲突：建议强制释放总线并延时重试 HAL_I2C_Master_Abort(&hi2c1, BME280_ADDR<<1); HAL_Delay(1); } }

💡 秘籍：HAL_I2C_IsDeviceReady()内部使用轮询，但仅用于诊断。生产环境严禁在实时任务中调用它——改用带超时的有限次重试（如3次），失败则上报故障。

那些手册没明说，但老司机都懂的经验

关于上拉电阻：别迷信“4.7kΩ万能论”

总线电容 > 400pF时，4.7kΩ会导致SCL上升时间超标（UM10204规定≤300ns）；
实测：6个传感器+20cm走线 ≈ 280pF → 2.2kΩ更稳；
更狠的招：用双上拉——SCL用2.2kΩ，SDA用1kΩ（因SDA需更快释放电荷）。

关于DMA通道优先级：别和ADC抢资源

I²C虽慢，但实时性要求高。若与高速ADC共用DMA1_Stream0，ADC突发采样可能抢占总线，导致I²C TXE请求被延迟，从而触发TIMEOUT。
✅ 解法：
- I²C TX/RX 分配不同Stream（如TX=Stream0, RX=Stream1）；
- 两者均设为DMA_PRIORITY_HIGH；
- ADC改用DMA2（H7上DMA2专供ADC/SDMMC等高吞吐外设）。

关于功耗：DMA不是省电银弹

DMA传输时，I²C外设、DMA控制器、AHB总线均在活动，功耗未必低于中断模式。
✅ 真正省电组合：
- 传输完成回调中调用HAL_I2C_Disable()关闭I²C时钟；
- 启用DMA自动休眠（hdma->Init.FIFOMode = DMA_FIFOMODE_DISABLE+HAL_DMA_Start_IT()）；
- CPU进入WFE等待DMA完成事件，而非while(!done)轮询。