1. 项目到底做什么：一颗256字节的I2C存储芯片，凭什么值得专门写驱动
做嵌入式项目最烦的瞬间之一，就是设备一断电，攒了很久的参数全没了。你辛辛苦苦调好的PID系数、设备编号、累计计数，全部清零，每次上电都要重来。很多人第一反应是“直接用STM32内部Flash啊”，但真用起来就发现不是那么回事：Flash要按扇区擦除，最小擦除单位太大，动不动就整块擦，而且写入前必须先擦干净，擦写寿命一般也就1万次左右。调试阶段频繁读写，很快就心里发虚。这时候，AT24C02这种外挂I2C接口的EEPROM才是顺手的选择。
AT24C02名字很有迷惑性，它叫“02”，实际容量是2Kbit，也就是256字节，不是2KB。刚接触的人十个里有八个在这里看走眼，下单之前一定翻开数据手册确认容量。这芯片容量不大，但特性非常经典：256字节存储空间，页大小8字节，I2C接口标准模式跑100kHz、快速模式能到400kHz，擦写寿命标称100万次，掉电数据保存几十到一百年。说白了，它就是为“小数据、频繁改、要掉电保存”的需求量身定做的。
我做这个项目的时候，实际上要解决的是三个层面的问题。第一是硬件上怎么把AT24C02挂到STM32的I2C总线上，别上来就翻车；第二是用HAL库把这颗芯片的驱动写干净，封装出读写接口，后续业务代码调用起来不难受；第三是把调试过程中遇到的那些坑记录下来，比如地址算错、跨页写丢数据、写完立刻读读不到东西这一类问题。这篇内容就是完整的小结，适合三类人：刚学STM32和HAL库的开发者、用过I2C但没细抠过EEPROM时序的人、以及准备在新项目里挂一颗AT24C02想少踩坑的老手。
2. 硬件连线的几个关键决策
2.1 I2C引脚怎么选，为什么会翻车
STM32的I2C外设引脚在不同型号上映射不太一样。拿最常见的I2C1来说，CubeMX默认可能给到PB6和PB7，有些板子走PB8和PB9，最坑的是部分引脚下还偷偷复用了别的功能。我自己的经验是：拿到板子先翻原理图，确认SCL和SDA这两根线没有跟调试口、串口、LED灯抢。曾经有一次图省事直接用了CubeMX自动分配的引脚，结果这个引脚对应的串口已经被另一块外设初始化占用，I2C波形一塌糊涂，SCL始终跑不起来。
另外注意一个细节：I2C引脚在CubeMX里要配置成开漏输出模式（Open Drain），并且从机设备是真正的开漏结构，外部需要靠上拉电阻把电平拉高。如果配置成推挽输出（Push-Pull），SDA脚在输出低电平和外部上拉同时作用时问题不大，但引脚切换方向时很容易出现总线竞争，表现为偶尔死机、通信不稳定。所以别偷懒，在CubeMX的GPIO设置里把Mode选成I2C对应的开漏模式，让HAL库自己去管理引脚。
2.2 上拉电阻为什么不能省，选多大
I2C是开漏总线，SCL和SDA本身不会主动输出高电平，靠的是外部上拉电阻。这个电阻值不是随便拍的：阻值太大，线电容充电慢，上升沿变缓，速率上不去，100kHz可能都勉强；阻值太小，低电平时的灌电流偏大，功耗增加，还可能烧引脚。3.3V系统跑100kHz，4.7k是经典取值，跑400kHz时建议换成2.2k。如果总线上挂了不止一颗I2C设备，多颗芯片的输入电容并联，等效负载变重，上拉电阻可以适当调小一点。
如果你的开发板上恰好已经带了I2C上拉排阻，那直接用就行。面包板或者自己画板的时候，别忘了在SCL和SDA上各接一颗上拉到VCC。这个电阻一漏，AT24C02几乎必然通信失败，而且失败的方式千奇百怪，有时候是能写不能读，有时候是第一次操作正常后面全部超时。所以我强烈建议，调试任何I2C设备之前，先用万用表量一下SCL和SDA的空闲电平，正常应该是高电平接近VCC，如果量出来是0V，先别怀疑代码，去查上拉。
2.3 地址线和WP脚怎么接
AT24C02的从机地址由A2、A1、A0三个硬件引脚决定，这三个引脚的电平直接拼进设备地址里。芯片地址格式是“1010 A2 A1 A0”，A2、A1、A0都接地时，得到7位从机地址0x50，对应8位写地址0xA0，读地址0xA1。这三根脚全悬空或者全接VCC也可以，但全接地是最省心的默认接法，很多现成的模块出厂就帮你接好了。
WP是写保护引脚，高电平有效。拉高之后，芯片会忽略所有写操作，读操作不受影响。正常使用就直接接地，但我见过有人把WP接到了MCU的某个GPIO上，然后在软件里控制。这个设计本身没问题，问题是很多人初始化时忘了把WP拉低，结果写数据时返回的居然是HAL_OK，读回来却全是0xFF，非常容易让人误判。所以如果WP接到了IO口，上电初始化第一件事就是保证WP为低，并且写操作期间不要动它。
3. I2C协议与AT24C02时序的底层逻辑
3.1 I2C通信的基本流程
I2C通信本质上就是主设备发起起始条件，然后逐字节传输数据，每个字节后面跟一个应答位。AT24C02属于从设备，永远不主动占用总线，只被动响应主机发起的操作。它的操作分两大类：写入和读取，写入又分单字节写入和页写入，读取则分成当前地址读、随机读和连续读这几种。
为什么HAL库能直接把I2C底层封装好？因为I2C协议是标准的，起始条件、停止条件、应答位、数据传输，这些在硬件外设里都有对应的状态机。HAL_I2C的一系列函数其实就是在调这个状态机，咱们只需要告诉它“设备地址是多少，往哪个内存地址读写，数据放哪里，长度多少”。这不代表时序就不用学了，真出问题时，还是得拿着逻辑分析仪从头到尾数波形。
3.2 写入操作的完整过程
单字节写入的过程是这样的：主机发起始条件，发送器件写地址（0xA0），等待从机应答；然后发送要写入的芯片内部内存地址，等待应答；接着发送这一个字节的数据，等待应答；最后发停止条件。AT24C02收到停止条件后，把数据移入内部EEPROM阵列，这一步需要时间，典型值是5ms左右，在它内部写周期完成之前，芯片会“罢工”，不响应任何总线上发过来的命令。
页写入稍微复杂一点。AT24C02的页大小是8字节，主机可以在发送一个起始地址之后连续发送最多8字节的数据，芯片会把这8个字节放到内部的页缓冲区里，然后一次性写入EEPROM。但如果写入长度跨越了页边界，情况就麻烦了：比如从地址7开始写3个字节，这3个字节会落在页0和页1的不同位置，如果驱动不做处理，芯片内部会在超过当前页末尾时回绕到当前页的开头，把页首已有的数据覆盖掉。这是AT24C02驱动里最容易翻车的地方，后面写驱动时会专门处理。
3.3 读取操作的典型方法
随机读最常用，它分两个阶段：先像写操作那样发送起始条件、器件写地址、目标内存地址，发送完之后不停止，而是再发一次起始条件，然后发送器件读地址（0xA1），这时从机开始把指定内存地址的数据放到SDA线上。HAL_I2C_Mem_Read这个函数封装的就是这个“先写地址再读数据”的过程，咱们不用自己拼波形，非常省事。
连续读则是在随机读的基础上，主机读取完一个字节后不回应答（NACK），数据输出就停止；如果每读完一个字节都回ACK，芯片会自动把内存地址加1，继续输出下一个字节。理论上AT24C02允许一次读满256字节不重发地址。实际使用中，我习惯限制一次读取长度，不要让读取调用跨过256字节的容量边界，因为地址回绕到0之后，数据完全不可预期。
3.4 写周期时间与ACK轮询
AT24C02在写周期内不响应设备地址，这个特性可以拿来当“忙标志”。最保守的写法是每次写完之后固定延时5ms再去操作，简单可靠，但在循环写很多字节时会比较浪费时间。严谨一点的做法叫ACK轮询（ACK Polling）：写完一页后，反复发送器件地址探测，设备内部写周期结束时，它会重新开始响应ACK，这时就能进行下一次操作。HAL库提供了HAL_I2C_IsDeviceReady函数，正好用来做这个轮询。后面驱动里我会把两种方式都演示一下。
4. HAL库驱动代码的完整实现
4.1 CubeMX的初始化配置
我用STM32CubeMX配置工程时，只需要打开I2C1外设，I2C Speed Mode选Standard模式100kHz，其他参数默认即可。地址模式那里不用填写我们的从机地址，因为HAL库在调用函数时会通过参数传入目标地址，外设自己工作在主机模式，不需要提前绑定从机ID。
配置好之后，生成的代码已经把I2C引脚初始化和基础时钟配置都做好了。需要注意的一点是，I2C时钟频率跟系统时钟的分频配置有关，CubeMX会自动计算，但如果你手动修改了系统时钟，回到外设配置页再确认一次I2C时钟频率，别出现实际配置成100kHz但波形却跑在极低频率的情况。
4.2 驱动头文件与基础宏定义
先把头文件写清楚，代码风格简洁点，宏定义集中放，方便后续换芯片或者改地址时快速修改。
#ifndef __AT24C02_H #define __AT24C02_H #include "main.h" #define AT24C02_ADDR 0xA0U /* 8位器件地址, A2=A1=A0=0 */ #define AT24C02_PAGE_SIZE 8U #define AT24C02_MAX_ADDR 255U HAL_StatusTypeDef AT24C02_WriteByte(uint16_t addr, uint8_t data); HAL_StatusTypeDef AT24C02_ReadByte(uint16_t addr, uint8_t *data); HAL_StatusTypeDef AT24C02_WriteBuffer(uint16_t addr, uint8_t *data, uint16_t len); HAL_StatusTypeDef AT24C02_ReadBuffer(uint16_t addr, uint8_t *data, uint16_t len); void AT24C02_WaitReady(void); #endif这里地址要用0xA0而不是0x50，很多人在这里栽跟头。0x50是7位地址，0xA0是它的8位写地址版本。HAL库API里DeviceAddr参数要传8位地址格式，并且库内部会根据读写操作自动调整最低位。如果你传0x50进去，库会把发送到总线上的7位地址当成0x28，完全错位。
4.3 单字节读写接口
先实现最基础的单字节读写函数。HAL_I2C_Mem_Write和HAL_I2C_Mem_Read这两个函数天生就是为EEPROM这类带内部地址寄存器设计的，参数非常贴合需求。
HAL_StatusTypeDef AT24C02_WriteByte(uint16_t addr, uint8_t data) { return HAL_I2C_Mem_Write(&hi2c1, AT24C02_ADDR, addr, I2C_MEMADD_SIZE_8BIT, &data, 1, 100); } HAL_StatusTypeDef AT24C02_ReadByte(uint16_t addr, uint8_t *data) { return HAL_I2C_Mem_Read(&hi2c1, AT24C02_ADDR, addr, I2C_MEMADD_SIZE_8BIT, data, 1, 100); }注意I2C_MEMADD_SIZE_8BIT这个参数，它告诉HAL库内部地址寄存器是8位宽度。AT24C02容量256字节，8位地址够用。如果以后换了AT24C04往上的大容量芯片，内部地址会变成12位或更多位数，这个宏就可能要改成I2C_MEMADD_SIZE_16BIT，具体要看芯片支持哪种寻址方式。
4.4 页写入驱动与跨页处理
页写入是AT24C02驱动的核心难点。直接调用HAL_I2C_Mem_Write一次写超过8个字节，表面上看没问题，实际上如果写入范围跨过页边界，数据就会错乱。正确的做法是先把一次长度拆成多个不跨页的小段，逐段写入，每段写完等待芯片内部写周期结束，再写下一段。
HAL_StatusTypeDef AT24C02_WriteBuffer(uint16_t addr, uint8_t *data, uint16_t len) { HAL_StatusTypeDef status = HAL_OK; uint16_t offset = 0; if (data == NULL || len == 0) { return HAL_ERROR; } if (addr + len - 1 > AT24C02_MAX_ADDR) { return HAL_ERROR; } while (offset < len) { uint16_t pos = (addr + offset) % AT24C02_PAGE_SIZE; uint16_t chunk = AT24C02_PAGE_SIZE - pos; if (chunk > len - offset) { chunk = len - offset; } status = HAL_I2C_Mem_Write(&hi2c1, AT24C02_ADDR, addr + offset, I2C_MEMADD_SIZE_8BIT, data + offset, chunk, 100); if (status != HAL_OK) { return status; } AT24C02_WaitReady(); offset += chunk; } return HAL_OK; }每一段能写多少，取决于当前地址在页内的位置。比如从地址5开始写，这一页剩余空间是3字节，那就先写3字节；下一段从地址8开始，正好是下一页页首，能写满8字节。这样拆下来，每一段最多8字节，而且必然落在同一页内，你永远不用担心数据跨页覆盖。
很多网上示例不做拆分，一次把几十个字节直接传给HAL_I2C_Mem_Write，测试时恰好写的是对齐在页首的数据，所以没暴露问题。一旦写入地址变成5、13、21这种非页首的位置，问题立刻冒出来。我建议驱动里一开始就养成跨页处理的好习惯，别留隐患。
4.5 读取接口与等待函数
读取相对简单，AT24C02支持连续读取，MCU侧只要指定起始地址，就能一次性把后续数据取回来。
HAL_StatusTypeDef AT24C02_ReadBuffer(uint16_t addr, uint8_t *data, uint16_t len) { if (data == NULL || len == 0) { return HAL_ERROR; } if (addr + len - 1 > AT24C02_MAX_ADDR) { return HAL_ERROR; } return HAL_I2C_Mem_Read(&hi2c1, AT24C02_ADDR, addr, I2C_MEMADD_SIZE_8BIT, data, len, 100); }等待函数这里提供两个版本。第一种用HAL_I2C_IsDeviceReady做ACK轮询，代码很精简：
void AT24C02_WaitReady(void) { HAL_I2C_IsDeviceReady(&hi2c1, AT24C02_ADDR, 1000, 10); }第二种是固定延时，适合极端情况下总线状态不稳或者不想等待的情况：
void AT24C02_WaitReady(void) { HAL_Delay(5); }固定延时简单粗暴，但如果在低功耗或者高频写入场景下，I2C主频又不低，5ms可能覆盖不了极端情况。我更推荐ACK轮询，因为它真正的耗时是“设备实际写完所需的时间”，写完就立刻返回，时间更精准，也不会因为延时不够而出错。
4.6 主函数里的实测用例
驱动写好之后，用一段简单的测试代码验证：先全部擦除为0xFF，再往特定地址写一串有规律的数，然后读出来比对。这里记录一下我常用的测试流程。
void AT24C02_Test(void) { uint8_t wBuf[12] = {0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C}; uint8_t rBuf[12] = {0}; uint32_t i; /* 从地址3开始连续写12字节, 故意制造非对齐跨页场景 */ if (AT24C02_WriteBuffer(3, wBuf, 12) == HAL_OK) { AT24C02_WaitReady(); } /* 等待芯片内部写周期结束并读回 */ HAL_Delay(10); if (AT24C02_ReadBuffer(3, rBuf, 12) == HAL_OK) { for (i = 0; i < 12; i++) { /* 比对 wBuf[i] 与 rBuf[i], 不一致则置错误标志 */ } } }选地址3开始写，是故意让第一段数据跨页。地址3所在页剩余5字节，第一段写5字节；地址到8后进入下一页，第二段写7字节。这个测试如果通过，说明跨页处理逻辑是对的。如果拿一张未处理跨页的驱动来跑，rBuf中前5个字节正确，后面的数据就会对不上，因为写到的其实是另外一个页的头部。
5. 调试实录：踩过的坑和排查方法
5.1 读出来全是0xFF，写入没生效怎么办
读出来全是0xFF，基本可以断定写入操作没有真正生效。第一检查WP脚电平，WP为高时写操作被芯片忽略，但读操作正常，表现就是写返回正常、读全是0xFF。第二检查芯片供电电压是否稳定，AT24C02工作电压范围可以覆盖2.5V到5.5V，但如果供电不稳，内部写周期可能没完成就掉电，数据自然也存不进去。第三用逻辑分析仪抓写时序，确认发送的地址字节确实是0xA0，数据确实从SDA上出去了。
还有一个容易忽略的情况：HAL_I2C_Mem_Write每次都返回HAL_OK，但你仔细看波形，芯片在最后一个数据字节后压根没有回ACK。HAL库某些版本的驱动程序在零应答时并不总是立刻返回错误，而是等到下一次操作才暴露。所以不要只看返回值，有条件就抓波形，一抓一个准。
5.2 地址传错：0xA0、0x50、0xA1到底怎么区分
这个坑我见得太多了。I2C总线上的地址字节一共8位，其中高7位是器件地址，最低位是读写标志。AT24C02的7位器件地址是0x50，把它左移一位得到0xA0，这是写操作时的完整地址字节；读操作时是0xA1。HAL库函数要求传入的设备地址参数是8位格式但不含读写标志，也就是说你统一传0xA0，库内部用写地址时直接发0xA0，用读地址时在内部置最低位为1发出0xA1。
如果把0x50传给HAL_I2C_Mem_Read，库会先把地址左移一位变成0xA0，然后加上读标志变成0xA1，结果发到总线上的实际地址就是0xA1，但0xA1对应的7位地址是0x50，跟AT24C02的地址对不上，通信自然失败。这个错如果不看波形，光看代码很难发现。所以我在头文件里注释写得很清楚：这个0xA0是8位地址格式，不是7位地址。
5.3 连续写数据出现错乱，原因在页边界
前文提到过页边界问题，这里补充一种现象：当写入长度超过剩余页空间时，数据看起来“部分正确部分乱”。举例，从地址5开始写5个字节，前3个字节落在正确位置，后2个字节实际上被芯片写到了页首地址0、1的位置，覆盖了原本的数据。所以如果你一次性写的数据正好跨页，尤其从地址7这种位置开始写超过1字节，错误几乎是必然的。
解决办法就是我驱动里的跨页拆分，任何多字节写入都要先检查当前地址在页内的偏移，再计算本页还能写多少，严格限制单片写入长度。另外，即使你的写入起点是对齐的，写满一页之后再写下一页还是建议重新发起一次写操作，别依赖芯片自动回绕。
5.4 写入成功后立刻读，但读出来的还是旧数据
AT24C02内部写周期需要时间，典型值5ms。有些场合你可能写完一个字节马上要去读，这时候芯片还在忙，读操作要么失败要么读回旧值。解决办法是两个思路：一是固定延时至少5ms，稳妥起见我一般延时10ms；二是用ACK轮询，检测到设备重新应答后再进行后续操作。测试时如果使用调试器的在线仿真，单步执行特别容易踩这个坑，因为单步时时间走得极慢，不容易复现；全速运行时偶尔出现读回旧数据，多半就是写周期没等够。
5.5 总线锁死和HAL库卡在超时状态
I2C最气人的问题就是总线锁死：SCL/SDA其中一根在通信中途被从机拉低不放，或者由于干扰导致状态机错乱，后续所有操作都返回HAL_BUSY或者HAL_TIMEOUT。我碰到过几次，排查后发现有的是上电瞬间板子上的电容充放电导致总线毛刺，有的则是因为上拉电阻没接，总线漂移到了不确定状态。
遇到总线锁死，可以用一个复位函数把I2C外设彻底重新初始化，这是最直接的办法。代码大概这样：
void I2C_Recover(I2C_HandleTypeDef *hi2c) { __HAL_I2C_DISABLE(hi2c); HAL_I2C_DeInit(hi2c); HAL_I2C_Init(hi2c); }另外，可以把HAL_I2C_Mem_Write的最后一个参数Timeout设短一点，别设成HAL_MAX_DELAY。设太长的超时时间，一旦总线卡死，整个系统就像被按了暂停键，非常耽误排查。我一般设100毫秒，最长不超过500毫秒，出错时能快速返回错误码。
5.6 用逻辑分析仪快速定位问题
调试I2C，逻辑分析仪是神器。市面上百元以内的逻辑分析仪抓I2C波形绰绰有余，采样率10M以上就行。接线时把逻辑分析仪的通道0接SCL，通道1接SDA，共地之后开始采集，然后触发一次写和读操作，在软件里解码I2C协议，直接看到地址字节、ACK位和数据。第一个要检查的就是起始条件后发送的地址字节是不是0xA0，如果地址不对，后面全部白搭；第二个看每个字节后面的ACK位是不是低电平，如果地址正确但没有ACK，说明器件没响应，大概率是硬件连接或者上拉问题。
波形检查过关后，再用解码结果对比自己写的寄存器地址和数据。这一步能迅速把问题范围缩小到“硬件问题”还是“软件逻辑问题”，省掉无头苍蝇式的瞎改代码。
6. 扩展想法：多设备共存、存储布局和磨损均衡
6.1 多片AT24C02挂同一条总线
I2C总线理论上可以挂多片不同地址的设备，AT24C02的地址线A2、A1、A0提供了8种组合，所以一条总线上最多可以挂8片同样型号的芯片，分别把地址线接成000、001、011这样的电平组合，就能让每片芯片的地址都不冲突。实际操作时注意一下：地址线不能直接接VCC或GND拉到极限，最好通过电阻固定电平，防止焊接短接造成意外。多片芯片同时挂总线时，上拉电阻可能需要调小，因为多个从机的输入电容并联会让总线负载变重，上升沿变慢。
另外，如果你的系统里同时还有别的I2C设备，比如传感器、RTC，得检查总线上所有器件地址有没有重叠。AT24C02的地址高四位固定是1010，也就是地址范围0x50到0x57，刚好落在很多传感器和RTC芯片的地址附近，所以硬件设计阶段就要规划好地址表，避免两个器件地址相同导致通信错乱。
6.2 256字节怎么布局更合理
AT24C02容量不大，怎么分配这256字节，其实是很考验设计思路的。我的习惯是开头的几个字节当作“数据结构头”，存魔数、版本号和数据长度。魔数是固定的，比如0x5A，程序启动时先读出来，如果不是这个值，说明芯片里还没有有效数据或者数据已经被破坏，就触发一次默认参数初始化流程。版本号是为了以后升级数据结构用的，一旦数据格式变了，可以靠版本号区分新老数据。
数据区尽量按页对齐。因为AT24C02页大小是8字节，一个参数块如果跨页保存，写驱动虽然能正确处理，但频繁跨页写入会增加代码复杂程度和出错概率。把参数块按8字节对齐分配，每块独立落在页内，就可以用更简单的写函数。边角料区域可以存一些运行时统计值，比如上电次数、运行小时数，这类数据更新频率高，适合放在单独一页，避免跟关键参数放在一起被频繁擦写影响寿命。
6.3 怎么延长EEPROM的寿命
AT24C02虽然标称100万次擦写，但那是指单个字节在特定测试条件下的寿命。实际项目中，如果你总是对着同一个地址反复写，这颗芯片可能几个月就坏了。要延长寿命，常用的手段是“磨损均衡”。
简单来说，把同一个逻辑参数轮流写到一页内的不同物理地址上。比如存储区分配16个字节，每隔一段时间换一个位置写入，读的时候从最新的位置读。这样做的好处是让所有字节的擦写次数大致均衡，整颗芯片的寿命就可以放大到单字节擦写寿命的若干倍。实现上也不复杂，拿1个字节作为“槽位索引”，写之前先读索引，然后写下一个槽位，索引加1后回绕。这个方法特别适合存运行计数这类高频更新的数据。
6.4 备份与校验
严谨一点的应用，我会在EEPROM里存两份相同的数据，一份原数据，一份备份。读的时候先读原数据，用CRC校验判断是否正确；如果校验失败，读备份，备份合法就用备份并且把原数据重新写一遍；如果两份都坏了，程序就回退到出厂默认参数。这样设计之后，即使数据在写周期中途掉电被破坏了，设备上电后还能自愈。代价是多占一倍的存储空间，AT24C02本身很小，如果剩余空间不够，可以换成4Kbit或8Kbit的型号，驱动改动不大。
关于校验方式，如果数据块只有几十字节，CRC16足够了。注意CRC的初始值和解算多项式要统一，连自己都别换着用，否则升级固件后老数据全变成“校验失败”。
另外提一个小技巧：重启后读EEPROM失败，不要急着报错。有的板子上电瞬间电源还没稳定，I2C通信可能失败一次，隔几百毫秒重新初始化一次I2C再读，往往就正常了。这个在上电时序比较差的板子上特别有效，算是经验之谈。
最后再分享一个我一直在用的习惯。拿到一个新的I2C从机芯片，我不会直接开写业务逻辑，而是先搭一个最小工程，就做一件事：写一个已知数据到固定地址，延时，读回来比对。这一步通了，后面怎么改都不慌。AT24C02虽然老，但它的小容量、字节级擦写和超长寿命，在掉电存储这个领域依然是不可替代的实用方案。HAL库把底层I2C封装好之后，驱动代码的维护成本已经很低了，真正需要花心思的地方，其实全都在数据手册那些不起眼的角落：地址、页大小、写周期时间。把这几个参数吃透了，换任何一颗I2C EEPROM都只是改改头文件的事。
