在STM32嵌入式开发里I2C总线加上AT24C02这颗EEPROM的组合几乎是每个开发者都绕不过去的一课。我最早接触STM32F103时第一个感觉灯亮起来很简单但一碰I2C就蒙了——时序看不懂、总线卡死、数据读回全是0xFF各种问题折腾了好几天。这个项目就是把这套玩法彻底拆开从AT24C02这颗芯片的原理讲起到I2C协议的底层时序再到硬件I2C和软件I2C两种实现方案最后给出完整的读写代码和调试思路。无论你是刚开始学STM32、还在点灯阶段的新手还是已经会外设驱动、想彻底弄懂I2C底层机制的老手这篇实操拆解都能让你少走弯路直接抄作业。1. 项目概述与方案选型为什么用AT24C02学I2C以及硬件还是软件I2C1.1 AT24C02在项目中的定位与价值AT24C02是Microchip原Atmel出品的一颗串行EEPROM存储芯片容量2Kbit也就是256个字节。它通过I2C接口与MCU通信工作电压通常在1.8V到5.5V之间正好和STM32F103的3.3V供电兼容。在开发板上AT24C02几乎是标配外设因为它太适合入门了容量小、操作直接、读写结果能立刻看到拿它学习I2C成本低、反馈快。我选它做I2C实战项目的核心还有一个原因EEPROM这种存储类外设对时序的正确性极其敏感。你把数据写进去再读出来如果协议时序有一点偏差读回来的就是乱码或者0xFF。这种“可验证性”是寄存器配置类外设比如GPIO控制LED给不了的——寄存器写进去你可能看不出问题但EEPROM写错了立刻现形。也正因如此AT24C02成了检验I2C协议理解程度的试金石。从学习路径看AT24C02覆盖了I2C协议的所有关键知识点起始停止条件、7位从机地址、读写的方向位、应答ACK/NACK机制、连续读写的地址自增、页写入边界问题、擦写周期等待。这些知识点学透了以后再玩OLED屏SSD1306、温度传感器SHT30、RTC时钟芯片DS3231都是同一套逻辑轻轻松松就能迁移过去。1.2 硬件I2C与软件I2C的取舍一个被反复讨论的话题做这个项目时首先面临的就是用STM32F103的硬件I2C外设还是用GPIO自己模拟时序软件I2C。这个问题被讨论了很多年我两种都做过踩过坑也尝过甜头说说我的判断。硬件I2C用的是STM32芯片内部集成的I2C外设。它的优势是配备了硬件移位寄存器、时钟同步、仲裁逻辑、中断和DMA支持理论上不占用CPU多主机通信也方便。但STM32F103这一代硬件I2C的口碑并不好主要体现在状态机复杂、报错事件多、BUSY位容易卡死。尤其是I2C通信中异常中断后外设状态机经常恢复不过来需要做额外的错误恢复逻辑。我在项目里用硬件I2C时遇到过几次从机地址发送后没有应答BUSY位被置1反复尝试都无法再次发起通信最后得对I2C外设做软复位才救回来。对刚入门的人来说这很容易劝退。软件I2C就是用两个GPIO口模拟SCL和SDA的时序。它的优势非常直观代码逻辑完全由自己控制每一拍时序都清清楚楚出了问题可以直接对照时序图排查不依赖芯片原厂外设的坑代码在不同型号的MCU之间迁移几乎零成本。缺点嘛也会占一点CPU时间而且模拟时序时中断响应可能打乱时序不过在100KHz标准模式下只要把GPIO翻转速度和延时控制好完全够用。我后面给出的实操代码以软件I2C为主原因是它能帮助你彻底理解协议本身这也是“实战”这个项目的核心目标。等协议完全吃透了再去碰硬件I2C你会理解它的状态机和事件含义上手难度直接下降一个量级。2. I2C协议与AT24C02核心机制时序、地址和页写入2.1 I2C时序基础起始、停止、数据位和应答I2C总线只有两根线SCL时钟和SDA数据。所有设备挂在同一条总线上MCU作为主机控制时钟AT24C02作为从机响应地址。理解I2C协议本质上是理解SCL和SDA在不同时刻的配合关系。先说起始条件START。当SCL为高电平时SDA发生一个高到低的跳变这一拍就是起始信号宣告一次I2C通信开始。配合的代码逻辑是先把SDA置高、SCL置高延时几个微秒再把SDA拉低延时最后把SCL拉低。停止条件STOP则反过来在SCL为高电平时SDA发生一个低到高的跳变表示通信结束。数据传输的规则是在SCL为高电平的期间SDA线上的数据必须保持稳定只有SCL为低电平时SDA才能切换电平。这句话看着抽象但实际观察波形就明白了——SCL像打节拍的节拍器SDA在拍子与拍子之间换内容SCL高电平的那一拍里SDA有一个稳定的确定电平这就是一个有效的数据位。每传输一个字节8个bit从机或主机会在第9个时钟周期期间拉低SDA表示收到并做好接收下一个字节的准备这就是应答ACK如果第9个周期SDA保持高电平就是非应答NACK意味着“我不接收了”或者“没有更多数据了”。应答机制是I2C调试中最容易被忽略的环节。我在项目里大量检查ACK方法很简单发送完一个地址字节或数据字节后把SDA方向改为输入在第九个时钟脉冲把SCL拉高一次读一下SDA引脚的电平。如果读到低电平说明从机应答了继续下一步如果读到高电平说明从机没理你赶紧停止通信再排查原因。忽略ACK检查的后果是你以为数据都写进去了实际上从机可能根本没在总线上读回来自然全错。2.2 AT24C02地址解析0xA0和0xA1从哪来的AT24C02在I2C总线上有一个7位从机地址前4位是芯片固定的1010后3位由硬件引脚A2、A1、A0决定你在电路板上把这几个引脚接低电平还是高电平就确定了对外的器件地址。假设A2/A1/A0都接地最常见的情况7位地址就是1010000换算成8位写地址是0xA0最低位R/W0读地址是0xA1最低位R/W1。这里有个很容易搞混的细节I2C地址字节包含7位从机地址加1位读写方向位在代码里体现为两个不同的字节。比如你要写AT24C02第一个字节发送0xA0从AT24C02读数据第一个字节发送0xA1。很多新手以为EEPROM有两个地址其实只有一个设备地址只是发送时的读写位不同最终形成的字节不同而已。如果总线上还挂着其他I2C设备地址会有冲突的风险所以AT24C02的A2/A1/A0引脚可以灵活配置出最多8个不同地址在一条总线上挂8颗同样的EEPROM。除了器件地址AT24C02内部还有一个字节地址寄存器地址范围从0x00到0xFF对应256个存储单元。对EEPROM读写时MCU要先告诉它“我要操作第几个存储字节”这是I2C通信中第二个要发送的数据。完整的写流程是起始条件、发送0xA0、等待ACK、发送寄存器地址、等待ACK、发送要存储的数据、等待ACK、停止条件。这个流程在代码层面非常清晰。2.3 页写入机制与5ms写周期两个最容易被忽略的细节AT24C02虽然是字节寻址的存储芯片但它内部在写入时有一个“页”的概念。一页是8个字节也就是说你可以在一次I2C事务中连续写入最多8个字节只要发送完起始条件和器件地址、寄存器地址后连续发送数据即可芯片会自动管理页内地址自增。这个特性大大提高了批量数据写入的效率。但这个连写机制有个大坑页边界回卷。如果起始寄存器地址位于页的末尾附近比如你从地址0x07开始连续写两个字节第二个字节不会写到0x08而是会回卷写到同一个页的首地址0x00。这个行为是芯片设计决定的写代码时必须提前处理。最稳妥的方案是做一个分页写函数先计算剩余空间能写多少字节超过页边界就分段写每次写入不超过页边界。我在做批量数据存储时就是按这个逻辑把长数据拆成多次页写入保证数据不会错位。另一个关键参数是写周期时间典型值为5ms。AT24C02收到最后一个数据字节和停止条件后内部会进入一段约5ms的擦写时间这期间芯片不响应任何I2C命令。所以每次写操作结束后必须延时至少5ms再发起下一次读或写。我在代码里统一用6ms到10ms的延时图个稳妥。读操作则不受这个限制芯片可以随时响应读取。这里也给一个提高效率的小技巧如果需要在写完后立即验证数据先把读命令发出去等芯片完成内部擦写后自然能应答但为了代码简单我建议直接加一个固定延时几百次写操作测试下来完全够用。3. 完整读写流程设计与代码实现从初始化到数据验证3.1 工程搭建与初始化配置这个项目我用的是STM32F103C8T6最小系统板AT24C02模块通过四根线连接VCC接3.3V、GND接GND、SCL接PB6、SDA接PB7。在动手写代码之前有几个硬件层面的细节先处理好可以避免后面排查半天。上拉电阻一定要加。I2C总线是开漏输出结构SDA和SCL本身只能拉低不能主动拉高必须靠外部上拉电阻保证高电平。开发板上的AT24C02模块一般已经带了4.7kΩ或10kΩ上拉电阻但如果是自己用裸芯片搭电路务必在两个引脚上各加一颗电阻到VCC。我用逻辑分析仪实测过没加上拉的情况总线空闲时SDA和SCL电平爬不上去浮在1V多波形像心电图上的锯齿通信基本不可能成功。这个问题在硬件层面出现的频率相当高值得一开始就排查。软件工程我用的是STM32标准外设库也可以用Cubemx生成。但要注意Cubemx默认配置的是硬件I2C外设而我的方案是软件模拟所以初始化代码不需要启用I2C1外设只需要把PB6和PB7配置为开漏输出的GPIO即可。开漏输出的关键原因和上拉电阻一样I2C协议要求总线支持多设备共享开漏输出配合上拉电阻能实现线与逻辑任何设备都能把总线拉低而不会出现推挽输出时两个设备一个输出高一个输出低导致短路的情况。初始化代码很简单void I2C_GPIO_Init(void) { GPIO_InitTypeDef GPIO_InitStructure; RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOB, ENABLE); GPIO_InitStructure.GPIO_Pin GPIO_Pin_6 | GPIO_Pin_7; GPIO_InitStructure.GPIO_Mode GPIO_Mode_Out_OD; // 开漏输出 GPIO_InitStructure.GPIO_Speed GPIO_Speed_50MHz; GPIO_Init(GPIOB, GPIO_InitStructure); SDA_GPIO_Pin_HIGH(); // 初始状态拉高 SCL_GPIO_Pin_HIGH(); }GPIO配置成开漏后操作SDA引脚时还要注意方向切换的问题。软件模拟I2C的标准做法是把SDA配置成类似双向端口发送数据时控制输出高低电平读取ACK时把引脚方向改回来。标准库改方向比较麻烦我的解决办法是用一个宏切换把GPIO重新初始化为输入模式或者在某些平台上直接读输出寄存器的值也能间接读到引脚状态。STM32的GPIO在开漏模式下如果输出寄存器为1引脚实际电平由外部上拉决定所以读取IDR寄存器可以得到真实引脚状态。用这个特性可以省去频繁切换方向的步骤读ACK时配置输出高电平作为释放SDA再去读IDR即可。3.2 软件I2C核心函数实现下面给出软件模拟I2C的基础操作函数这套代码我在多个项目里复用稳定可靠。每个函数都包含了必要的延时保证时序满足100KHz标准模式的要求。使用STM32标准库的SysTick精确延时4MHz主频时一个微秒延时可以通过循环或定时器实现。#define SDA_GPIO_Pin_HIGH() GPIO_SetBits(GPIOB, GPIO_Pin_7) #define SDA_GPIO_Pin_LOW() GPIO_ResetBits(GPIOB, GPIO_Pin_7) #define SCL_GPIO_Pin_HIGH() GPIO_SetBits(GPIOB, GPIO_Pin_6) #define SCL_GPIO_Pin_LOW() GPIO_ResetBits(GPIOB, GPIO_Pin_6) #define I2C_SDA_IN() { GPIO_InitStructure.GPIO_Pin GPIO_Pin_7; \ GPIO_InitStructure.GPIO_Speed GPIO_Speed_50MHz; \ GPIO_InitStructure.GPIO_Mode GPIO_Mode_IN_FLOATING; \ GPIO_Init(GPIOB, GPIO_InitStructure); } #define I2C_SDA_OUT() { GPIO_InitStructure.GPIO_Pin GPIO_Pin_7; \ GPIO_InitStructure.GPIO_Speed GPIO_Speed_50MHz; \ GPIO_InitStructure.GPIO_Mode GPIO_Mode_Out_OD; \ GPIO_Init(GPIOB, GPIO_InitStructure); }起始条件和停止条件与时序图一一对应。起始条件的核心是“SCL为高时SDA从高变低”停止条件是“SCL为高时SDA从低变高”。初始状态SDA和SCL都是高这对应总线空闲状态。SCL和SDA的跳变时序绝对不能反了否则从机不识别。发送字节时数据从最高位开始一位一位地发先把SDA设为当前位电平再拉高SCL让从机在上升沿采样然后拉低SCL换下一位。这中间每拍延时约5微秒100KHz的标准模式买不了吃亏买不了上当。void I2C_Start(void) { SDA_GPIO_Pin_HIGH(); SCL_GPIO_Pin_HIGH(); I2C_Delay(5); SDA_GPIO_Pin_LOW(); I2C_Delay(5); SCL_GPIO_Pin_LOW(); I2C_Delay(5); } void I2C_Stop(void) { SDA_GPIO_Pin_LOW(); SCL_GPIO_Pin_HIGH(); I2C_Delay(5); SDA_GPIO_Pin_HIGH(); I2C_Delay(5); SCL_GPIO_Pin_LOW(); I2C_Delay(5); } void I2C_SendByte(uint8_t byte) { uint8_t i; for (i 0; i 8; i) { if (byte 0x80) SDA_GPIO_Pin_HIGH(); else SDA_GPIO_Pin_LOW(); byte 1; SCL_GPIO_Pin_HIGH(); I2C_Delay(5); SCL_GPIO_Pin_LOW(); I2C_Delay(5); } } uint8_t I2C_ReceiveByte(uint8_t ack) { uint8_t i, byte 0; SDA_GPIO_Pin_HIGH(); // 释放SDA总线由从机控制 I2C_SDA_IN(); for (i 0; i 8; i) { SCL_GPIO_Pin_HIGH(); I2C_Delay(3); byte (byte 1) | (GPIO_ReadInputDataBit(GPIOB, GPIO_Pin_7) ? 1 : 0); SCL_GPIO_Pin_LOW(); I2C_Delay(3); } // 发送应答或非应答 I2C_SDA_OUT(); if (ack) SDA_GPIO_Pin_LOW(); else SDA_GPIO_Pin_HIGH(); SCL_GPIO_Pin_HIGH(); I2C_Delay(3); SCL_GPIO_Pin_LOW(); SDA_GPIO_Pin_HIGH(); return byte; }// 等待从机ACK返回0表示成功 uint8_t I2C_WaitACK(void) { uint8_t ack 1; SDA_GPIO_Pin_HIGH(); I2C_SDA_IN(); SCL_GPIO_Pin_HIGH(); I2C_Delay(5); if (GPIO_ReadInputDataBit(GPIOB, GPIO_Pin_7) 0) // SDA被从机拉低 ack 0; SCL_GPIO_Pin_LOW(); I2C_SDA_OUT(); return ack; }这套代码的逻辑非常直白你不需要背寄存器对照时序图就能看明白每一行在干什么。发送一个字节时从最高位逐位发送I2C协议就是从左到右、高位先出。接收一个字节时先把SDA切换成输入模式然后每个时钟脉冲读取一位8个脉冲下来正好一个字节。阿克检查放在地址字节和数据字节之后这个习惯我强烈建议从一开始就保留绝不要因为暂时没出问题就跳过。3.3 完整写操作实现与执行流程现在说AT24C02的写操作。最典型的是单字节写向某个存储地址写入一个字节。调用关系很清楚启动、发送器件写地址0xA0并等待ACK、发送内部字节地址并等待ACK、发送数据并等待ACK、停止、延时等待内部擦写完成。把这几个步骤写成函数就是标准的I2C写一字节目录。// 向AT24C02指定地址写入一个字节 void AT24C02_WriteByte(uint8_t addr, uint8_t data) { I2C_Start(); I2C_SendByte(0xA0); // 器件写地址 I2C_WaitACK(); I2C_SendByte(addr); // 内部字节地址 I2C_WaitACK(); I2C_SendByte(data); // 数据 I2C_WaitACK(); I2C_Stop(); delay_ms(6); // 等待内部写周期完成 }这里每个WaitACK都要检查返回值如果返回1没有ACK说明总线状态异常或AT24C02不在总线上。项目调试时我习惯在这里加一个调试断点或串口打印读取ACK的状态便于第一时间定位问题。写到EEPROM内部时5ms写周期内MCU必须等待千万别在这期间发起新的I2C通信否则总线会得不到响应。如果你有大量数据要连续写入建议每写一个字节后延时6ms这样虽然速度慢一点但是稳定可靠。对于多字节写入需要实现分页逻辑。AT24C02的页是8字节从当前字节地址到页末尾可写入的字节数是有限的。假设起始地址是0x02要写10个字节第一段可以写0x02到0x07共6字节第二段从0x08开始写剩余4个字节。所有操作都必须拆成不超过页边界的子事务。这个函数写起来也不复杂核心是计算len和page_remain的关系。我在项目里批量保存参数时就把数据组织成固定结构按页对齐到0x00开始写省去很多边界计算的麻烦。void AT24C02_WritePage(uint8_t addr, uint8_t *buf, uint8_t len) { uint8_t first_len 8 - (addr % 8); // 当前页剩余空间 uint8_t i; if (len first_len) { I2C_Start(); I2C_SendByte(0xA0); I2C_WaitACK(); I2C_SendByte(addr); I2C_WaitACK(); for (i 0; i len; i) { I2C_SendByte(buf[i]); I2C_WaitACK(); } I2C_Stop(); delay_ms(6); } else { // 先写当前页剩余部分 AT24C02_WritePage(addr, buf, first_len); // 再写下一页 AT24C02_WritePage(addr first_len, buf first_len, len - first_len); } }3.4 完整读操作实现与执行流程读操作比写稍微绕一点因为需要先告诉芯片“我要读哪个地址”再发起一次读事务拿数据。标准流程是先发一个写事务只发送器件写地址和内部字节地址目的是把地址指针设置好然后可以发停止条件再重新起始也可以直接发重起始条件Restart再发送器件读地址0xA1之后逐字节读取。两种方式协议上都允许我用停止后重新起始的方式代码结构更直白。// 从AT24C02指定地址读取一个字节 uint8_t AT24C02_ReadByte(uint8_t addr) { uint8_t data; I2C_Start(); I2C_SendByte(0xA0); // 先写地址设置内部指针 I2C_WaitACK(); I2C_SendByte(addr); I2C_WaitACK(); I2C_Start(); // 重新起始 I2C_SendByte(0xA1); // 切换为读模式 I2C_WaitACK(); data I2C_ReceiveByte(0); // 最后一个字节发NACK I2C_Stop(); return data; }读多个字节时前N个字节发送ACK表示“继续读下一个”最后一个字节发送NACK表示“够了别再发了”。这个细节在I2C协议里非常关键如果最后没发NACK而是发了ACK从机会以为你还要继续接收数据总线会进入僵持状态。我做批量读取时一般是连续读8字节前7个传ack1最后一个传ack0然后停止。void AT24C02_ReadBytes(uint8_t addr, uint8_t *buf, uint8_t len) { uint8_t i; I2C_Start(); I2C_SendByte(0xA0); I2C_WaitACK(); I2C_SendByte(addr); I2C_WaitACK(); I2C_Start(); I2C_SendByte(0xA1); I2C_WaitACK(); for (i 0; i len - 1; i) buf[i] I2C_ReceiveByte(1); // 前n-1个ACK buf[len - 1] I2C_ReceiveByte(0); // 最后一个NACK I2C_Stop(); }主函数里做一次完整的写读验证定义两个数组一个写入数据一个读取数据写完后延时再读回来用memcmp对比两边一致就串口输出ok不一致则输出错误码。这种验证方法比只看单字节读写要可靠得多能同时验证页写入、地址自增、跨页处理和读流程的正确性。3.5 代码层面的优化与注意事项代码写完不是终点我还做了几处优化提前避免隐患。第一个优化是ACK检查的失败处理。前面写的函数里WaitACK返回值没有被判断生产代码里我会补上失败重试或状态返回这样什么问题都能靠返回值定位。第二个优化是加入超时机制防止I2C通信卡死导致MCU进入死循环。比如WaitACK里加一个计数器超过N个循环就返回失败主流程再进入恢复流程。第三个优化是延时函数的精度我建议直接用SysTick做微秒级定时别再靠空循环延时——编译器的优化等级一变空循环的延时时间就完全不同了。还有一个容易踩的坑是中断干扰。如果项目里开了定时器中断、串口中断而这些中断的响应时间超过微秒级软件模拟I2C的时序很可能被破坏。我的做法是在I2C通信的完整事务期间临时屏蔽优先级低的中断或者把延时调大一些留出余量。实践证明标准模式100KHz下稍微宽松一点的时序不会影响通信但中断打断波形就难说了。4. 调试历程与常见问题排查实录4.1 问题速查表现象、原因、解决办法把我在实际调试这个项目中遇到的问题整理成一个表这个表浓缩了我最常遇到的坑包括现象和对应的排查方向。调试I2C的时候对照这张表逐个排除能节省大量时间。现象可能原因排查与解决SDA/SCL波形一直为低上拉电阻缺失或引脚配置错误检查硬件上拉改用开漏输出发送地址后无ACK器件地址错误或AT24C02未供电核对A2/A1/A0引脚确认0xA0/0xA1读回数据全为0xFF写入未成功或写周期不够延长写后延时到10ms检查WP引脚写入数据读回错位跨页边界写入使用分页写函数按8字节页对齐写数据后芯片仍不响应写周期内发起了新命令每次写后延时6ms以上再操作I2C通信偶发失败中断干扰时序通信期间屏蔽中断或放宽延时硬件I2C的BUSY位卡死外设状态机异常软件复位I2C外设或改用软件I2C4.2 硬件I2C版本的痛苦回忆与救急方案我不否认硬件I2C在很多复杂场景下有其价值但在STM32F103上做AT24C02这类简单从机通信硬件I2C成了很多人的梦魇。最典型的问题是总线忙检测BUSY位被置位后无法清除。I2C通信过程中只要出现一个意外的停止条件或者线路干扰外设就认为自己还在通信中BUSY位锁死后续所有起始条件都无法发出主函数卡死在事件循环里。如果坚持用硬件I2C救急方案有几种一是把I2C外设彻底禁用再重新使能包括复位寄存器二是在初始化前把SDA和SCL引脚做几次手动翻转模拟出有效的停止条件骗过外设状态机三是干脆加一个超时计数检测到BUSY位异常就软件复位。我实测下来这种救急逻辑确实能用但代码复杂度和维护成本明显上涨。相比之下软件模拟I2C版本至少能保证我对每一拍时序都有绝对控制权出现问题可以直接通过逻辑分析仪对照协议图排查。如果你被硬件I2C的这个问题折磨过建议先切到软件I2C方案让项目先跑通再回来看硬件外设那些“看不见摸不着”的状态位你会产生一种豁然开朗的感觉。4.3 逻辑分析仪观测波形调试I2C的一大利器调试I2C我强烈建议配一个逻辑分析仪不需要多高端几十块钱的8通道就能用采样率选24MHz以上。把探头夹在SCL和SDA上通信时抓取波形解码器选择I2C它能自动解析出起始条件、地址、数据、ACK状态看一眼就知道整个事务是否符合预期。我在调试时发现很多人不会看波形一堆曲线在屏幕上横七竖八的其实只要抓住几个关键节点就行。首先是查找SCL高电平时SDA的下跳沿那就是起始条件后面的波形就是一次完整的事务。接着看起始条件后的第一个字节前7位是器件地址第8位是读写方向第9位是ACK。比如一次写操作第一个字节应该解出0xA0且带ACK读操作在Restart后的第一个字节应该是0xA1。再看中间的数据字节对照你代码里发的寄存器地址和数据值。如果波形显示设备无ACK十有八九是地址没对上或者芯片没上电。如果SCL有脉冲但SDA一直为高说明总线上只有主机在自说自话从机根本没参与。波形分析比纯看代码调试的效率高一个数量级。我自己的习惯是代码写完先跑一轮正常通信就抓一段波形存成截图出了问题再抓一段对比两段波形差距一眼就看出来。这种排查方式也特别适合初学者建立时序感看多了波形I2C的“节奏”就刻在脑子里了。4.4 写保护引脚与上电时序的额外提醒AT24C02的WPWrite Protect引脚是另一个容易被忽视的硬件细节。WP接高电平时整个芯片被写保护任何写命令都会被忽略但读操作不受影响。很多开发板把这个引脚通过跳线帽接到了3.3V如果你写入数据后读回全是对的旧数据或0xFF检查一下WP引脚的电平把它接地即可。这个坑特别隐蔽因为IC对写操作“不响应”和“响应但擦写失败”的外在表现不一样前者读回旧值后者读回全FF。上电时序也值得提一句。STM32和AT24C02最好能同步上电如果EEPROM先上电、MCU后上电GPIO在MCU初始化之前处于浮动状态SDA和SCL的干扰电平有可能被AT24C02误判为起始或停止条件导致芯片内部状态混乱。解决方法是在MCU初始化函数一进来就先把SDA和SCL配置成开漏输出并输出高电平抢占总线空闲状态再初始化I2C功能。如果你的硬件设计允许也可以在EEPROM的供电脚上加一个小电容让它的上电稍微滞后几毫秒这样总线上不会出现乱糟糟的中间状态。5. 再强化一遍的实操经验与扩展方向5.1 我从这个项目里拿走的三个习惯第一个习惯是ACK必查。不管写命令还是读命令只要是从机必须回答的字节我全都会检查ACK。这不仅是协议要求更是一条免费的通信体检通道主机和从机之间每次对话都有回应你才知道链路是通的。第二个习惯是写周期必等。AT24C02的5ms写周期是芯片的物理特性不可违背每次写操作后都留足时间宁可多等不可少等。第三个习惯是逻辑分析仪到位再调试。软件模拟I2C只要时序有一点不对波形就完全变样光靠肉眼读代码很难发现问题用分析仪看波形直接对照协议图基本一抓一个准。这三个习惯让我后续调试其他I2C设备时节省了无数时间。比如调OLED屏SSD1306时它的初始化命令序列很长但我已经习惯了在每条命令之间检查ACK、控制好命令间的延时一次就把屏幕点亮了。再比如调传感器时读回来的数据不对我第一反应是抓波形看ACK和寄存器地址而不是在代码里盲目改延时。所以这个项目练的不只是AT24C02读写而是把整套I2C调试方法论内化成自己的肌肉记忆。5.2 往更深的方向从AT24C02到I2C总线上的所有从机AT24C02跑通之后可以沿着I2C这个方向继续深入。你可以试试硬件I2C版本把外设寄存器的事件、错误中断都吃透彻底搞明白那一堆状态位的含义也可以挂一颗OLED屏或陀螺仪传感器让你的I2C总线同时挂多个从机体验地址分配和总线仲裁还可以试试把I2C速度从100KHz提到400KHz的快速模式看看软件模拟的时序余量撑不撑得住在Linux层面借助i2c-tools等工具对系统底层的I2C设备进行操作也能从主机侧对协议有更全面的认识。EEPROM的外部应用还有很多比如把配置参数存在EEPROM里实现断电保存、做多设备组网通信都是很有意思的项目延伸。项目做到这一步我从AT24C02身上学到的早已超过“一个存储芯片怎么用”本身。它逼着我把时序图吃透、把ACK机制理解透彻、把硬件和软件分层看清。这些东西在以后写任何I2C设备驱动时都会反复用上。如果你正在为I2C读写发愁就拿起手边的开发板装上这颗两毛钱的EEPROM一步一步跟着这篇文章操作最后看到串口打出的Readback OK那种感觉值得体验。