简介：面向STM32F4X嵌入式开发者，这份压缩包提供了I2C总线通信的完整实现，同时给出硬件外设驱动与软件模拟两条路径，适合需要掌握不同I2C实现方式的中级开发者参考。包内共2个文件，分别是程序源码I2C.c和配套头文件I2C.h，整体仅4KB，结构精简，便于快速阅读、剪裁和移植到实际项目。硬件I2C方案基于芯片内置外设，覆盖GPIO复用配置、标准/快速模式速率设定、起始停止条件、读写字节等核心操作，充分发挥硬件时序优势，适合高速稳定传输。软件模拟方案则通过GPIO口搭配延时函数精确生成SCL/SDA电平变化，完整模拟主机发送流程，适合硬件I2C不可用或引脚受限、速率要求不高的场景。资源已有157人学习下载，代码注释清晰，主干函数一目了然，对照学习能直观理解两种方式的时序差异和适用边界，同时为后续驱动EEPROM、温湿度传感器等常见I2C器件提供可复用的底层基础。
1. I2C 没那么玄，难点全在“谁控制时钟”这件事上
拿到“I2C.zip_STM32F4X_模拟I2C_硬件I2C_软件模拟I2C”这个标题时，我第一反应不是去解压什么压缩包，而是先确认一件事：你手上到底有没有对应的源码。如果只有这个压缩包文件名，那这更像是一份资料归档，里面大概率放着 STM32F4 系列上 I2C 的硬件驱动、软件模拟实现和移植笔记。但不管里面装了什么，I2C 这个协议的难度不在于协议本身，而在于 STM32F4 的硬件 I2C 外设从库时代就被人诟病“锁死”“卡死”“进不了中断”，以至于很多人最终选择 GPIO 模拟时序来绕过它。
这篇文章我把两条路都讲透：硬件 I2C 用寄存器加 HAL 库分析状态机，软件模拟 I2C 用 GPIO 逐位翻转电平。适合三种人：一是正在 STM32F407 上接 EEPROM、传感器、0.96 寸 OLED 屏的开发调试者；二是被 I2C 总线锁死问题折腾到想换方案的人；三是想彻底搞懂 ACK/NACK、时序翻转、时钟极性这些底层细节的嵌入式工程师。读完之后你能回答“我到底该用硬件 I2C 还是模拟 I2C”，也能照着代码直接改出能跑的版本。
2. 硬件 I2C 与软件模拟 I2C 的选型逻辑：时序、中断与总线锁死
2.1 硬件 I2C 外设的真实面目：状态机驱动的“伪主从模式”
STM32F4 的硬件 I2C 外设本质上是一个独立于 CPU 的状态机，你写一个起始条件到控制寄存器，之后 SCL 时钟由硬件产生，SDA 数据由移位寄存器自动送出。外设自己维护主模式发送、主模式接收、从模式发送、从模式接收四种状态，每个状态通过事件标志位EV5、EV6、EV8等反映在状态寄存器SR1和SR2里。
裸机编程时，一次完整的主模式写操作要经过这些步骤：
// 初始化 I2C1，PB6=SCL，PB7=SDA，时钟 42MHz -> 400kHz RCC->AHB1ENR |= RCC_AHB1ENR_GPIOBEN; RCC->APB1ENR |= RCC_APB1ENR_I2C1EN; GPIOB->MODER |= (GPIO_MODER_MODER6_1 | GPIO_MODER_MODER7_1); // 复用模式 GPIOB->OTYPER |= (GPIO_OTYPER_OT_6 | GPIO_OTYPER_OT_7); // 开漏输出 GPIOB->AFR[0] |= (4 << 24) | (4 << 28); // AF4: I2C1 I2C1->CR1 |= I2C_CR1_SWRST; // 先复位外设 I2C1->CR1 &= ~I2C_CR1_SWRST; I2C1->CR2 = 42; // APB1 时钟 42MHz I2C1->CCR = 210; // 400kHz: CCR = 42MHz / (2 * 400kHz) I2C1->TRISE = 17; // 400kHz 模式下最大上升时间 100ns I2C1->CR1 |= I2C_CR1_PE; // 使能外设代码里CCR = 210和TRISE = 17是关键参数，400kHz 快速模式下时钟脉宽由CCR直接决定，TRISE则告诉外设总线允许的最大上升沿时间。能影响零点几个微秒的时序，数据手册里照抄也可能踩坑，因为CCR计算依赖 APB1 时钟频率，不同时钟树配置下同一个数字跑出来的速率完全不同。
硬件 I2C 最大的优势是能不占用 CPU 去完成字节传输，配合 DMA 更是能实现数据自动搬运。但它的缺陷同样明显：状态机太复杂，一旦出现总线错误AF=1、仲裁丢失ARLO=1或者超时TIMEOUT=1，外设可能停在某个异常状态，此时写入控制寄存器不再生效，也就是俗称的“锁死”。
2.2 软件模拟 I2C 为什么能绕过锁死问题
软件模拟 I2C 根本不使用芯片内部的 I2C 外设，而是用两个 GPIO 引脚手动翻转电平，自己控制 SCL 的高低和 SDA 的数据变化。主机想产生一个起始条件，就先拉高 SCL，再把 SDA 从高拉到低；想发一个字节，就在 SCL 低电平期间依次把 8 个 bit 放到 SDA 上，然后拉高 SCL 让从设备采样，再拉低 SCL 继续下一位。
这种做法的直接好处是：不存在硬件状态机，所以根本不会发生“外设卡死”的问题。无论总线上发生什么，你只要把 GPIO 重新初始化，就能立刻恢复通信。代价是每个字节的时序都由 CPU 用延时函数来填充，延时精度决定了通信速率能跑多高，也决定了系统里其他任务的实时性。
#define I2C_SCL_H() GPIOB->BSRRL = GPIO_PIN_6 #define I2C_SCL_L() GPIOB->BSRRH = GPIO_PIN_6 #define I2C_SDA_H() GPIOB->BSRRL = GPIO_PIN_7 #define I2C_SDA_L() GPIOB->BSRRH = GPIO_PIN_7 #define I2C_SDA_READ() (GPIOB->IDR & GPIO_PIN_7) static void i2c_delay_us(uint32_t us) { for (uint32_t i = 0; i < us * 8; i++) { __NOP(); } }BSRRL和BSRRH分别是 GPIO 的置位和复位寄存器，用它们操作引脚只需要一条写指令，比先读ODR再修改要快得多。i2c_delay_us里的8是一个经验值，具体取决于芯片主频和编译器优化级别，同一段代码在-O0和-O2下跑出来的实际延时会相差好几倍，这也是模拟 I2C 在不同工程之间移植时最隐蔽的坑。
2.3 什么时候必须用硬件 I2C，什么时候必须用模拟
判断标准只有一个：总线上挂了多少设备、通信频率和稳定性要求有多高。如果只有一个温度传感器或者一块 OLED 屏，模拟 I2C 完全够用；如果总线上挂了多个不同地址的从设备，或者主控需要以 400kHz 持续读写数据，硬件 I2C 配合 DMA 才是正路。
工业现场更常见的是混合方案：硬件 I2C 指配给高速且数据量大的从设备，比如 IMU 或 ADC；慢速传感器则挂到模拟 I2C 的引脚上。这里有个经验，用软件模拟 I2C 时总线上挂超过 3 个设备，就要额外注意 ACK 时序和电平竞争问题，因为不同从设备对时序偏移的容忍度不同，一个设备应答慢了会影响后续字节的稳定性。
3. 在 STM32F407 上跑通模拟 I2C：时序实现与可移植代码
3.1 最小可实现：起始、停止、发送字节、接收字节
先从底层的字节级操作写起。模拟 I2C 的核心是 4 个函数：起始条件、停止条件、发送一个字节并读取 ACK、接收一个字节并发送 ACK/NACK。这四个函数拼起来就是任何 I2C 设备通信的骨架。
void i2c_start(void) { I2C_SDA_H(); I2C_SCL_H(); i2c_delay_us(5); I2C_SDA_L(); // SCL 高电平期间 SDA 下降沿 -> 起始条件 i2c_delay_us(5); I2C_SCL_L(); } void i2c_stop(void) { I2C_SDA_L(); I2C_SCL_H(); i2c_delay_us(5); I2C_SDA_H(); // SCL 高电平期间 SDA 上升沿 -> 停止条件 i2c_delay_us(5); } uint8_t i2c_write_byte(uint8_t data) { for (uint8_t i = 0; i < 8; i++) { if (data & 0x80) { I2C_SDA_H(); } else { I2C_SDA_L(); } data <<= 1; I2C_SCL_H(); // SCL 拉高，从设备采样 SDA i2c_delay_us(2); I2C_SCL_L(); i2c_delay_us(2); } I2C_SDA_H(); // 释放 SDA，等待从设备 ACK I2C_SCL_H(); i2c_delay_us(2); uint8_t ack = I2C_SDA_READ(); // 低电平 = ACK I2C_SCL_L(); i2c_delay_us(2); return ack == 0 ? 1 : 0; // 返回 1 表示收到 ACK } uint8_t i2c_read_byte(uint8_t ack) { uint8_t data = 0; I2C_SDA_H(); // 释放总线，让从设备驱动 SDA for (uint8_t i = 0; i < 8; i++) { data <<= 1; I2C_SCL_H(); i2c_delay_us(2); if (I2C_SDA_READ()) { data |= 0x01; } I2C_SCL_L(); i2c_delay_us(2); } if (ack) { I2C_SDA_L(); // 主机发送 ACK，表示还需要读下一字节 } else { I2C_SDA_H(); // 主机发送 NACK，表示这是最后一字节 } I2C_SCL_H(); i2c_delay_us(2); I2C_SCL_L(); I2C_SDA_H(); return data; }i2c_write_byte里先发送最高位，I2C 协议是 MSB first；i2c_delay_us(2)对应大约 100kHz 的速率，如果从设备只支持标准模式 100kHz，这个延时可以加一倍，但不要低于 1 微秒，否则 SCL 高电平持续时间太短，从设备可能采样失败。i2c_read_byte的参数ack表示读完这个字节之后是否继续读，当读最后一个字节时必须传 NACK，告诉从设备“别再发了”，否则从设备会一直占用 SDA。
3.2 向 EEPROM 写入一页数据并回读验证
字节级函数就绪后，就可以封装设备级 API。EEPROM 的 I2C 操作通常分三步：发送设备地址加写命令、发送内部寄存器地址、发送数据。以 AT24C02 为例，从机地址是0xA0，片内地址从0x00到0xFF。
#define AT24C02_ADDR 0xA0 // 8 位地址格式，含写位 uint8_t eeprom_write_byte(uint8_t mem_addr, uint8_t data) { i2c_start(); if (i2c_write_byte(AT24C02_ADDR) == 0) return 1; // 从设备无 ACK if (i2c_write_byte(mem_addr) == 0) return 2; // 地址无 ACK if (i2c_write_byte(data) == 0) return 3; // 数据无 ACK i2c_stop(); delay_ms(5); // EEPROM 内部写周期 return 0; } uint8_t eeprom_read_byte(uint8_t mem_addr) { i2c_start(); i2c_write_byte(AT24C02_ADDR); // 伪写，设置目标地址 i2c_write_byte(mem_addr); i2c_start(); // 重复起始条件 i2c_write_byte(AT24C02_ADDR | 0x01); // 读操作 uint8_t data = i2c_read_byte(0); // 只读一字节，发 NACK i2c_stop(); return data; }注意读操作中间有一个i2c_start()，这是在总线忙时向从设备宣告“我要切换方向”。很多初学者写成先 stop 再 start，这样也能工作但多占总线时间，并且某些 EEPROM 对“伪写后立刻 stop”的处理会造成状态残留。重复起始条件在 I2C 协议里是合法操作，也符合多数从设备的状态机设计。
delay_ms(5)是写入后必须等待的内部写周期，不同型号的 EEPROM 从 3 毫秒到 10 毫秒不等，如果写完后立刻读取，大概率会读到 0xFF，这是新手最容易误判为“I2C 不通”的陷阱。
3.3 模拟 I2C 的常见踩坑：上拉电阻、引脚复用、速度异常
模拟 I2C 最常遇到的三个问题，按出现频率排序是：SDA 一直为低、读回全 F、波形频率和预期差太多。
SDA 一直为低，首要检查 GPIO 是否配置成了开漏模式并且外部接了上拉电阻。I2C 协议要求 SDA 和 SCL 必须是开漏输出，如果你用了推挽输出，多个设备同时驱动总线时可能造成短路。开漏模式下必须要有上拉电阻，常见 4.7kΩ，400kHz 模式下可以换成 2.2kΩ。
读回全 F 分两种：如果读地址阶段就失败，多半是地址不对或者从设备不在总线上；如果地址阶段正常但数据全是 F，那多半是 SDA 释放时机有问题，i2c_read_byte里必须在 SCL 拉高之前让 SDA 完全释放，否则从设备看到 SDA 一直被主机强驱动，就根本不会尝试拉低发送数据。
速率不准的根源是i2c_delay_us里的延时依赖时钟频率和编译器优化。同一个函数在 MDK-O2 下可能跑出 200kHz，换到 IAR-O3 就成了 500kHz。解决办法是不要追求延时函数的精确性，而是先确定你自己目标速率是多少，用示波器测一次实际翻转频率再微调循环次数；没有示波器的话，把延时值写大一些，100kHz 的容错范围比 400kHz 宽得多。
4. 硬件 I2C 的 HAL 库实现：参数配置、DMA 丢数据与恢复策略
4.1 用 CubeMX 生成配置的正确姿势与关键参数开关
STM32F407 在 STM32CubeMX 里配置 I2C1 时，最核心的参数不是速率，而是这几个选项：时钟速度选 100000 还是 400000；时钟极性选Low；时钟相位选Edge1；应答模式选Ack。前两个参数决定时序基准，后两个决定 SCL 和 SDA 的相对位置，多数情况下保持默认即可，但如果你从别的工程复制过来的代码出现“时序对但设备不响应”，就要检查这两个参数和从机数据手册是否匹配。
HAL 库的函数调用方式和裸机寄存器完全不同，因为 HAL 库把状态机的每一步都封装成 API，并在内部加了超时判断：
I2C_HandleTypeDef hi2c1; hi2c1.Instance = I2C1; hi2c1.Init.ClockSpeed = 400000; hi2c1.Init.DutyCycle = I2C_DUTYCYCLE_2; hi2c1.Init.OwnAddress1 = 0; hi2c1.Init.AddressingMode = I2C_ADDRESSINGMODE_7BIT; hi2c1.Init.DualAddressMode = I2C_DUALADDRESS_DISABLE; hi2c1.Init.OwnAddress2 = 0; hi2c1.Init.GeneralCallMode = I2C_GENERALCALL_DISABLE; hi2c1.Init.NoStretchMode = I2C_NOSTRETCH_DISABLE; HAL_I2C_Init(&hi2c1);DutyCycle这个参数只影响快速模式下的占空比，I2C_DUTYCYCLE_2表示 2:1，配合CCR寄存器实现 400kHz，I2C_DUTYCYCLE_16_9则是 16:9 的占空比。NoStretchMode默认DISABLE表示允许从设备拉低 SCL 延长时钟周期，如果开启，从设备失去时钟同步手段，部分传感器会直接不工作。
实际上 CubeMX 生成的MX_I2C1_Init比我上面手写的长得多，原因是里面包含了HAL_I2C_MspInit回调函数对 GPIO 和时钟的分步初始化。HAL 库的设计哲学是底层初始化和业务初始化分离，MspInit里只管引脚、时钟、DMA 通道，Init里只管外设参数。
4.2 阻塞、中断、DMA 三种传输方式的超时与错误处理差异
HAL 库给 I2C 封装了三种传输模式，阻塞模式的HAL_I2C_Master_Transmit会一直等待事件标志，直到超时计时器耗尽；中断模式在每完成一个字节时触发回调；DMA 模式则把数据交给外设自动搬运，传输完成后在 DMA 中断里再触发 I2C 完成回调。
uint8_t data_buf[32]; HAL_StatusTypeDef status; status = HAL_I2C_Mem_Write(&hi2c1, AT24C02_ADDR, 0x00, I2C_MEMADD_SIZE_8BIT, data_buf, 32, 100); if (status != HAL_OK) { Error_Handler(); }这个函数的参数分别是：I2C 句柄、设备地址、内存地址、内存地址宽度、发送缓冲、数据长度、超时毫秒数。I2C_MEMADD_SIZE_8BIT对应 EEPROM 是 8 位地址，如果是 16 位地址的 EEPROM 比如 AT24C256，要换成I2C_MEMADD_SIZE_16BIT，地址字节数和从设备状态机的匹配不能错。
阻塞模式最直接但最危险，超时时间内没有完成传输，函数返回HAL_TIMEOUT，此时 I2C 外设可能处于半完成状态，不能直接重发，要先复位外设再用。DMA 模式效率最高，但坑也最多：DMA 传输完成中断和 I2C 完成中断的先后顺序在不同芯片上有差异，极少数情况下 DMA 认为传完了、I2C 还差最后一个字节在总线上，这时你直接关 DMA 外设会丢掉尾巴数据。
4.3 总线锁死的完整恢复序列：复位外设、切换 GPIO、恢复时序
STM32F4 的 I2C 总线锁死本质上是 SCL 被主机拉低后没有释放，或者 SDA 被某个从设备拉低不放。硬件外设由于自身状态机陷入 BUSY 状态，后续的传输都无响应。常见的恢复方法不是直接改寄存器，而是按这个顺序操作：
void i2c_bus_recover(void) { // 1. 确保 I2C 外设关闭 __HAL_I2C_DISABLE(&hi2c1); // 2. 把 I2C 的两个引脚切到普通 GPIO 输出 GPIO_InitTypeDef gpio = {0}; gpio.Pin = GPIO_PIN_6 | GPIO_PIN_7; gpio.Mode = GPIO_MODE_OUTPUT_OD; gpio.Pull = GPIO_PULLUP; gpio.Speed = GPIO_SPEED_FREQ_VERY_HIGH; HAL_GPIO_Init(GPIOB, &gpio); // 3. 手动产生 9 个时钟脉冲 HAL_GPIO_WritePin(GPIOB, GPIO_PIN_6, GPIO_PIN_RESET); // SCL 拉低 for (int i = 0; i < 9; i++) { HAL_GPIO_WritePin(GPIOB, GPIO_PIN_6, GPIO_PIN_SET); // SCL 拉高 HAL_Delay(1); HAL_GPIO_WritePin(GPIOB, GPIO_PIN_6, GPIO_PIN_RESET); HAL_Delay(1); } // 4. 产生一个停止条件 HAL_GPIO_WritePin(GPIOB, GPIO_PIN_7, GPIO_PIN_RESET); // SDA 拉低 HAL_GPIO_WritePin(GPIOB, GPIO_PIN_6, GPIO_PIN_SET); // SCL 拉高 HAL_Delay(1); HAL_GPIO_WritePin(GPIOB, GPIO_PIN_7, GPIO_PIN_SET); // SDA 拉高 // 5. 重新初始化 I2C 外设 HAL_GPIO_DeInit(GPIOB, GPIO_PIN_6 | GPIO_PIN_7); MX_I2C1_Init(); }9 个时钟脉冲能让总线上锁死的从设备完成内部状态复位，因为 I2C 协议规定从设备在收到 9 个时钟后必须释放 SDA，这是从设备复位总线异常的标准操作。第 4 步的停止条件通知所有从设备“一次传输已经结束”，此后会释放对 SDA 的占用。
最值得注意的细节是调换HAL_GPIO_Init和MX_I2C1_Init的顺序：必须先做 GPIO 手动时序，再把引脚交还给 I2C 复用功能。如果先重新初始化 I2C 外设，外设会立刻接管引脚，而这时总线上还是锁死状态，恢复序列完全无效。
5. 硬件 I2C 与 DMA 的配合：高频读写与环形缓冲设计
5.1 用 DMA 连续读取 IMU 数据的工程写法
接 IMU 这种需要高频读数的传感器，纯轮询模式会把 CPU 时间耗在等标志位上，更合理的设计是 DMA 自动搬运。以读取 6 轴数据为例，IMU 的寄存器地址是连续的，可以用HAL_I2C_Mem_Read_DMA一次性读取 12 个字节：
uint8_t imu_raw[12]; volatile uint8_t imu_data_ready = 0; HAL_I2C_Mem_Read_DMA(&hi2c1, IMU_ADDR << 1, 0x1B, I2C_MEMADD_SIZE_8BIT, imu_raw, 12); // 注册回调函数，在传输完成后处理数据DMA 完成回调在 HAL 库里通过HAL_UART_RxCpltCallback类似的机制实现，但 I2C 有自己的回调名称，需要重定义HAL_I2C_MemRxCpltCallback：
void HAL_I2C_MemRxCpltCallback(I2C_HandleTypeDef *hi2c) { if (hi2c->Instance == I2C1) { imu_data_ready = 1; // 置标志位，在主循环中消费数据 // 如果需要连续采样，可以在这里立即发起下一次传输 } }回调函数里不建议做浮点转换或 PID 运算，因为 CPU 中断优先级抢占耗时较长，而 DMA 需要重新配置才能发起下一次传输。常见做法是置标志后立刻由主循环完成数据解析，如果采样率超过 1kHz，可以考虑在回调里直接调用下一次HAL_I2C_Mem_Read_DMA形成链式搬运，但要小心回调重入问题。
5.2 DMA 与硬件 I2C 传输完成顺序问题的实际规避方法
很多工程师在 IMU 的数据里看到“最后一个字节永远不对”，根因是 I2C 外设停止条件的产生时机。DMA 传输完成中断发生在最后一个字节写完移位寄存器但还没有彻底送出时，此时总线事务可能还需要一个额外的时钟周期来发送停止条件。如果你紧跟HAL_I2C_Mem_Read_DMA就读取数据缓冲，最后一个字节还在路上，读到的自然 是上上次的值。
规避方法是在 DMA 完成回调里加一个极短延时再操作数据，但更彻底的办法是使用 I2C 外设的NBYTES配置让硬件知道本次传输总长度。ST 在一些系列芯片提供了 I2C 超时寄存器TIMEOUT参数，配置该寄存器后由硬件自动插入等待周期，能消除大部分因为 CPU 抢占导致的中断与 DMA 不同步问题。
__HAL_I2C_ENABLE(&hi2c1); // 确保传输结束后外设仍使能 // 关键：等待 BUSY 标志清除 while (__HAL_I2C_GET_FLAG(&hi2c1, I2C_FLAG_BUSY)) { // 有超时保护，避免死循环 }等BUSY标志清除再进入下一次传输看起来简单，实际能避免两个设备交替访问 I2C1 时的“重叠传输”问题。HAL 库的I2C_IsErrorOccurred函数也会检查总线状态，但它更多用于报告错误码，不能替代应用层对 DMA 缓冲区的保护。
5.3 两条 I2C 总线并用时的资源分配与中断优先级原则
STM32F407 有 I2C1、I2C2、I2C3 三条外设总线，再加上 GPIO 模拟的软总线，同一颗芯片能拖四套 I2C 设备。分配原则是：中断服务程序里访问的设备用 I2C1 加 DMA，主循环轮询的设备用 I2C2 阻塞模式，上线较慢或容易卡死的设备一律挂模拟 I2C。
中断优先级需要刻意安排。I2C 事件中断优先级不要高于 DMA 的传输完成中断，否则可能出现：“I2C 事件先到，中断抢占 CPU，DMA 一直没完成搬运，I2C 外设数据被覆盖”。在 NVIC 里把 DMA 中断优先级设置为最高一档，I2C 事件中断低一档，就能让数据搬运在总线空闲前完成。
6. 验证时序与排查失效：示波器看什么、逻辑分析仪怎么接
6.1 示波器探头接法的精确位置与地线考量
用示波器看 I2C 时序时，接探头的位置决定了你能看到什么。SCL 接 CH1，SDA 接 CH2，地线夹子接系统 GND。用弹簧地线替代长鳄鱼夹地线能明显抑制噪声，因为长地线形成环路天线，400kHz 上升沿的高次谐波会被耦合进来，在 SDA 波形上看到振铃。
探头量程打到 1x，会限制带宽但更适合观察 3.3V 逻辑电平的翻转细节。如果示波器支持协议解码功能，先设置 I2C 的地址位宽为 7 位，再设置速率匹配，多数情况下能直接看到从机 ACK 的位置和地址字节内容，省去手算波形的时间。
6.2 从波形一眼定位 ACK 丢失、时钟拉伸与短时毛刺
正常波形里每一字节的高电平段之后，第九个时钟周期是 ACK 位。主机释放 SDA 的瞬间会有一个小的上升沿，如果从设备 ACK，SDA 拉低保持到第九个时钟结束；如果 NACK，SDA 始终为高。没有示波器时，可以用逻辑分析仪抓全帧数据，再匹配起始条件后的第一个字节。
时序代码里试过加长延时后仍然失败，优先怀疑从设备的时钟拉伸功能。部分传感器会在内部处理数据时主动拉低 SCL，此时主机必须检测到 SCL 被拉低并等待它再次变高才能继续，否则会发出重叠的数据，而模拟 I2C 的i2c_delay_us延时不检查 SCL 状态，直接翻转就会破坏时序。可以在i2c_start和每个字节发送后检查 SCL 输入引脚的电平：
uint16_t timeout = 1000; while (I2C_SCL_READ() == 0) { // 等待从设备释放 SCL if (--timeout == 0) return 1; }这段代码放在i2c_write_byte和i2c_read_byte里SCL_H()后面即可支持时钟拉伸，也是模拟 I2C 能适配更多传感器的关键补丁。
6.3 用逻辑分析仪回放验证写入值与实际数据帧的一致性
逻辑分析仪抓到的数据帧应该和代码指定的完全一致。用 AT24C02 写入操作举例，波形上会依次出现：起始条件、地址字节0xA0、内存地址0x00、数据字节、ACK 位、停止条件。若波形里地址字节是0x50，说明地址拼错了，0xA0是带写位的 8 位地址，而 HAL 库的HAL_I2C_Mem_Write内部会自动把设备地址左移运算后填入寄存器。
最后给一个验证手段：在 EEPROM 的某地址写入一个特定值，读回来比对，连续执行 100 次，任何一次不匹配都说明时序边界没有留足余量。建议在 400kHz 硬件 I2C 下执行，然后切到 100kHz 再执行，两次都通过才能算通信稳定。读取失败时的打印信息建议带上状态寄存器的原始值：
printf("I2C error: SR1=0x%04X SR2=0x%04X\r\n", hi2c1.Instance->SR1, hi2c1.Instance->SR2);SR1的第 0 位是发送数据寄存器空TXE，第 1 位是总线忙BUSY，第 10 位是超时TIMEOUT；SR2则记录当前是主模式还是从模式、是否有总线错误。这些位组合起来能直接定位锁死具体原因：如果 BUSY 一直为 1 而其它位都是 0，说明外设不认为自己完成了传输，需要走 5.3 节的总线恢复流程。
本文还有配套的精品资源，点击获取
