简介：AT24C64驱动文件是一份面向嵌入式开发者的EEPROM驱动代码包，解决微控制器通过I²C总线读写AT24C64的常见需求，适用于STM32、51等单片机项目的配置存储与设备信息读取场景。资源共3个文件，压缩包仅1KB，其中C源码文件提供I²C初始化、按地址读写、错误处理及CRC校验等完整功能，H头文件包含函数原型、地址宏定义与配置结构体，整体模块化设计便于直接移植；附带的txt文档可用于记录使用说明或开发备注。对于需要快速集成AT24C64的中初级开发者，这套轻量驱动能省去从零调试I²C时序的麻烦，直接调用接口即可完成设备序列号读取、用户设置保存等任务；同时读者可借源码梳理EEPROM驱动的基本框架，理解通信协议与硬件接口的结合方式。目前已有448人学习下载，适合在嵌入式固件开发中作为可靠参考。同时，由于包体极小、依赖简单，也可作为教学示例快速部署到现有工程。 做嵌入式这几年，存参数、存日志、存校准数据，基本都绕不开EEPROM这个小玩意儿。要说最常用的型号，AT24C64绝对排得上号——8KB容量，I2C接口，两条线搞定，价格还便宜。前阵子一个仪表项目要存校准参数和运行日志，选型就定在它身上。驱动文件这东西，说简单也简单，无非就是读和写，但真要把读写做稳、做可靠，尤其是页写和跨页边界处理，坑还不少。这篇就基于我自己的驱动文件，把AT24C64的驱动细节、实操要点和踩过的坑一次性讲清楚。
先说清楚这篇适合谁看。如果你正在调AT24C64，或者准备在项目里用，甚至只是想把I2C EEPROM这套读写逻辑搞明白，那这篇内容就是给你准备的。我会从芯片基础特性讲起，把驱动分层、读写时序、页写边界处理、常见故障排查都过一遍，代码直接可抄，参数给全，保证落到实处在。
1. 为什么需要一份靠谱的AT24C64驱动文件
1.1 AT24C64是什么，它解决了什么问题
AT24C64是Atmel（现在归Microchip）推出的I2C接口EEPROM芯片，容量64Kbit，换算过来就是8KB。8KB看似不大，但存设备编号、MAC地址、校准系数、开机次数、故障日志这类小数据，绰绰有余。它最大的特点是断电不丢数据，写入后可保持100年，擦写寿命标称100万次，这些指标在实际产品里完全够用。
你可能会问，为什么不用Flash或者直接用MCU内置的Flash模拟EEPROM？MCU内置Flash擦写寿命一般也就1万次到10万次，如果做OTA升级，Flash还要存固件，跟参数混在一起有风险。外挂一颗AT24C64，参数区和代码区物理隔离，意外情况最多丢参数，不至于把固件搞坏。而且I2C接口只占两个IO，比SPI Flash还省引脚。
还有个很实际的优势：AT24C64和24C02、24C16这些同系列芯片引脚兼容，软件上只需要改一下设备地址和容量参数。我手头就常备几种封装，小项目用24C02，数据量上来就换24C64，PCB不用重新画，驱动做个小配置就能通吃，这个思路建议你也保留。
1.2 驱动文件在驱动什么：从芯片手册看关键时序
写驱动前，我习惯把芯片手册的时序图先吃透。AT24C64的几个关键参数直接影响代码正确性：
- I2C从机地址：AT24C64的固定地址部分是1010，A2、A1、A0三个引脚决定低三位。如果三个引脚都接地，写地址就是0xA0，读地址是0xA1。如果接了上拉或下拉组合，地址会相应变化，这点在设计硬件时要定下来。
- 页写大小：AT24C64的页大小是32字节。这是写驱动最容易踩坑的地方——一次写操作最多只能写32字节，超过就会回卷到当前页开头，把前面写的数据覆盖掉。
- 写周期时间：每次写完字节或页，芯片内部需要tWR时间完成真正的Flash编程，典型值5ms，最大10ms。这段期间芯片不响应任何命令，驱动必须在每次写操作后等待，否则数据会丢。
这里有个概念新手容易搞混，就是“页写”和“连续写”的区别。页写指在一次写周期内连续写入最多32字节到同一页；连续写则是一次I2C事务里逐个字节写，每个字节都要等一个tWR周期，效率低得多。页写的价值在于一次启动写周期就能写32字节，速度快，代码也干净。
2. 驱动文件的整体架构：分层设计与思路
2.1 从底层到应用，驱动代码怎么分层才不混乱
我写EEPROM驱动习惯分三层：总线层、设备层、应用层。三层各管各的事，互不越界，移植的时候也能最大化复用。
总线层只做I2C的收发，对上层屏蔽是软件模拟I2C还是硬件I2C。你在STM32上可能是HAL库的HAL_I2C_Mem_Write，在51上可能是GPIO模拟时序，这层把差异吃掉就行。
设备层就是AT24C64的专用驱动，调用总线层接口，实现读字节、写字节、页写、任意地址读这些基础函数。这层要处理的是芯片自身的逻辑，比如设备地址、页边界、写周期等待。
应用层则是你业务里的实际场景，比如“保存校准参数”“读取开机次数”。应用层不需要关心EEPROM是怎么写的，只调用设备层提供的接口，传入缓冲区、长度、目标地址就行。
2.2 使用硬件I2C还是软件模拟I2C，实际项目怎么选
驱动文件很大程度受I2C实现方式影响，我两种方式都写过，说说我的选择标准。
如果MCU自带硬件I2C，优先用硬件。原因是代码简洁、不占CPU、时序由硬件保证。但硬件I2C也有麻烦的时候，比如某些MCU的I2C外设在异常总线状态（SDA一直为低）时不好恢复，必须复用IO配置成GPIO来翻转时钟复位。所以即便用硬件I2C，我也会在驱动里加一个“总线恢复”函数，关键时候真的能救命。
软件模拟I2C的优势是引脚任意、调试直观、不挑MCU，缺点是占用CPU并且时序必须严格按手册来。如果主频不高或者系统里中断比较多，软件I2C容易被中断打断导致时序出错。我的建议是：项目对引脚有强约束或者MCU硬件I2C不太好用，就用软件模拟；否则硬件I2C更省心。下面驱动文件按总线层已封装好的前提来写，不管底层是硬件还是软件，上层逻辑完全一致。
3. 核心驱动文件实现与关键代码解析
3.1 驱动头文件：地址定义与超时机制
先把头文件放出来，这几个宏是整个驱动的基石：
#ifndef AT24C64_H #define AT24C64_H #include <stdint.h> #define AT24C64_DEV_ADDR 0xA0 // 器件地址，A2=A1=A0=0 #define AT24C64_PAGE_SIZE 32 // 页大小 32 字节 #define AT24C64_MAX_ADDR 0x1FFF // 8KB 容量 0~8191 // 总线层需要提供的底层接口 int i2c_write_bytes(uint8_t dev_addr, uint16_t reg_addr, uint8_t *buf, uint16_t len); int i2c_read_bytes(uint8_t dev_addr, uint16_t reg_addr, uint8_t *buf, uint16_t len); // 设备层API int at24c64_write(uint16_t addr, const uint8_t *buf, uint16_t len); int at24c64_read(uint16_t addr, uint8_t *buf, uint16_t len); #endif设备地址这里要注意：0xA0是8位写地址，如果你用的MCU的I2C库要求传7位地址，需要右移一位传0x50。很多新手把0xA0直接丢给HAL库导致通信失败，其实不是芯片问题，是地址位宽没搞清楚。
3.2 写函数：单字节、页写与跨页处理
写EEPROM的核心逻辑是页写。先看单字节写，这是最基础的：
int at24c64_write_byte(uint16_t addr, uint8_t data) { if (addr > AT24C64_MAX_ADDR) { return -1; } if (i2c_write_bytes(AT24C64_DEV_ADDR, addr, &data, 1) != 0) { return -1; } delay_ms(5); // 写周期等待，典型5ms return 0; }单字节写看似简单，但有一个隐患：EEPROM内部写周期是“一刀切”的，每次写命令发送完后，芯片都固定要花大约5ms去写Flash。如果系统里频繁调用单字节写，这个延时叠加起来会拖慢速度。所以真正高效的写法是利用页写，一次写完32字节。
页写函数就要小心了，先判断剩余页空间是否够用，不够就拆分：
int at24c64_write_page(uint16_t addr, const uint8_t *buf, uint16_t len) { uint16_t page_remain; uint16_t chunk; if (addr > AT24C64_MAX_ADDR || len == 0) { return -1; } // 当前地址到页尾还剩多少字节 page_remain = AT24C64_PAGE_SIZE - (addr % AT24C64_PAGE_SIZE); chunk = (len < page_remain) ? len : page_remain; if (i2c_write_bytes(AT24C64_DEV_ADDR, addr, (uint8_t *)buf, chunk) != 0) { return -1; } delay_ms(5); return chunk; }注意这个函数返回的是本次实际写入的字节数，调用者要靠它判断是否写完。如果len超过页剩余空间，就得分多次写。
通用写函数就是把“跨页”逻辑做完整：
int at24c64_write(uint16_t addr, const uint8_t *buf, uint16_t len) { uint16_t written = 0; int ret; while (written < len) { ret = at24c64_write_page(addr, buf + written, len - written); if (ret <= 0) { return -1; } addr += ret; written += ret; } return 0; }这里整个驱动最关键的判断就是AT24C64_PAGE_SIZE - (addr % AT24C64_PAGE_SIZE)。这一行解决的是“从地址100开始写20字节，会不会越过页边界”的问题。如果地址100属于页96~127，剩余页空间是112，假设还要写入30字节，那第一次就能写入30字节；如果地址100属于页96~127，要写入40字节，那只能先写28字节到页尾，再写12字节到下一页。
3.3 读函数：任意地址读与顺序读
读操作比写简单很多，因为不涉及页限制和写周期。随机读和顺序读在EEPROM内部天然支持，地址自动递增：
int at24c64_read(uint16_t addr, uint8_t *buf, uint16_t len) { if (addr > AT24C64_MAX_ADDR || len == 0) { return -1; } return i2c_read_bytes(AT24C64_DEV_ADDR, addr, buf, len); }读的核心隐藏在总线层，我简单说下一帧完整的随机读时序，了解这个对排查问题很有帮助：
- 主机发送START + 设备写地址（0xA0），等待ACK。
- 主机发送2个字节的存储地址，先高字节后低字节，等待ACK。
- 主机重新发送START + 设备读地址（0xA1），等待ACK。
- 主机连续读取len个字节，每字节后发送ACK，读完最后一个字节发NACK。
- 主机发送STOP，结束事务。
总线层的i2c_read_bytes内部就是按这个流程实现的。这里有一个细节：读操作在发送存储地址和发送读地址之间，很多实现会多一次STOP，变成“先写地址、STOP、再启动读”。这在大多数芯片上没问题，但严谨的I2C时序是采用“重复起始位”的方式，在主机发送完地址后、重新发送读地址前发一个Restart而不是Stop，可以避免总线所有权丢失。AT24C64对Restart支持得很好，驱动最好按这个标准写。
3.4 应用层封装：参数存储的完整示例
设备层搞定后，应用层就非常舒服了。比如把一组设备参数存到EEPROM：
typedef struct { uint16_t magic; // 标记 0xAA55 表示参数有效 uint8_t version; // 参数版本 int32_t offset_value;// 校准偏移 uint16_t threshold; // 阈值 } DeviceParam; #define PARAM_ADDR 0x0000 int param_save(DeviceParam *param) { param->magic = 0xAA55; return at24c64_write(PARAM_ADDR, (uint8_t *)param, sizeof(DeviceParam)); } int param_load(DeviceParam *param) { if (at24c64_read(PARAM_ADDR, (uint8_t *)param, sizeof(DeviceParam)) != 0) { return -1; } if (param->magic != 0xAA55) { return -1; // 数据无效，恢复默认 } return 0; }注意写结构体时用的sizeof(DeviceParam)，如果结构体里有编译对齐，可能会有填充字节。EEPROM不在乎这些字节，只要写入和读取时用的是同一个结构体定义、同一个编译器选项就行。但如果你将来会换平台或升级固件，建议把结构体定义成#pragma pack(1)或者用固定长度数组逐字节赋值，避免跨编译器对齐不一致导致参数错位。
4. 几件必须注意的事：避坑经验之谈
4.1 写保护引脚WP，为什么你的数据写不进去
AT24C64有WP（Write Protect）引脚，低电平时允许写入，高电平时整个芯片变成只读。这是一个非常隐蔽的坑，因为有些模块原理图上WP直接接了高电平，你调试了半天读数据都正常，但写入时怎么都不成功，也不报错，只是读回来全是旧数据。
我第一次用这个芯片时也在这栽过跟头。排查问题时先把WP引脚状态量了一遍，确认硬件上拉还是下拉，再决定软件里是否需要处理。如果你的板子上WP是固定接地或固定接高，驱动代码不用管；但如果你做了跳线或GPIO控制，驱动里就要加一个WP_Enable()的功能函数，上电默认拉低保证可写，要进入“只读模式”再拉高。
4.2 I2C无应答（NACK）最常见的三种原因
I2C通信失败最容易看到的现象就是设备不应答。我总结下来，90%的原因集中在三个方面：
- 设备地址不匹配。确认A2、A1、A0引脚的实际电平，对照手册确认地址。特别是从网上抄例程时，别人的硬件地址和你的不一样，直接换成7位地址或者加上读写位导致错乱。
- 上拉电阻缺失或值不对。I2C总线需要上拉电阻把SDA和SCL拉高，常见值4.7kΩ。如果你在快速模式下（400kHz）通信，上拉电阻太大（比如10kΩ）会导致上升沿太慢，通信不稳定；太小（比如1kΩ）又会增大损耗。我习惯用4.7kΩ兼容不同速率。
- 总线被拉死。SDA低电平持续不释放，一般是某个从机内部状态异常。解决办法是给SCL来8~9个时钟脉冲，让从机复位状态机，或者彻底断电重新上电。
4.3 页写时的数据覆盖，最经典的数据丢失场景
页写导致数据错乱是最经典的问题。比如从地址14开始，一次写入30字节。如果你没做跨页判断，直接把30字节塞进I2C发送缓冲，芯片内部会在写完地址14~31这18字节后，继续写入地址0~11，把你最早写入的部分数据覆盖掉。这种现象最难排查，因为看起来“好像写进去了，但数据怪怪的”，不是全丢，是部分错乱。
我习惯在页写函数里做一个自检：len <= AT24C64_PAGE_SIZE - (addr % AT24C64_PAGE_SIZE)，一旦发现超过就拆包写入。另外，如果你从网上扒驱动，一定要检查它有没有做这个判断，很多教程代码为了演示简单，跳过了这步，复制过来就埋雷。
4.4 读取数据前面正常、后面全是0xFF，怎么回事
这个问题通常出现在跨页读上。前面说过读操作地址会自动递增，但有个隐藏前提——地址递增只在页内有效，或者说地址计数器会回卷。读操作跨页时，地址不会自动跳到下一页，而是回卷到当前页起始地址。如果你读的长度超过页大小，后面的数据会读到当前页的开头，看起来就像数据错乱。
所以读函数同样要小心。要么在驱动里像写函数一样做跨页拆分，要么在应用层保证每次读操作长度不超过页大小。我把这个逻辑也写进驱动里的原因就在这里，省得每个项目都重复踩坑。
5. 实际调试过程记录：一次完整的AT24C64驱动验证
5.1 刚上电，读数全是0xFF？先看地址对不对
拿到一块新板子或者新模块，我上电后的第一件事不是写数据，而是先读一遍。如果读出来全是0xFF，这是EEPROM出厂状态，正常。但如果你读出来全是0x00或者乱码，就要怀疑地址或接线问题了。
具体排查顺序：先拿万用表量SDA和SCL的静态电平，正常应该都被上拉到高。如果有一个是低，说明总线有问题或者某个器件把它拉死了。然后测AT24C64的供电引脚，确认电压正常。最后再检查设备地址，特别是A0/A1/A2的上下拉。有个取巧的办法：如果地址不确定，可以把A0~A2三个引脚都接地或都接高，得到一个基准地址，先能通信再说。
5.2 写入后再读回，数据不一致怎么排查
写完了再读，发现数据不一致，先别怀疑芯片坏了。把问题拆开来看：是第一次写就不对，还是写多次后不对；是某一位的数据错误，还是整段错位；是单字节写没问题、页写有问题，还是反过来。
我遇到过一次很奇怪的现象：单字节写没问题，页写32字节后，读回前16字节正确，后16字节全是上一轮的数据。查到最后发现是页写起始地址没有按页对齐，地址落在一片区域的中间，而页内剩余空间不足32字节，芯片自动回卷，把数据叠加到了页开头。解决办法就是上面说的，写之前算好页剩余空间，不够就拆。
5.3 掉电测试与长时间运行验证
驱动的稳定性不能靠上电读两次数就行，一定要做掉电测试。我写EEPROM驱动后，习惯用这样的手段验证：上电后写入一组随机数据，掉电，再上电读回比对。连续做200次，每次写入内容不同，长度从1字节到几百字节随机。这能同时验证写周期时序、页写拆分逻辑和地址计算。
还有一次让我印象深刻的是，客户反馈设备运行几天后参数偶发丢失。后来发现是写EEPROM和系统掉电时序有冲突——系统检测到掉电后，在电压跌落到芯片最低工作电压以下时还在写EEPROM，导致写周期没有完成。这是典型的硬件和软件配合问题，驱动里需要加一个电源状态判断，保证在电压安全范围内才允许写入。
6. 驱动文件常见的移植问题
6.1 从24C02移植到AT24C64，哪些代码必须改
AT24C64和24C02原理一模一样，但代码不能无脑复制。主要差异在三点：
- 设备地址不同。24C02如果A0~A2接地，地址是0xA0；AT24C64也是0xA0，但如果你的板子上A0~A2接法不同，地址就不同。
- 页大小不同。24C02的页是8字节，AT24C64是32字节。如果你的驱动里硬编码了8字节页，写入AT24C64时速度会慢很多，但不会出错；反过来硬编码32字节写到24C02，就会数据覆盖。
- 内部地址宽度不同。24C02只有8位地址，AT24C64需要16位地址。体现在驱动上是写地址时的高字节和低字节，代码上的差异一定要确认。
我在工程里习惯用一个配置头文件统一管理这些差异，换芯片时只改宏定义，不碰逻辑代码：
#define EEPROM_ADDR 0xA0 #define EEPROM_PAGE_SIZE 32 #define EEPROM_ADDR_SIZE 2 // 1 表示8位地址，2 表示16位地址6.2 驱动函数返回值和错误处理怎么设计才可靠
驱动写得稳不稳，很大程度看错误处理是否到位。我自己的驱动统一用返回0表示成功，负数表示失败。每层函数向上传递错误码，不做吞掉错误的处理。
总线层如果发送无应答或者超时，立即返回错误。设备层在参数合法性检查上就拦住，比如地址越界、长度为零。应用层在调用设备层接口后，一定要检查返回值，不能写完就当成功了。很多数据丢失的Bug就是源于“写入失败但没人管”。
6.3 GPIO模拟I2C模式下，如何提高通信稳定性
最后说一点软件模拟I2C提速的小技巧。模拟I2C时序最容易因SCL低电平时SDA变化而误触发生成STOP条件。正确时序是先改SDA（数据准备好），再拉高SCL，保持一定延时，再拉低SCL，在SCL低电平期间改SDA准备下一位。写代码时严格按照这个流程来，并且给每步操作加上微秒级的延时，至少在低速100kHz模式，稳定。
驱动文件的用户层面，我还习惯在模拟I2C的延时函数里加上volatile空指令，防止被优化掉。否则编译器优化后时序被压缩，波形变形，通信不稳，查起来非常痛苦。
7. AT24C64之外的思考：驱动设计给你留下的通用能力
写完这版AT24C64驱动，我的感受是做嵌入式存储，真正难的不是“能读写”，而是把边界情况全部考虑完整。看代码量可能也就两三百行，但每一处“if判断”“延时等待”背后都是实际项目里踩出来的认知。
这个驱动文件的框架，稍作修改就能套用到24C02、24C16、AT24C128这些同系列芯片上。换芯片时要处理的差异其实就是那几点：设备地址、页大小、地址宽度。把握住这三条，任何I2C接口的EEPROM对你来说都不再是黑盒。
最后再分享一个小技巧：在AT24C64里规划参数存储时，建议把多个参数分组存放，并且在每组开头放一个magic字段和version字段。这样一来，后续升级固件或者改变参数结构时，可以通过magic和version做兼容判断，决定是直接读取还是恢复默认。这个习惯帮我避免过很多“参数结构变更导致设备变砖”的售后问题。EEPROM的容量不算大，但操作规范了，它能替你省下的调试时间绝对远超你花在驱动上的那点功夫。
本文还有配套的精品资源，点击获取
