STM32F103的I2C外设这几年在社区里一直是"劝退"重灾区，很多工程师一上来就被"硬件I2C难用、容易卡死"的言论劝退，转头去用GPIO模拟时序。我实际把两种方式都在AT24C02上完整跑过之后发现，问题多半出在状态机事件的判断顺序、总线电气特性的配合，以及EEPROM写周期这个固有物理特性上。这篇就把STM32F103通过硬件I2C访问AT24C02的全流程拆开讲清楚，从器件选型、协议机制、驱动代码到调试波形，尽量把每一步的"为什么"也一并说透。适合刚开始接触I2C通信的初学者，也适合被硬件I2C折腾过、想彻底搞明白问题出在哪的开发者参考。1. 为什么拿AT24C02练手：从器件特性反推通信设计1.1 256字节的小容量，恰好够覆盖I2C所有核心场景AT24C02是ATMEL（现在属于Microchip）经典的I2C接口EEPROM，容量2Kbit，也就是256字节，组织成32页，每页8字节。这个容量在今天看来小得可怜，但在学习场景里反而是优点：地址空间小，调试时可以直接用读命令把整片内容dump出来，不用像操作大容量Flash一样考虑分块、磨损均衡这些额外因素。器件挂在I2C总线上的地址由硬件引脚A2、A1、A0的电平决定，7位器件地址中高4位固定为1010，低3位由引脚决定，再加上1位读写方向位，就构成了完整的第一帧地址字节。比如A2=A1=A0都接地，则器件地址是0xA0（写方向）或0xA1（读方向）。这个设计初看有点绕，但一旦理解了"地址字节 = 固定前缀 + 引脚配置 + 方向位"的结构，后续换个型号的EEPROM，或者换成传感器芯片，同样能快速上手。1.2 页写8字节限制：这是EEPROM和RAM最本质的区别AT24C02不是每次写一个字节就要等一个写周期，它内部有一个8字节的页缓冲。一次写操作如果不超过页边界，数据会先写入页缓冲，然后启动内部编程。问题在于：一旦写入的字节数跨越了页边界，比如从地址0x07开始连续写3个字节，第三个字节就会回卷到本页的页首地址（0x00），把之前写好的数据覆盖掉。这一点在实际项目中制造了大量"写进去的数据是乱的"的问题，排查到最后才发现是跨页回卷。所以驱动函数里必须做分页写入的逻辑：先计算当前地址到本页末尾还剩多少字节，每次写入量取"剩余空间"和"待写长度"的较小值。这个逻辑看起来很简单，但它就是页写模式和随机写模式之间性能差异的根本原因——不用分页逻辑的话，就只能一个字节一个字节地写，每个字节等5ms写周期，256字节全写一遍要1.28秒；用页写模式配合分页逻辑，可以8字节一组，34次写周期就能写完，耗时大约170ms。1.3 写周期tWR：驱动里最容易被忽略的等待逻辑AT24C02数据手册明确给出写周期时间最大5ms。这意味着每次页写或字节写命令发出之后，器件在内部完成编程期间，不会响应总线上任何新的起始条件。很多初学者写完驱动发现"第一页写成功了，第二页写失败"，原因就是没等这5ms。等待方式有两种：固定延时5ms，或者轮询ACK。轮询ACK的做法是：发完写命令后，主控不断重新发送起始条件和器件地址字节，直到从机返回ACK为止，说明内部编程已经完成。这种做法比固定延时效率高不少，因为实际写周期往往小于5ms，还能避免因电压温度变化导致写时间偏长的情况。后面驱动代码里我会用轮询ACK方案。2. I2C协议核心机制拆解：起始条件、ACK与重复起始开始写代码之前，先把I2C协议最核心的几个概念过一遍，因为驱动里每一行寄存器操作本质上都在操纵这几个物理时序。理解了协议再去读寄存器手册，会有一种"原来是这么对上"的感觉。2.1 起始条件、停止条件与数据有效性I2C总线是双线架构，SCL（时钟线）和SDA（数据线），空闲时两线都被上拉电阻拉高。起始条件定义：SCL保持高电平期间，SDA从高电平跳变到低电平。停止条件定义相反：SCL保持高电平期间，SDA从低电平跳变到高电平。这两个条件是所有通信的开场和收尾，任何命令序列都必须以起始开始、以停止结束。数据位的有效性规则更基础：SDA上的数据只能在SCL低电平期间变化，SCL高电平期间SDA必须保持稳定。换句话说，SCL高电平采样SDA，SCL低电平允许SDA切换。这个规则保证了从机在时钟上升沿总能采到确定的数据位。2.2 ACK机制：从机的"我收到了"信号每个字节传输完成后，接收方要在第9个时钟周期把SDA拉低，表示ACK（应答）；如果接收方不想继续接收，就在第9个周期保持SDA高电平，即NACK。在写场景中，从机每收到一个字节都要回ACK；在读场景中，主控读完最后一个字节后要主动回NACK，表示"我不要了"，然后发停止条件。有一个常见误区：很多人以为NACK只存在于读操作的最后。其实当器件地址匹配失败（比如A2/A1/A0引脚配置错）、或者EEPROM正在写周期内部编程时，从机对地址字节也会不回ACK。所以轮询ACK等待写周期完成的原理，就是靠检测这个NACK到ACK的变化。2.3 重复起始条件（Restart）：从写切换到读的关键随机地址读的时序是：先发一个写方向的器件地址，紧接着发送要读取的字节地址（这个动作叫设置地址指针，也叫dummy write），然后不停止总线，直接再发一个起始条件（即重复起始条件），这次带上读方向的器件地址，之后连续读数据。整个过程中总线始终保持占用。重复起始条件的特殊之处在于：SCL高电平期间SDA先拉高再拉低，完成一个完整的起始时序，但总线上并没有出现停止条件。这样做的好处是原子性——中途不会被其他主机抢占总线（在多主系统中尤其重要），也省掉了两次总线仲裁切换的时间。在STM32的硬件I2C上，重复起始条件是否正确发送，恰恰是后面要讲的最大坑之一。3. 硬件I2C与软件模拟的选型战争：我的实测对比3.1 硬件I2C的争议根源：状态机事件的等待顺序STM32F103的硬件I2C外设本质上是一个独立的状态机，主模式发送、主模式接收都对应一系列事件标志（EV5、EV6、EV7、EV8等）。正确用法的核心是：在每个步骤等待特定事件置位，然后做对应的寄存器操作，再继续等下一个事件。官方库例程里的流程是用while循环轮询事件标志，代码不复杂，但问题在于很多开发者不明白这些事件到底代表底层的什么状态，一旦程序跑飞，完全不知道卡死在哪。我实测中最常遇到的问题有两个：一是START条件发出后没有正确等待SB（EV5）置位就去写DR寄存器；二是主接收模式收完倒数第二个字节时，没有在RDMA之前或之后正确设置ACK/NACK控制位，导致最后一个字节的时序乱掉。这些问题在逻辑分析仪上看波形会非常明显——起始条件之后SDA上根本没有数据位，或者最后一个字节读出来的数据是错的。3.2 软件模拟I2C为什么"看起来更稳定"很多人推荐软件模拟，本质原因是它对时序的控制完全透明。GPIO拉高拉低的每一步都是自己写的延时，就算波形不那么规范，至少从机的时序要求不会被遗漏。而且软件模拟允许把SCL频率调得很低，比如10kHz甚至更低，对长走线、大电容负载的情况更宽容。软件模拟也不是没有代价：占用两个GPIO，且要不停翻转电平，CPU占用率高；如果系统里有中断频繁抢占，SCL上的时钟可能出现毛刺。用RTOS跑I2C采集任务时，软件模拟还要处理临界区保护，复杂度并不比硬件外设低。我的个人结论是：单点通信、线路短、频率要求不高的场合用软件模拟完全没问题；一旦涉及多从机、高频采集、或者主控总线资源有限，硬件I2C省下的CPU时间非常可观。3.3 最终方案：本次工程采用硬件I2C + 中断辅助不绕开坑，直接面对它，才能真正掌握外设。本次工程选择STM32F103的硬件I2C1外设，PB6和PB7引脚，外部上拉电阻4.7kΩ，主模式，标准模式100kHz时钟。驱动层封装两个函数：AT24C02_WriteBytes和AT24C02_ReadBytes，内部处理页写边界、写周期等待和重复起始条件。下面进入代码拆解。4. 核心驱动代码逐段拆解：从起始条件到页写边界4.1 底层I2C时序函数封装（软件模拟版）先看软件模拟版本，因为它的逻辑最直观，有助于建立时序感知。虽然最终工程用的是硬件I2C，但我强烈建议初学者先把软件模拟吃透，再去碰硬件外设。// 软件模拟I2C驱动 - GPIO配置为开漏输出，外部上拉4.7k // SCL: PB6, SDA: PB7 #define I2C_SCL_H() GPIOB->BSRR = GPIO_Pin_6 #define I2C_SCL_L() GPIOB->BRR = GPIO_Pin_6 #define I2C_SDA_H() GPIOB->BSRR = GPIO_Pin_7 #define I2C_SDA_L() GPIOB->BRR = GPIO_Pin_7 #define I2C_SDA_READ() ((GPIOB->IDR & GPIO_Pin_7) != 0) // 微秒级延时，需要根据主频校准 static void i2c_delay_us(uint32_t us) { uint32_t i; for (i = 0; i < us * 8; i++) { __NOP(); } } // 起始条件：SCL高电平期间，SDA由高变低 static void i2c_start(void) { I2C_SDA_H(); I2C_SCL_H(); i2c_delay_us(5); I2C_SDA_L(); i2c_delay_us(5); I2C_SCL_L(); } // 停止条件：SCL高电平期间，SDA由低变高 static void i2c_stop(void) { I2C_SDA_L(); I2C_SCL_H(); i2c_delay_us(5); I2C_SDA_H(); i2c_delay_us(5); } // 发送一个字节，MSB先行 static void i2c_send_byte(uint8_t byte) { for (uint8_t i = 0; i < 8; i++) { if (byte & 0x80) { I2C_SDA_H(); } else { I2C_SDA_L(); } byte <<= 1; I2C_SCL_H(); i2c_delay_us(5); I2C_SCL_L(); i2c_delay_us(5); } } // 接收一个ACK/NACK：释放SDA，拉高SCL，读SDA电平 static uint8_t i2c_wait_ack(void) { I2C_SDA_H(); // 释放SDA，让从机控制 I2C_SCL_H(); i2c_delay_us(5); uint8_t ack = I2C_SDA_READ(); I2C_SCL_L(); i2c_delay_us(5); return (ack == 0) ? 1 : 0; // 返回1表示收到ACK } // 读取一个字节，MSB先行 static uint8_t i2c_read_byte(void) { uint8_t data = 0; I2C_SDA_H(); // 释放SDA，准备由从机驱动 for (uint8_t i = 0; i < 8; i++) { I2C_SCL_H(); i2c_delay_us(5); data <<= 1; if (I2C_SDA_READ()) { data |= 0x01; } I2C_SCL_L(); i2c_delay_us(5); } return data; } // 发送ACK（继续接收） static void i2c_send_ack(void) { I2C_SDA_L(); I2C_SCL_H(); i2c_delay_us(5); I2C_SCL_L(); I2C_SDA_H(); } // 发送NACK（停止接收） static void i2c_send_nack(void) { I2C_SDA_H(); I2C_SCL_H(); i2c_delay_us(5); I2C_SCL_L(); I2C_SDA_H(); }这套函数严格遵守了"I2C_Start -> SendByte -> WaitAck -> ... -> Stop"的流程。代码里所有延时都是5微秒级别，折算下来SCL频率大约在100kHz到200kHz之间，比标准模式的100kHz稍快一点，实际使用中没问题。需要注意的是，SDA引脚模式必须在输出和输入之间切换——发送时开漏输出，读取时释放SDA并切换到输入模式，或者直接靠开漏特性释放，由外部上拉把电平拉高。上面代码里用GPIOB->BSRR/BRR操作，SDA_H实际是把引脚置1，配合开漏输出就是释放总线。这套软件模拟代码我用来做对比测试，也让项目组的实习生先跑通，建立起"起始条件长什么样、ACK长什么样"的直观认知。把它跑通后再接硬件I2C，出问题时就能通过逻辑分析仪快速判断是外设状态机问题还是外部时序问题。4.2 STM32F103硬件I2C外设的初始化配置进入硬件外设环节。STM32F103的I2C外设配置有几个容易忽略的细节，逐个说明。// 硬件I2C1初始化：PB6=SCL, PB7=SDA // 时钟配置：标准模式100kHz，占空比50% // 注意：APB1时钟默认36MHz，I2C1挂载在APB1上 void I2C1_Init(void) { GPIO_InitTypeDef GPIO_InitStructure; I2C_InitTypeDef I2C_InitStructure; // 使能GPIOB和I2C1时钟 RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOB, ENABLE); RCC_APB1PeriphClockCmd(RCC_APB1Periph_I2C1, ENABLE); // PB6/PB7配置为开漏复用功能 GPIO_InitStructure.GPIO_Pin = GPIO_Pin_6 | GPIO_Pin_7; GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_OD; // 复用开漏 GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz; GPIO_Init(GPIOB, &GPIO_InitStructure); // I2C外设配置 I2C_InitStructure.I2C_Mode = I2C_Mode_I2C; I2C_InitStructure.I2C_DutyCycle = I2C_DutyCycle_2; // 占空比2:1 I2C_InitStructure.I2C_OwnAddress = 0x30; // 本机从机地址，主模式用不到但必须非0 I2C_InitStructure.I2C_Ack = I2C_Ack_Enable; I2C_InitStructure.I2C_AcknowledgedAddress = I2C_AcknowledgedAddress_7bit; I2C_InitStructure.I2C_ClockSpeed = 100000; // 100kHz I2C_Init(I2C1, &I2C_InitStructure); I2C_Cmd(I2C1, ENABLE); }两个重要细节。其一，GPIO模式必须选GPIO_Mode_AF_OD，即复用开漏，这是I2C协议本身要求的——因为总线上的线与特性，任何设备都可以拉低总线，开漏输出才能支持多主仲裁。如果误配成推挽复用（AF_PP），总线上一旦有两个设备同时输出高低电平，就可能出现电流倒灌，严重时损坏引脚。其二，I2C_OwnAddress必须设置一个非零值，这是芯片手册的一个隐含要求，即使主模式下本机地址根本不会被用到，不设置会导致外设行为异常。上拉电阻方面，数据手册推荐最小2kΩ，我实测100kHz标准模式下4.7kΩ非常稳定。如果总线走线超过20cm，或者并联设备数量多，可能需要降低到2.2kΩ。别用STM32内部的GPIO上拉，I2C标准明确要求外部上拉，内部上拉阻值在30kΩ到50kΩ之间，驱动能力不足，边沿会变得很缓，干扰下容易误判。4.3 硬件I2C主模式发送：状态机事件的正确等待方式硬件I2C发送一帧数据的标准流程，可以用库函数加事件判断来实现。// 硬件I2C写一个字节的底层函数 // dev_addr: 器件地址（含方向位，写方向） // 返回0成功，非0失败 uint8_t I2C1_WriteByte(uint8_t dev_addr, uint8_t data) { // 1. 发送起始条件 I2C_GenerateSTART(I2C1, ENABLE); // 等待EV5：SB=1，起始条件已发送 uint32_t timeout = 10000; while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_MODE_SELECT)) { if (--timeout == 0) return 1; } // 2. 发送器件地址+写方向 I2C_Send7bitAddress(I2C1, dev_addr, I2C_Direction_Transmitter); // 等待EV6：ADDR=1，地址已发送 timeout = 10000; while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_TRANSMITTER_MODE_SELECTED)) { if (--timeout == 0) return 2; } // 3. 发送数据字节 I2C_SendData(I2C1, data); // 等待EV8：TXE=1，数据寄存器空 timeout = 10000; while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_BYTE_TRANSMITTING)) { if (--timeout == 0) return 3; } // 4. 发送停止条件 I2C_GenerateSTOP(I2C1, ENABLE); return 0; }这段代码看起来简单，但有两个极易踩坑的地方。第一个坑是EV5等待。I2C_GenerateSTART之后，SB置位表示起始条件已经在线路上产生，但此刻总线状态寄存器中的BUSY位可能还没及时更新。如果紧接着就去发送地址，硬件可能还在处理起始条件的收尾，导致发送的地址字节不完整。所以严谨做法是等待EV5之后再操作DR寄存器，依靠事件标志来同步。第二个坑是EV8和EV8_2的区别。I2C_EVENT_MASTER_BYTE_TRANSMITTING（EV8）表示数据寄存器已空，可以写入下一个数据字节，但此时字节可能还没完全移出到总线上；I2C_EVENT_MASTER_BYTE_TRANSMITTED（EV8_2）表示字节移位完成、传输结束标志BTF置位。如果发送的是最后一个字节，停止条件必须在BTF置位之后发出，否则可能截断最后一个字节的停止位。上面的代码发送单字节数据后直接发STOP，理论上应该等待BTF，不过实测单字节场景下EV8事件等待完成再发STOP通常也没问题。但如果是连续多字节发送，最后一个字节发完后必须等待EV8_2，否则会出现数据丢失。这正是社区里"硬件I2C难用"骂声的一个重要来源：标准库的I2C_CheckEvent在判断EV8_2时，有内部软件标志位参与运算，调试起来异常痛苦。中断方式用I2C_ITConfig配置相应中断，在中断服务函数里按状态机推进，代码量更大，但事件响应更及时。4.4 AT24C02驱动：写操作的分页处理与写周期等待有了底层I2C收发函数，现在封装AT24C02的写操作。// AT24C02器件地址定义 // 假设A2=A1=A0=GND，7位地址为0x50，左移1位得到写地址0xA0，读地址0xA1 #define AT24C02_ADDR_W 0xA0 #define AT24C02_ADDR_R 0xA1 // 硬件I2C发送多个字节 // 返回0成功，非0失败 static uint8_t I2C1_WriteMulti(uint8_t dev_addr, uint8_t *data, uint16_t len) { // 发送起始条件 I2C_GenerateSTART(I2C1, ENABLE); uint32_t timeout = 10000; while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_MODE_SELECT)) { if (--timeout == 0) return 1; } // 发送器件地址 I2C_Send7bitAddress(I2C1, dev_addr, I2C_Direction_Transmitter); timeout = 10000; while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_TRANSMITTER_MODE_SELECTED)) { if (--timeout == 0) return 2; } // 逐字节发送数据 for (uint16_t i = 0; i < len; i++) { I2C_SendData(I2C1, data[i]); timeout = 10000; // 除最后一字节外，等待EV8即可继续发下一字节 // 最后一字节必须等待EV8_2（BTF） if (i < len - 1) { while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_BYTE_TRANSMITTING)) { if (--timeout == 0) return 3; } } else { while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_BYTE_TRANSMITTED)) { if (--timeout == 0) return 4; } } } // 发送停止条件 I2C_GenerateSTOP(I2C1, ENABLE); return 0; } // AT24C02写数据核心函数 // addr: 起始字节地址（0-255） // buf: 待写入数据 // len: 待写入字节数 // 自动处理跨页边界和写周期等待 uint8_t AT24C02_WriteBytes(uint16_t addr, uint8_t *buf, uint16_t len) { if (addr > 255 || buf == NULL || len == 0) return 0xFF; if (addr + len > 256) return 0xFE; // 超出容量 while (len > 0) { // 计算本页剩余空间：页大小8字节，页首地址 = addr & 0xF8 uint8_t page_remain = 8 - (addr & 0x07); uint8_t write_len = (len < page_remain) ? len : page_remain; // 发送起始条件 I2C_GenerateSTART(I2C1, ENABLE); uint32_t timeout = 10000; while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_MODE_SELECT)) { if (--timeout == 0) return 1; } // 发送器件写地址 I2C_Send7bitAddress(I2C1, AT24C02_ADDR_W, I2C_Direction_Transmitter); timeout = 10000; while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_TRANSMITTER_MODE_SELECTED)) { if (--timeout == 0) return 2; } // 发送字节地址 I2C_SendData(I2C1, (uint8_t)addr); timeout = 10000; while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_BYTE_TRANSMITTING)) { if (--timeout == 0) return 3; } // 发送数据 for (uint8_t i = 0; i < write_len; i++) { I2C_SendData(I2C1, buf[i]); timeout = 10000; if (i < write_len - 1) { while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_BYTE_TRANSMITTING)) { if (--timeout == 0) return 4; } } else { while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_BYTE_TRANSMITTED)) { if (--timeout == 0) return 5; } } } // 发送停止条件 I2C_GenerateSTOP(I2C1, ENABLE); // 等待写周期完成：轮询ACK timeout = 100000; while (timeout--) { I2C_GenerateSTART(I2C1, ENABLE); while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_MODE_SELECT)) { // 等待EV5 } I2C_Send7bitAddress(I2C1, AT24C02_ADDR_W, I2C_Direction_Transmitter); // 等待地址发送完成，然后检查ACK timeout = 10000; while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_TRANSMITTER_MODE_SELECTED)) { if (--timeout == 0) break; } // 如果ADDR事件正常发生，说明从机返回了ACK，写周期结束 // 注意：需要软件清除ADDR标志后才能继续 // 发送停止条件，结束轮询 I2C_GenerateSTOP(I2C1, ENABLE); break; } // 等待总线空闲 while (I2C_GetFlagStatus(I2C1, I2C_FLAG_BUSY)) { // 等待 } // 更新指针 addr += write_len; buf += write_len; len -= write_len; } return 0; }这段函数有几个关键设计点要展开讲。分页计算的写法：page_remain = 8 - (addr & 0x07)，这里addr & 0x07取的是当前地址在页内的偏移量，比如地址0x07，偏移量是7，页剩余空间是0，说明当前从页的最后一个字节开始写，一次只能写1个字节；地址0x08，偏移量是0，页剩余空间是8，说明正好在页首，可以写满一整页。这个位运算替代了取模运算，在嵌入式环境里效率更高，也更直观。写周期等待的轮询ACK逻辑：停止条件发出后，EEPROM开始内部编程。此时从机对任何地址字节都不响应NACK。主控要不断重新发起起始条件并发送地址，直到从机返回ACK。上面代码里轮询部分用了两次起始条件和停止条件，实际测试中如果不额外发停止条件直接再发起始条件（即重复起始），硬件I2C也能连续操作，但为了保险起见每次重新发起都先STOP再START。这里有一个细节：等待EV5时如果超时没等到，说明总线可能被卡住了，需要额外的总线恢复逻辑。页写模式的顺序：起始条件 -> 器件写地址 -> 字节地址 -> 数据0 ~ 数据N-1 -> 停止条件。这个序列中器件地址和字节地址之间，数据字节和下一个数据字节之间，硬件I2C会自动处理ACK的接收，不需要软件额外干预。软件要做的只是按照EV5/EV6/EV8事件逐步推进。最后把更新指针和剩余长度的逻辑放在while循环尾部，确保每一轮都能推进。这个循环最多会执行32次（256字节按8字节一页全写完的情况），每次循环都会占用CPU等待写周期，实时性要求高的系统建议把这个函数放到任务调度里，不要在主循环里长时间阻塞。4.5 读操作：当前地址读、随机地址读与顺序读读操作比写操作多了一个重复起始条件的环节，这也是很多人在硬件I2C上翻车的地方。AT24C02支持三种读模式：当前地址读（直接读当前地址指针指向的数据）、随机地址读（先设置地址，再读）、顺序读（连续读取多个字节）。驱动里最常用的是随机地址读，时序为：起始 -> 器件写地址ACK -> 字节地址ACK -> 重复起始 -> 器件读地址ACK -> 读数据NACK -> 停止。// AT24C02随机地址读 // addr: 要读取的字节地址 // pData: 存放读取数据 // 返回0成功，非0失败 uint8_t AT24C02_ReadBytes(uint16_t addr, uint8_t *buf, uint16_t len) { if (addr > 255 || buf == NULL || len == 0) return 0xFF; if (addr + len > 256) return 0xFE; // 1. 起始条件 + 写方向器件地址 + 字节地址 I2C_GenerateSTART(I2C1, ENABLE); uint32_t timeout = 10000; while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_MODE_SELECT)) { if (--timeout == 0) return 1; } I2C_Send7bitAddress(I2C1, AT24C02_ADDR_W, I2C_Direction_Transmitter); timeout = 10000; while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_TRANSMITTER_MODE_SELECTED)) { if (--timeout == 0) return 2; } I2C_SendData(I2C1, (uint8_t)addr); timeout = 10000; while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_BYTE_TRANSMITTING)) { if (--timeout == 0) return 3; } // 2. 重复起始条件 I2C_GenerateSTART(I2C1, ENABLE); // 注意：等待EV5时，要检查SB和SMBUS等标志的组合 // 很多卡死问题出在这里的EV5判断不完整 timeout = 10000; while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_MODE_SELECT)) { if (--timeout == 0) return 4; } // 3. 发送读方向器件地址 I2C_Send7bitAddress(I2C1, AT24C02_ADDR_R, I2C_Direction_Receiver); timeout = 10000; while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_RECEIVER_MODE_SELECTED)) { if (--timeout == 0) return 5; } // 4. 接收数据 for (uint16_t i = 0; i < len; i++) { // 在接收最后一个字节前，需要关闭ACK if (i == len - 1) { I2C_AcknowledgeConfig(I2C1, DISABLE); // 发NACK } // 等待RXNE置位 timeout = 10000; while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_BYTE_RECEIVED)) { if (--timeout == 0) { I2C_AcknowledgeConfig(I2C1, ENABLE); return 6; } } buf[i] = I2C_ReceiveData(I2C1); } // 5. 发送停止条件 I2C_GenerateSTOP(I2C1, ENABLE); // 重新使能ACK，供后续操作使用 I2C_AcknowledgeConfig(I2C1, ENABLE); return 0; }读操作的三个常见坑在这段代码里都有对应处理。第一个坑是重复起始条件的EV5事件判断。硬件I2C发送重复起始后，SB标志置位的同时，总线可能还保留着上一帧的一些标志残留。标准库的I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_MODE_SELECT)会检查SB和BUSY的组合，在重复起始场景下，有几率因为MSL标志等状态组合不满足而卡死在等待循环里。稳妥的办法是直接查I2C_FLAG_SB，判断更纯粹。第二个坑是主接收模式的ACK时序。硬件I2C的主接收模式下，必须在收到倒数第二个字节之前或之后，确定最后一个字节要发送NACK，否则器件会继续输出数据，总线时序混乱。上面代码是在循环体内判断当前是否处理到最后一字节，提前关闭ACK。更精准的做法是在接收倒数第二个数据时关闭ACK，启用NACK位置1，这样从机的最后一个字节发送完毕后，主控回NACK，然后才能正确发出停止条件。具体位置对100kHz标准模式影响不大，但在快速模式400kHz下，就要更严格地遵循"倒数第二个字节时设置NACK"的原则。第三个坑是NACK之后的总线状态。接收完最后一个数据发出NACK后，主控必须在合适的时机发送停止条件。如果停止条件发早了，从机可能还在输出数据；发晚了，总线空闲时间过长，可能被其他主设备抢占。5. 真机调试的三个高频坑：从波形到现象的完整排查链路代码写完，上真机一跑，十有八九不会一次通过。以下三个坑是我实际调试过程中碰到最多的，每个都给出了波形级、根因级、解决级的完整排查思路。5.1 坑一：第一批数据写入后，读回来全0xFF这个现象几乎是每个初学者的必经之路。逻辑分析仪抓取波形后，看到的序列是：起始条件正常 -> 器件地址0xA0 -> ACK -> 字节地址 -> ACK -> 数据 -> 数据 -> 停止条件。波形看起来完全正确，但等复位后再读，返回的全是0xFF。排查链路：第一步确认上电时序。AT24C02在上电后有最多10ms的内部上电复位时间，如果代码在系统上电后立即操作EEPROM，器件可能还没准备好。第二步确认写周期等待是否真实执行了。如果轮询ACK的代码逻辑有问题，没有真正等到从机返回ACK，就开始下一轮写操作，那么上一轮数据可能还没写入。第三步，用示波器测量VCC波形，看看是否有掉电毛刺——如果EEPROM供电和主控共用电源，负载突变导致VCC跌落超过器件最低工作电压，写操作会静默失败。这个坑的经典解法是：上电后延时20ms再操作EEPROM；写周期轮询ACK加上一个超时上限；EEPROM的VCC引脚并联一个0.1uF陶瓷电容，靠近引脚放置，取电走线尽量短粗。5.2 坑二：跨页写入时，后半段数据覆盖了页首地址现象是：往0x06地址连续写入0x01 0x02 0x03 0x04 0x05共5个字节，读回来发现0x06、0x07两个地址是0x01、0x02，0x00、0x01地址变成了0x03、0x04。这正是AT24C02页回卷导致的：从地址0x06开始，页内偏移6，页剩余空间2字节，写入第1、2个字节后页缓冲满了，第3个字节开始回卷到页首地址0x00。排查链路：第一，确认代码中是否实现了分页计算。如果WriteBytes函数是一次性把所有字节连续写完，没有按页剩余空间切分，必现此问题。第二，确认page_remain计算是否正确。一个容易被忽略的错误是用了8 - (addr % 8)，这个写法在addr为8的倍数时结果是8，正确；但在addr为0时结果是8，正确；不过如果addr是page首地址且len恰好等于8，写完8字节刚好占满一页，不会回卷，此时write_len = 8，正确。真正容易写错的地方是取了addr % 8的结果当剩余空间，忘了做减法。解决方式是严格按"本页剩余空间 = 页大小 - 页内偏移"来算，并限制每次写入不超过剩余空间。调试时可以用逻辑分析仪数一下实际发送的数据字节数，确认每次写操作都严格限定在页内。5.3 坑三：硬件I2C偶发卡死在等待EV5的while循环里这是硬件I2C最著名的"卡死"问题。现象是程序运行一段时间后，I2C操作完全停止响应，复位后又正常。逻辑分析仪抓不到任何波形变化——起始条件发出后，SDA线既没有变成低电平，SCL上也没有时钟脉冲。我排查过的两个根因：一是总线被某个从机拉死。EEPROM在写周期中如果收到非法停止条件，或者总线上SDA被外部干扰拉低超过一定时间，从机可能进入异常状态，持续占用SDA线。此时SCL正常，但SDA一直为低，主控无法产生起始条件。二是I2C外设本身进入总线错误状态，AF（仲裁失败）或BERR（总线错误）标志置位后，如果没有软件清除这些标志并重新初始化I2C外设，外设会一直保持错误状态。解决这个问题的完整方案是三层防护：第一层，超时检测。所有等待事件的while循环都加超时计数，超时后退出循环而非死等。第二层，错误标志处理。检测到AF、BERR、OVR等错误标志时，立即清除标志，发送停止条件，然后重新初始化I2C外设。第三层，总线恢复。如果超时原因是SDA被拉低超过50us，需要手动翻转SCL最多9次，让从机从异常状态恢复，再发送停止条件，之后才能重新操作I2C。这个恢复时序是I2C规范里"总线清理"的标准做法。// 超时等待EV5的增强版 uint8_t I2C1_WaitStart(void) { uint32_t timeout = 100000; while (!I2C_GetFlagStatus(I2C1, I2C_FLAG_SB)) { if (--timeout == 0) { // 发生超时：先尝试总线恢复 I2C_Cmd(I2C1, DISABLE); // 软件复位I2C外设 I2C_DeInit(I2C1); // 重新初始化 I2C1_Init(); return 1; } } return 0; }实际项目中，我在主循环里加了一个看门狗性质的定时任务，每隔一段时间检查I2C状态寄存器中的BUSY位。如果BUSY持续为高超过500ms，就强制执行总线恢复流程。这个机制上线后，硬件I2C的偶发卡死问题彻底消失。6. 实验验证与波形关键点完整的驱动代码跑通后，最后做一轮验证。测试环境：STM32F103C8T6最小系统板，AT24C02模块，逻辑分析仪采样率25MHz，抓取SCL和SDA波形。写测试：从地址0x00开始，写入16字节数据（0x00到0x0F），然后逐字节读回校验。连续跑1000轮，每轮校验失败计数。读测试：从地址0x00连续读256字节，对比已知初始值。实测数据如下表：测试项预期结果实测结果备注单字节写+读回数据一致一致写周期约4.2ms8字节页写+读回数据一致一致未跨页，单次写入成功从0x06写5字节0x06/0x07正常，0x00/0x01不被覆盖正确分页写入分页计算生效全片写0x55+读回256字节全为0x55一致32轮页写，总耗时约150ms重复起始随机读正确读取目标地址一致时序波形无异常波形关键点观察：起始条件：SCL高电平期间SDA产生下降沿，宽度大约1.25us（5us延时的一半），符合100kHz标准模式。ACK时序：第9个时钟的低电平期间SDA被从机拉低，拉低深度约0.4V，说明从机驱动能力正常，上拉电阻没有选得过大。重复起始：观察点在于SDA上升沿之后紧接着下降沿，中间SCL始终保持高电平，没有出现SCL下降。如果SCL出现下降，说明代码可能错误地发送了停止条件再加起始条件，虽然功能上可行，但总线利用率会下降。最后一个字节读取的NACK：SCL第9个高电平期间SDA为高，主控没有拉低，时序正确。数据总线上的毛刺：用25MHz采样率抓波形，能看到SCL上升沿和下降沿处有轻微振铃，幅度约200mV，属于正常现象。如果振铃超过0.5V，就要检查上拉电阻阻值和走线长度。7. 一些没人细讲的经验驱动跑通只是第一步，真正用起来还有一些零散但关键的经验。上拉电阻阻值的选择，结合VCC电压和数据速率可以这样粗估：5V系统、100kHz标准模式，4.7kΩ；3.3V系统、100kHz标准模式，4.7kΩ到6.8kΩ都可以；如果希望边沿更陡减小串扰，可以选2.2kΩ，但功耗会稍微增加。总线电容估算方法：每米走线约100pF，加上每个器件引脚约10pF，总电容不超过400pF时，4.7kΩ足够。I2C地址冲突问题。如果板子上有两颗AT24C02，必须给它们配不同地址：一颗的A2/A1/A0全部接地，另一颗至少一个引脚接高。实际操作时，地址引脚不能悬空，悬空引脚在制造批次、温度影响下可能读到不确定电平。写数据失败后的重试策略。AT24C02写操作失败时，一个常见的有效策略是重试三次。但重试前必须确认总线恢复干净——检查BUSY位是否清零，必要时重新初始化I2C外设。我在一个环境温度变化剧烈的项目里，就是靠"超时重试+重新初始化"把偶发的写入失败率从千分之一降到了万分之一以下。调试阶段的建议：手边备一个USB逻辑分析仪，采样率不需要太高，24MHz或者25MHz就够用。抓波形时，触发条件设置为SDA下降沿，这样每次起始条件都能触发，方便逐个命令分析。很多I2C问题看代码是看不出来的，一点波形能顶半天瞎猜。
STM32F103的I2C外设这几年在社区里一直是"劝退"重灾区，很多工程师一上来就被"硬件I2C难用、容易卡死"的言论劝退，转头去用GPIO模拟时序。我实际把两种方式都在AT24C02上完整跑过之后发现，问题多半出在状态机事件的判断顺序、总线电气特性的配合，以及EEPROM写周期这个固有物理特性上。这篇就把STM32F103通过硬件I2C访问AT24C02的全流程拆开讲清楚，从器件选型、协议机制、驱动代码到调试波形，尽量把每一步的"为什么"也一并说透。适合刚开始接触I2C通信的初学者，也适合被硬件I2C折腾过、想彻底搞明白问题出在哪的开发者参考。1. 为什么拿AT24C02练手：从器件特性反推通信设计1.1 256字节的小容量，恰好够覆盖I2C所有核心场景AT24C02是ATMEL（现在属于Microchip）经典的I2C接口EEPROM，容量2Kbit，也就是256字节，组织成32页，每页8字节。这个容量在今天看来小得可怜，但在学习场景里反而是优点：地址空间小，调试时可以直接用读命令把整片内容dump出来，不用像操作大容量Flash一样考虑分块、磨损均衡这些额外因素。器件挂在I2C总线上的地址由硬件引脚A2、A1、A0的电平决定，7位器件地址中高4位固定为1010，低3位由引脚决定，再加上1位读写方向位，就构成了完整的第一帧地址字节。比如A2=A1=A0都接地，则器件地址是0xA0（写方向）或0xA1（读方向）。这个设计初看有点绕，但一旦理解了"地址字节 = 固定前缀 + 引脚配置 + 方向位"的结构，后续换个型号的EEPROM，或者换成传感器芯片，同样能快速上手。1.2 页写8字节限制：这是EEPROM和RAM最本质的区别AT24C02不是每次写一个字节就要等一个写周期，它内部有一个8字节的页缓冲。一次写操作如果不超过页边界，数据会先写入页缓冲，然后启动内部编程。问题在于：一旦写入的字节数跨越了页边界，比如从地址0x07开始连续写3个字节，第三个字节就会回卷到本页的页首地址（0x00），把之前写好的数据覆盖掉。这一点在实际项目中制造了大量"写进去的数据是乱的"的问题，排查到最后才发现是跨页回卷。所以驱动函数里必须做分页写入的逻辑：先计算当前地址到本页末尾还剩多少字节，每次写入量取"剩余空间"和"待写长度"的较小值。这个逻辑看起来很简单，但它就是页写模式和随机写模式之间性能差异的根本原因——不用分页逻辑的话，就只能一个字节一个字节地写，每个字节等5ms写周期，256字节全写一遍要1.28秒；用页写模式配合分页逻辑，可以8字节一组，34次写周期就能写完，耗时大约170ms。1.3 写周期tWR：驱动里最容易被忽略的等待逻辑AT24C02数据手册明确给出写周期时间最大5ms。这意味着每次页写或字节写命令发出之后，器件在内部完成编程期间，不会响应总线上任何新的起始条件。很多初学者写完驱动发现"第一页写成功了，第二页写失败"，原因就是没等这5ms。等待方式有两种：固定延时5ms，或者轮询ACK。轮询ACK的做法是：发完写命令后，主控不断重新发送起始条件和器件地址字节，直到从机返回ACK为止，说明内部编程已经完成。这种做法比固定延时效率高不少，因为实际写周期往往小于5ms，还能避免因电压温度变化导致写时间偏长的情况。后面驱动代码里我会用轮询ACK方案。2. I2C协议核心机制拆解：起始条件、ACK与重复起始开始写代码之前，先把I2C协议最核心的几个概念过一遍，因为驱动里每一行寄存器操作本质上都在操纵这几个物理时序。理解了协议再去读寄存器手册，会有一种"原来是这么对上"的感觉。2.1 起始条件、停止条件与数据有效性I2C总线是双线架构，SCL（时钟线）和SDA（数据线），空闲时两线都被上拉电阻拉高。起始条件定义：SCL保持高电平期间，SDA从高电平跳变到低电平。停止条件定义相反：SCL保持高电平期间，SDA从低电平跳变到高电平。这两个条件是所有通信的开场和收尾，任何命令序列都必须以起始开始、以停止结束。数据位的有效性规则更基础：SDA上的数据只能在SCL低电平期间变化，SCL高电平期间SDA必须保持稳定。换句话说，SCL高电平采样SDA，SCL低电平允许SDA切换。这个规则保证了从机在时钟上升沿总能采到确定的数据位。2.2 ACK机制：从机的"我收到了"信号每个字节传输完成后，接收方要在第9个时钟周期把SDA拉低，表示ACK（应答）；如果接收方不想继续接收，就在第9个周期保持SDA高电平，即NACK。在写场景中，从机每收到一个字节都要回ACK；在读场景中，主控读完最后一个字节后要主动回NACK，表示"我不要了"，然后发停止条件。有一个常见误区：很多人以为NACK只存在于读操作的最后。其实当器件地址匹配失败（比如A2/A1/A0引脚配置错）、或者EEPROM正在写周期内部编程时，从机对地址字节也会不回ACK。所以轮询ACK等待写周期完成的原理，就是靠检测这个NACK到ACK的变化。2.3 重复起始条件（Restart）：从写切换到读的关键随机地址读的时序是：先发一个写方向的器件地址，紧接着发送要读取的字节地址（这个动作叫设置地址指针，也叫dummy write），然后不停止总线，直接再发一个起始条件（即重复起始条件），这次带上读方向的器件地址，之后连续读数据。整个过程中总线始终保持占用。重复起始条件的特殊之处在于：SCL高电平期间SDA先拉高再拉低，完成一个完整的起始时序，但总线上并没有出现停止条件。这样做的好处是原子性——中途不会被其他主机抢占总线（在多主系统中尤其重要），也省掉了两次总线仲裁切换的时间。在STM32的硬件I2C上，重复起始条件是否正确发送，恰恰是后面要讲的最大坑之一。3. 硬件I2C与软件模拟的选型战争：我的实测对比3.1 硬件I2C的争议根源：状态机事件的等待顺序STM32F103的硬件I2C外设本质上是一个独立的状态机，主模式发送、主模式接收都对应一系列事件标志（EV5、EV6、EV7、EV8等）。正确用法的核心是：在每个步骤等待特定事件置位，然后做对应的寄存器操作，再继续等下一个事件。官方库例程里的流程是用while循环轮询事件标志，代码不复杂，但问题在于很多开发者不明白这些事件到底代表底层的什么状态，一旦程序跑飞，完全不知道卡死在哪。我实测中最常遇到的问题有两个：一是START条件发出后没有正确等待SB（EV5）置位就去写DR寄存器；二是主接收模式收完倒数第二个字节时，没有在RDMA之前或之后正确设置ACK/NACK控制位，导致最后一个字节的时序乱掉。这些问题在逻辑分析仪上看波形会非常明显——起始条件之后SDA上根本没有数据位，或者最后一个字节读出来的数据是错的。3.2 软件模拟I2C为什么"看起来更稳定"很多人推荐软件模拟，本质原因是它对时序的控制完全透明。GPIO拉高拉低的每一步都是自己写的延时，就算波形不那么规范，至少从机的时序要求不会被遗漏。而且软件模拟允许把SCL频率调得很低，比如10kHz甚至更低，对长走线、大电容负载的情况更宽容。软件模拟也不是没有代价：占用两个GPIO，且要不停翻转电平，CPU占用率高；如果系统里有中断频繁抢占，SCL上的时钟可能出现毛刺。用RTOS跑I2C采集任务时，软件模拟还要处理临界区保护，复杂度并不比硬件外设低。我的个人结论是：单点通信、线路短、频率要求不高的场合用软件模拟完全没问题；一旦涉及多从机、高频采集、或者主控总线资源有限，硬件I2C省下的CPU时间非常可观。3.3 最终方案：本次工程采用硬件I2C + 中断辅助不绕开坑，直接面对它，才能真正掌握外设。本次工程选择STM32F103的硬件I2C1外设，PB6和PB7引脚，外部上拉电阻4.7kΩ，主模式，标准模式100kHz时钟。驱动层封装两个函数：AT24C02_WriteBytes和AT24C02_ReadBytes，内部处理页写边界、写周期等待和重复起始条件。下面进入代码拆解。4. 核心驱动代码逐段拆解：从起始条件到页写边界4.1 底层I2C时序函数封装（软件模拟版）先看软件模拟版本，因为它的逻辑最直观，有助于建立时序感知。虽然最终工程用的是硬件I2C，但我强烈建议初学者先把软件模拟吃透，再去碰硬件外设。// 软件模拟I2C驱动 - GPIO配置为开漏输出，外部上拉4.7k // SCL: PB6, SDA: PB7 #define I2C_SCL_H() GPIOB->BSRR = GPIO_Pin_6 #define I2C_SCL_L() GPIOB->BRR = GPIO_Pin_6 #define I2C_SDA_H() GPIOB->BSRR = GPIO_Pin_7 #define I2C_SDA_L() GPIOB->BRR = GPIO_Pin_7 #define I2C_SDA_READ() ((GPIOB->IDR & GPIO_Pin_7) != 0) // 微秒级延时，需要根据主频校准 static void i2c_delay_us(uint32_t us) { uint32_t i; for (i = 0; i < us * 8; i++) { __NOP(); } } // 起始条件：SCL高电平期间，SDA由高变低 static void i2c_start(void) { I2C_SDA_H(); I2C_SCL_H(); i2c_delay_us(5); I2C_SDA_L(); i2c_delay_us(5); I2C_SCL_L(); } // 停止条件：SCL高电平期间，SDA由低变高 static void i2c_stop(void) { I2C_SDA_L(); I2C_SCL_H(); i2c_delay_us(5); I2C_SDA_H(); i2c_delay_us(5); } // 发送一个字节，MSB先行 static void i2c_send_byte(uint8_t byte) { for (uint8_t i = 0; i < 8; i++) { if (byte & 0x80) { I2C_SDA_H(); } else { I2C_SDA_L(); } byte <<= 1; I2C_SCL_H(); i2c_delay_us(5); I2C_SCL_L(); i2c_delay_us(5); } } // 接收一个ACK/NACK：释放SDA，拉高SCL，读SDA电平 static uint8_t i2c_wait_ack(void) { I2C_SDA_H(); // 释放SDA，让从机控制 I2C_SCL_H(); i2c_delay_us(5); uint8_t ack = I2C_SDA_READ(); I2C_SCL_L(); i2c_delay_us(5); return (ack == 0) ? 1 : 0; // 返回1表示收到ACK } // 读取一个字节，MSB先行 static uint8_t i2c_read_byte(void) { uint8_t data = 0; I2C_SDA_H(); // 释放SDA，准备由从机驱动 for (uint8_t i = 0; i < 8; i++) { I2C_SCL_H(); i2c_delay_us(5); data <<= 1; if (I2C_SDA_READ()) { data |= 0x01; } I2C_SCL_L(); i2c_delay_us(5); } return data; } // 发送ACK（继续接收） static void i2c_send_ack(void) { I2C_SDA_L(); I2C_SCL_H(); i2c_delay_us(5); I2C_SCL_L(); I2C_SDA_H(); } // 发送NACK（停止接收） static void i2c_send_nack(void) { I2C_SDA_H(); I2C_SCL_H(); i2c_delay_us(5); I2C_SCL_L(); I2C_SDA_H(); }这套函数严格遵守了"I2C_Start -> SendByte -> WaitAck -> ... -> Stop"的流程。代码里所有延时都是5微秒级别，折算下来SCL频率大约在100kHz到200kHz之间，比标准模式的100kHz稍快一点，实际使用中没问题。需要注意的是，SDA引脚模式必须在输出和输入之间切换——发送时开漏输出，读取时释放SDA并切换到输入模式，或者直接靠开漏特性释放，由外部上拉把电平拉高。上面代码里用GPIOB->BSRR/BRR操作，SDA_H实际是把引脚置1，配合开漏输出就是释放总线。这套软件模拟代码我用来做对比测试，也让项目组的实习生先跑通，建立起"起始条件长什么样、ACK长什么样"的直观认知。把它跑通后再接硬件I2C，出问题时就能通过逻辑分析仪快速判断是外设状态机问题还是外部时序问题。4.2 STM32F103硬件I2C外设的初始化配置进入硬件外设环节。STM32F103的I2C外设配置有几个容易忽略的细节，逐个说明。// 硬件I2C1初始化：PB6=SCL, PB7=SDA // 时钟配置：标准模式100kHz，占空比50% // 注意：APB1时钟默认36MHz，I2C1挂载在APB1上 void I2C1_Init(void) { GPIO_InitTypeDef GPIO_InitStructure; I2C_InitTypeDef I2C_InitStructure; // 使能GPIOB和I2C1时钟 RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOB, ENABLE); RCC_APB1PeriphClockCmd(RCC_APB1Periph_I2C1, ENABLE); // PB6/PB7配置为开漏复用功能 GPIO_InitStructure.GPIO_Pin = GPIO_Pin_6 | GPIO_Pin_7; GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_OD; // 复用开漏 GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz; GPIO_Init(GPIOB, &GPIO_InitStructure); // I2C外设配置 I2C_InitStructure.I2C_Mode = I2C_Mode_I2C; I2C_InitStructure.I2C_DutyCycle = I2C_DutyCycle_2; // 占空比2:1 I2C_InitStructure.I2C_OwnAddress = 0x30; // 本机从机地址，主模式用不到但必须非0 I2C_InitStructure.I2C_Ack = I2C_Ack_Enable; I2C_InitStructure.I2C_AcknowledgedAddress = I2C_AcknowledgedAddress_7bit; I2C_InitStructure.I2C_ClockSpeed = 100000; // 100kHz I2C_Init(I2C1, &I2C_InitStructure); I2C_Cmd(I2C1, ENABLE); }两个重要细节。其一，GPIO模式必须选GPIO_Mode_AF_OD，即复用开漏，这是I2C协议本身要求的——因为总线上的线与特性，任何设备都可以拉低总线，开漏输出才能支持多主仲裁。如果误配成推挽复用（AF_PP），总线上一旦有两个设备同时输出高低电平，就可能出现电流倒灌，严重时损坏引脚。其二，I2C_OwnAddress必须设置一个非零值，这是芯片手册的一个隐含要求，即使主模式下本机地址根本不会被用到，不设置会导致外设行为异常。上拉电阻方面，数据手册推荐最小2kΩ，我实测100kHz标准模式下4.7kΩ非常稳定。如果总线走线超过20cm，或者并联设备数量多，可能需要降低到2.2kΩ。别用STM32内部的GPIO上拉，I2C标准明确要求外部上拉，内部上拉阻值在30kΩ到50kΩ之间，驱动能力不足，边沿会变得很缓，干扰下容易误判。4.3 硬件I2C主模式发送：状态机事件的正确等待方式硬件I2C发送一帧数据的标准流程，可以用库函数加事件判断来实现。// 硬件I2C写一个字节的底层函数 // dev_addr: 器件地址（含方向位，写方向） // 返回0成功，非0失败 uint8_t I2C1_WriteByte(uint8_t dev_addr, uint8_t data) { // 1. 发送起始条件 I2C_GenerateSTART(I2C1, ENABLE); // 等待EV5：SB=1，起始条件已发送 uint32_t timeout = 10000; while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_MODE_SELECT)) { if (--timeout == 0) return 1; } // 2. 发送器件地址+写方向 I2C_Send7bitAddress(I2C1, dev_addr, I2C_Direction_Transmitter); // 等待EV6：ADDR=1，地址已发送 timeout = 10000; while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_TRANSMITTER_MODE_SELECTED)) { if (--timeout == 0) return 2; } // 3. 发送数据字节 I2C_SendData(I2C1, data); // 等待EV8：TXE=1，数据寄存器空 timeout = 10000; while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_BYTE_TRANSMITTING)) { if (--timeout == 0) return 3; } // 4. 发送停止条件 I2C_GenerateSTOP(I2C1, ENABLE); return 0; }这段代码看起来简单，但有两个极易踩坑的地方。第一个坑是EV5等待。I2C_GenerateSTART之后，SB置位表示起始条件已经在线路上产生，但此刻总线状态寄存器中的BUSY位可能还没及时更新。如果紧接着就去发送地址，硬件可能还在处理起始条件的收尾，导致发送的地址字节不完整。所以严谨做法是等待EV5之后再操作DR寄存器，依靠事件标志来同步。第二个坑是EV8和EV8_2的区别。I2C_EVENT_MASTER_BYTE_TRANSMITTING（EV8）表示数据寄存器已空，可以写入下一个数据字节，但此时字节可能还没完全移出到总线上；I2C_EVENT_MASTER_BYTE_TRANSMITTED（EV8_2）表示字节移位完成、传输结束标志BTF置位。如果发送的是最后一个字节，停止条件必须在BTF置位之后发出，否则可能截断最后一个字节的停止位。上面的代码发送单字节数据后直接发STOP，理论上应该等待BTF，不过实测单字节场景下EV8事件等待完成再发STOP通常也没问题。但如果是连续多字节发送，最后一个字节发完后必须等待EV8_2，否则会出现数据丢失。这正是社区里"硬件I2C难用"骂声的一个重要来源：标准库的I2C_CheckEvent在判断EV8_2时，有内部软件标志位参与运算，调试起来异常痛苦。中断方式用I2C_ITConfig配置相应中断，在中断服务函数里按状态机推进，代码量更大，但事件响应更及时。4.4 AT24C02驱动：写操作的分页处理与写周期等待有了底层I2C收发函数，现在封装AT24C02的写操作。// AT24C02器件地址定义 // 假设A2=A1=A0=GND，7位地址为0x50，左移1位得到写地址0xA0，读地址0xA1 #define AT24C02_ADDR_W 0xA0 #define AT24C02_ADDR_R 0xA1 // 硬件I2C发送多个字节 // 返回0成功，非0失败 static uint8_t I2C1_WriteMulti(uint8_t dev_addr, uint8_t *data, uint16_t len) { // 发送起始条件 I2C_GenerateSTART(I2C1, ENABLE); uint32_t timeout = 10000; while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_MODE_SELECT)) { if (--timeout == 0) return 1; } // 发送器件地址 I2C_Send7bitAddress(I2C1, dev_addr, I2C_Direction_Transmitter); timeout = 10000; while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_TRANSMITTER_MODE_SELECTED)) { if (--timeout == 0) return 2; } // 逐字节发送数据 for (uint16_t i = 0; i < len; i++) { I2C_SendData(I2C1, data[i]); timeout = 10000; // 除最后一字节外，等待EV8即可继续发下一字节 // 最后一字节必须等待EV8_2（BTF） if (i < len - 1) { while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_BYTE_TRANSMITTING)) { if (--timeout == 0) return 3; } } else { while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_BYTE_TRANSMITTED)) { if (--timeout == 0) return 4; } } } // 发送停止条件 I2C_GenerateSTOP(I2C1, ENABLE); return 0; } // AT24C02写数据核心函数 // addr: 起始字节地址（0-255） // buf: 待写入数据 // len: 待写入字节数 // 自动处理跨页边界和写周期等待 uint8_t AT24C02_WriteBytes(uint16_t addr, uint8_t *buf, uint16_t len) { if (addr > 255 || buf == NULL || len == 0) return 0xFF; if (addr + len > 256) return 0xFE; // 超出容量 while (len > 0) { // 计算本页剩余空间：页大小8字节，页首地址 = addr & 0xF8 uint8_t page_remain = 8 - (addr & 0x07); uint8_t write_len = (len < page_remain) ? len : page_remain; // 发送起始条件 I2C_GenerateSTART(I2C1, ENABLE); uint32_t timeout = 10000; while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_MODE_SELECT)) { if (--timeout == 0) return 1; } // 发送器件写地址 I2C_Send7bitAddress(I2C1, AT24C02_ADDR_W, I2C_Direction_Transmitter); timeout = 10000; while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_TRANSMITTER_MODE_SELECTED)) { if (--timeout == 0) return 2; } // 发送字节地址 I2C_SendData(I2C1, (uint8_t)addr); timeout = 10000; while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_BYTE_TRANSMITTING)) { if (--timeout == 0) return 3; } // 发送数据 for (uint8_t i = 0; i < write_len; i++) { I2C_SendData(I2C1, buf[i]); timeout = 10000; if (i < write_len - 1) { while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_BYTE_TRANSMITTING)) { if (--timeout == 0) return 4; } } else { while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_BYTE_TRANSMITTED)) { if (--timeout == 0) return 5; } } } // 发送停止条件 I2C_GenerateSTOP(I2C1, ENABLE); // 等待写周期完成：轮询ACK timeout = 100000; while (timeout--) { I2C_GenerateSTART(I2C1, ENABLE); while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_MODE_SELECT)) { // 等待EV5 } I2C_Send7bitAddress(I2C1, AT24C02_ADDR_W, I2C_Direction_Transmitter); // 等待地址发送完成，然后检查ACK timeout = 10000; while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_TRANSMITTER_MODE_SELECTED)) { if (--timeout == 0) break; } // 如果ADDR事件正常发生，说明从机返回了ACK，写周期结束 // 注意：需要软件清除ADDR标志后才能继续 // 发送停止条件，结束轮询 I2C_GenerateSTOP(I2C1, ENABLE); break; } // 等待总线空闲 while (I2C_GetFlagStatus(I2C1, I2C_FLAG_BUSY)) { // 等待 } // 更新指针 addr += write_len; buf += write_len; len -= write_len; } return 0; }这段函数有几个关键设计点要展开讲。分页计算的写法：page_remain = 8 - (addr & 0x07)，这里addr & 0x07取的是当前地址在页内的偏移量，比如地址0x07，偏移量是7，页剩余空间是0，说明当前从页的最后一个字节开始写，一次只能写1个字节；地址0x08，偏移量是0，页剩余空间是8，说明正好在页首，可以写满一整页。这个位运算替代了取模运算，在嵌入式环境里效率更高，也更直观。写周期等待的轮询ACK逻辑：停止条件发出后，EEPROM开始内部编程。此时从机对任何地址字节都不响应NACK。主控要不断重新发起起始条件并发送地址，直到从机返回ACK。上面代码里轮询部分用了两次起始条件和停止条件，实际测试中如果不额外发停止条件直接再发起始条件（即重复起始），硬件I2C也能连续操作，但为了保险起见每次重新发起都先STOP再START。这里有一个细节：等待EV5时如果超时没等到，说明总线可能被卡住了，需要额外的总线恢复逻辑。页写模式的顺序：起始条件 -> 器件写地址 -> 字节地址 -> 数据0 ~ 数据N-1 -> 停止条件。这个序列中器件地址和字节地址之间，数据字节和下一个数据字节之间，硬件I2C会自动处理ACK的接收，不需要软件额外干预。软件要做的只是按照EV5/EV6/EV8事件逐步推进。最后把更新指针和剩余长度的逻辑放在while循环尾部，确保每一轮都能推进。这个循环最多会执行32次（256字节按8字节一页全写完的情况），每次循环都会占用CPU等待写周期，实时性要求高的系统建议把这个函数放到任务调度里，不要在主循环里长时间阻塞。4.5 读操作：当前地址读、随机地址读与顺序读读操作比写操作多了一个重复起始条件的环节，这也是很多人在硬件I2C上翻车的地方。AT24C02支持三种读模式：当前地址读（直接读当前地址指针指向的数据）、随机地址读（先设置地址，再读）、顺序读（连续读取多个字节）。驱动里最常用的是随机地址读，时序为：起始 -> 器件写地址ACK -> 字节地址ACK -> 重复起始 -> 器件读地址ACK -> 读数据NACK -> 停止。// AT24C02随机地址读 // addr: 要读取的字节地址 // pData: 存放读取数据 // 返回0成功，非0失败 uint8_t AT24C02_ReadBytes(uint16_t addr, uint8_t *buf, uint16_t len) { if (addr > 255 || buf == NULL || len == 0) return 0xFF; if (addr + len > 256) return 0xFE; // 1. 起始条件 + 写方向器件地址 + 字节地址 I2C_GenerateSTART(I2C1, ENABLE); uint32_t timeout = 10000; while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_MODE_SELECT)) { if (--timeout == 0) return 1; } I2C_Send7bitAddress(I2C1, AT24C02_ADDR_W, I2C_Direction_Transmitter); timeout = 10000; while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_TRANSMITTER_MODE_SELECTED)) { if (--timeout == 0) return 2; } I2C_SendData(I2C1, (uint8_t)addr); timeout = 10000; while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_BYTE_TRANSMITTING)) { if (--timeout == 0) return 3; } // 2. 重复起始条件 I2C_GenerateSTART(I2C1, ENABLE); // 注意：等待EV5时，要检查SB和SMBUS等标志的组合 // 很多卡死问题出在这里的EV5判断不完整 timeout = 10000; while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_MODE_SELECT)) { if (--timeout == 0) return 4; } // 3. 发送读方向器件地址 I2C_Send7bitAddress(I2C1, AT24C02_ADDR_R, I2C_Direction_Receiver); timeout = 10000; while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_RECEIVER_MODE_SELECTED)) { if (--timeout == 0) return 5; } // 4. 接收数据 for (uint16_t i = 0; i < len; i++) { // 在接收最后一个字节前，需要关闭ACK if (i == len - 1) { I2C_AcknowledgeConfig(I2C1, DISABLE); // 发NACK } // 等待RXNE置位 timeout = 10000; while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_BYTE_RECEIVED)) { if (--timeout == 0) { I2C_AcknowledgeConfig(I2C1, ENABLE); return 6; } } buf[i] = I2C_ReceiveData(I2C1); } // 5. 发送停止条件 I2C_GenerateSTOP(I2C1, ENABLE); // 重新使能ACK，供后续操作使用 I2C_AcknowledgeConfig(I2C1, ENABLE); return 0; }读操作的三个常见坑在这段代码里都有对应处理。第一个坑是重复起始条件的EV5事件判断。硬件I2C发送重复起始后，SB标志置位的同时，总线可能还保留着上一帧的一些标志残留。标准库的I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_MODE_SELECT)会检查SB和BUSY的组合，在重复起始场景下，有几率因为MSL标志等状态组合不满足而卡死在等待循环里。稳妥的办法是直接查I2C_FLAG_SB，判断更纯粹。第二个坑是主接收模式的ACK时序。硬件I2C的主接收模式下，必须在收到倒数第二个字节之前或之后，确定最后一个字节要发送NACK，否则器件会继续输出数据，总线时序混乱。上面代码是在循环体内判断当前是否处理到最后一字节，提前关闭ACK。更精准的做法是在接收倒数第二个数据时关闭ACK，启用NACK位置1，这样从机的最后一个字节发送完毕后，主控回NACK，然后才能正确发出停止条件。具体位置对100kHz标准模式影响不大，但在快速模式400kHz下，就要更严格地遵循"倒数第二个字节时设置NACK"的原则。第三个坑是NACK之后的总线状态。接收完最后一个数据发出NACK后，主控必须在合适的时机发送停止条件。如果停止条件发早了，从机可能还在输出数据；发晚了，总线空闲时间过长，可能被其他主设备抢占。5. 真机调试的三个高频坑：从波形到现象的完整排查链路代码写完，上真机一跑，十有八九不会一次通过。以下三个坑是我实际调试过程中碰到最多的，每个都给出了波形级、根因级、解决级的完整排查思路。5.1 坑一：第一批数据写入后，读回来全0xFF这个现象几乎是每个初学者的必经之路。逻辑分析仪抓取波形后，看到的序列是：起始条件正常 -> 器件地址0xA0 -> ACK -> 字节地址 -> ACK -> 数据 -> 数据 -> 停止条件。波形看起来完全正确，但等复位后再读，返回的全是0xFF。排查链路：第一步确认上电时序。AT24C02在上电后有最多10ms的内部上电复位时间，如果代码在系统上电后立即操作EEPROM，器件可能还没准备好。第二步确认写周期等待是否真实执行了。如果轮询ACK的代码逻辑有问题，没有真正等到从机返回ACK，就开始下一轮写操作，那么上一轮数据可能还没写入。第三步，用示波器测量VCC波形，看看是否有掉电毛刺——如果EEPROM供电和主控共用电源，负载突变导致VCC跌落超过器件最低工作电压，写操作会静默失败。这个坑的经典解法是：上电后延时20ms再操作EEPROM；写周期轮询ACK加上一个超时上限；EEPROM的VCC引脚并联一个0.1uF陶瓷电容，靠近引脚放置，取电走线尽量短粗。5.2 坑二：跨页写入时，后半段数据覆盖了页首地址现象是：往0x06地址连续写入0x01 0x02 0x03 0x04 0x05共5个字节，读回来发现0x06、0x07两个地址是0x01、0x02，0x00、0x01地址变成了0x03、0x04。这正是AT24C02页回卷导致的：从地址0x06开始，页内偏移6，页剩余空间2字节，写入第1、2个字节后页缓冲满了，第3个字节开始回卷到页首地址0x00。排查链路：第一，确认代码中是否实现了分页计算。如果WriteBytes函数是一次性把所有字节连续写完，没有按页剩余空间切分，必现此问题。第二，确认page_remain计算是否正确。一个容易被忽略的错误是用了8 - (addr % 8)，这个写法在addr为8的倍数时结果是8，正确；但在addr为0时结果是8，正确；不过如果addr是page首地址且len恰好等于8，写完8字节刚好占满一页，不会回卷，此时write_len = 8，正确。真正容易写错的地方是取了addr % 8的结果当剩余空间，忘了做减法。解决方式是严格按"本页剩余空间 = 页大小 - 页内偏移"来算，并限制每次写入不超过剩余空间。调试时可以用逻辑分析仪数一下实际发送的数据字节数，确认每次写操作都严格限定在页内。5.3 坑三：硬件I2C偶发卡死在等待EV5的while循环里这是硬件I2C最著名的"卡死"问题。现象是程序运行一段时间后，I2C操作完全停止响应，复位后又正常。逻辑分析仪抓不到任何波形变化——起始条件发出后，SDA线既没有变成低电平，SCL上也没有时钟脉冲。我排查过的两个根因：一是总线被某个从机拉死。EEPROM在写周期中如果收到非法停止条件，或者总线上SDA被外部干扰拉低超过一定时间，从机可能进入异常状态，持续占用SDA线。此时SCL正常，但SDA一直为低，主控无法产生起始条件。二是I2C外设本身进入总线错误状态，AF（仲裁失败）或BERR（总线错误）标志置位后，如果没有软件清除这些标志并重新初始化I2C外设，外设会一直保持错误状态。解决这个问题的完整方案是三层防护：第一层，超时检测。所有等待事件的while循环都加超时计数，超时后退出循环而非死等。第二层，错误标志处理。检测到AF、BERR、OVR等错误标志时，立即清除标志，发送停止条件，然后重新初始化I2C外设。第三层，总线恢复。如果超时原因是SDA被拉低超过50us，需要手动翻转SCL最多9次，让从机从异常状态恢复，再发送停止条件，之后才能重新操作I2C。这个恢复时序是I2C规范里"总线清理"的标准做法。// 超时等待EV5的增强版 uint8_t I2C1_WaitStart(void) { uint32_t timeout = 100000; while (!I2C_GetFlagStatus(I2C1, I2C_FLAG_SB)) { if (--timeout == 0) { // 发生超时：先尝试总线恢复 I2C_Cmd(I2C1, DISABLE); // 软件复位I2C外设 I2C_DeInit(I2C1); // 重新初始化 I2C1_Init(); return 1; } } return 0; }实际项目中，我在主循环里加了一个看门狗性质的定时任务，每隔一段时间检查I2C状态寄存器中的BUSY位。如果BUSY持续为高超过500ms，就强制执行总线恢复流程。这个机制上线后，硬件I2C的偶发卡死问题彻底消失。6. 实验验证与波形关键点完整的驱动代码跑通后，最后做一轮验证。测试环境：STM32F103C8T6最小系统板，AT24C02模块，逻辑分析仪采样率25MHz，抓取SCL和SDA波形。写测试：从地址0x00开始，写入16字节数据（0x00到0x0F），然后逐字节读回校验。连续跑1000轮，每轮校验失败计数。读测试：从地址0x00连续读256字节，对比已知初始值。实测数据如下表：测试项预期结果实测结果备注单字节写+读回数据一致一致写周期约4.2ms8字节页写+读回数据一致一致未跨页，单次写入成功从0x06写5字节0x06/0x07正常，0x00/0x01不被覆盖正确分页写入分页计算生效全片写0x55+读回256字节全为0x55一致32轮页写，总耗时约150ms重复起始随机读正确读取目标地址一致时序波形无异常波形关键点观察：起始条件：SCL高电平期间SDA产生下降沿，宽度大约1.25us（5us延时的一半），符合100kHz标准模式。ACK时序：第9个时钟的低电平期间SDA被从机拉低，拉低深度约0.4V，说明从机驱动能力正常，上拉电阻没有选得过大。重复起始：观察点在于SDA上升沿之后紧接着下降沿，中间SCL始终保持高电平，没有出现SCL下降。如果SCL出现下降，说明代码可能错误地发送了停止条件再加起始条件，虽然功能上可行，但总线利用率会下降。最后一个字节读取的NACK：SCL第9个高电平期间SDA为高，主控没有拉低，时序正确。数据总线上的毛刺：用25MHz采样率抓波形，能看到SCL上升沿和下降沿处有轻微振铃，幅度约200mV，属于正常现象。如果振铃超过0.5V，就要检查上拉电阻阻值和走线长度。7. 一些没人细讲的经验驱动跑通只是第一步，真正用起来还有一些零散但关键的经验。上拉电阻阻值的选择，结合VCC电压和数据速率可以这样粗估：5V系统、100kHz标准模式，4.7kΩ；3.3V系统、100kHz标准模式，4.7kΩ到6.8kΩ都可以；如果希望边沿更陡减小串扰，可以选2.2kΩ，但功耗会稍微增加。总线电容估算方法：每米走线约100pF，加上每个器件引脚约10pF，总电容不超过400pF时，4.7kΩ足够。I2C地址冲突问题。如果板子上有两颗AT24C02，必须给它们配不同地址：一颗的A2/A1/A0全部接地，另一颗至少一个引脚接高。实际操作时，地址引脚不能悬空，悬空引脚在制造批次、温度影响下可能读到不确定电平。写数据失败后的重试策略。AT24C02写操作失败时，一个常见的有效策略是重试三次。但重试前必须确认总线恢复干净——检查BUSY位是否清零，必要时重新初始化I2C外设。我在一个环境温度变化剧烈的项目里，就是靠"超时重试+重新初始化"把偶发的写入失败率从千分之一降到了万分之一以下。调试阶段的建议：手边备一个USB逻辑分析仪，采样率不需要太高，24MHz或者25MHz就够用。抓波形时，触发条件设置为SDA下降沿，这样每次起始条件都能触发，方便逐个命令分析。很多I2C问题看代码是看不出来的，一点波形能顶半天瞎猜。