序言
久闻STM32硬件I2C坑多，之前做的项目浅尝主机通信就偶尔遇到总线锁死的bug，网上解决方案也很多，用着也还行。然而作为从机就是另一个大坑了，官方例程少，网上资料少，api也说的不明不白。本文整合各位博主分享的资料，记录和分享调试linux主机与STM32的I2C通信过程中遇到的问题和解决方案，最终在STM32L051C8T单片机实现DMA方式的I2C从机。
单片机资源紧张，性能低但是实时性高。要充分发挥单片机实时特性，在处理低速IO时应该尽量用硬件方式实现，尽可能利用硬件处理数据。DMA就是解放CPU负载的利器。
HAL库API分析
一般来说HAL库的通信io类API分为polling阻塞，IT和DMA方式。而I2C分主从模式，不同I2C器件有不同的协议细节，在此基础还要向上支持SMBus/PMBus等协议，导致API冗杂。API大概可以按以下方式组合：
【主机/从机】-【序列】-【阻塞/中断/DMA】-【收/发】
其中主机模式特有【内存存取】模式
例如：
HAL_I2C_Master_Transmit， 为【主机阻塞方式普通发送】
HAL_I2C_Mem_Read_DMA，为【主机DMA方式读从机内存】
HAL_I2C_Slave_Seq_Transmit_DMA，为【从机序列DMA方式发送】
【主从机】决定是谁发送SCL
【阻塞/中断/DMA】决定单片机内部存取数据方式，影响CPU和总线使用率
【收/发】决定数据传输方向
参考大佬对HAL库Seq相关API的分析。【内存存取】和【序列】是对基础收发API的更高级封装，前者可以通过单个函数实现对从设备内存的存取，典型用处是存取EEPROM。但是实际上大多数I2C设备通信协议不如EEPROM简单，所以这个API简单使用但局限。后者【序列】方式弥补了适用局限，这类API允许主从机对连续占用和监听，即主机可以不产生Stop而产生ReStart信号，大大扩展了HAL库的适用条件。
然而如同更新HAL_UARTEx_ReceiveToIdle之前一样，STM32L0固件V1.12.0版本不支持任意长度数据收发，只能收发定长数据。实际使用中不可能要求主机收发数据长度固定不变。经过阅读代码和测试，发现从机【序列】方式收发不定长数据会导致I2C句柄报错。主机提前停止收发数据，从机都会报NACK错误，导致无法进入正确回调函数，进行下一轮通信。
代码分析
STM32硬件i2c从机DMA: 基于HAL库函数的STM32单片机I2C从机代码，DMA（Seq）方式通信。 - Gitee.com
定义收发数组，初始化模块变量。这里将addr和slave_rx变量放在一起方便DMA接受数据时，第一个数据直接填入结构体第一个变量。考虑到主机写入不一定从0地址开始，所以收发数组要独立。dir暂时没用，只凑齐4字节。rxlen是接受长度，不包含地址字节。
当主机发数据不满DMA计数时，进入这个回调函数，需要我们字节计算收到的字节数。并开启下一轮通信。
监听到总线广播从机地址，进入到这个回调函数，在这里判断收发并初始化监听。注意这里的【I2C_LAST_FRAME】参数，会影响到DMA传输完成时的回调函数，这里这样配置会导致DMA传输完成后不调用I2C_DMASlaveReceiveCplt（初始化监听时注册的）。详见这里。
当然如果主机收发的字节数刚好和DMA计数一样，我们也应当要开启新一轮传输。于是这里先实现DMA传输完成的回调函数，放到<stm32l0xx_it.c>对应的DMA终端里面，要注意判断DMA通道。
从机监听入口函数，在主函数或初始化时调用即可。
参考资料
总结一下首次使用HAL库STM32f030硬件IIC从机中断收发
STM32 HAL I2C（IIC）通信的序列传输(restart condition)
简书也太难用了
