简介AT24C64驱动文件是一份面向嵌入式开发者的轻量级EEPROM驱动源码包解决在微控制器项目中通过I²C总线读写AT24C64芯片的底层通信问题。驱动包含初始化、按地址读取、页写入、错误处理等核心函数头文件则统一封装I²C地址、页大小与函数原型便于移植到不同MCU工程中适合需要快速集成非易失性存储的入门及中级开发者参考。压缩包内共3个文件包含1个C源码文件、1个头文件和1个说明文本整体仅1KB结构精简可直接复制到工程目录调用。已有448人学习下载具有一定参考热度。资源价值在于提供了可直接使用的AT24C64驱动模板可借此理解I²C协议时序、EEPROM页写入边界处理和驱动分层设计思路随包txt文件或含使用说明与开发笔记有助于减少重复造轮子、加速功能调试。 最近在调一块用AT24C64存配置参数的板子把驱动重新整理了一遍。AT24C64这颗芯片算是I2C接口EEPROM里的老熟人64Kbit容量换算下来是8K字节做参数存储、校准数据、掉电保存这些小任务绰绰有余。网上能找到的驱动零零散散有的只给单字节读写有的页写逻辑还有问题正好借这次机会把整套驱动文件梳理清楚给需要的人省点折腾的时间。这篇东西围绕AT24C64驱动文件展开重点说清楚驱动里每段代码为什么这么写页写边界怎么处理以及调I2C时序时容易踩的坑。适合正在用单片机比如STM32、GD32、ESP32之类接AT24C64做存储功能的开发者新手能照着把驱动跑起来老手也能从里面的排错思路里找到些参考。1. AT24C64驱动文件的核心搞清楚芯片脾气再写代码写驱动之前得先把AT24C64的几个关键参数刻在脑子里不然代码写得再漂亮硬件上跑不通也是白搭。这颗芯片的供电范围是1.8V到5.5V不同电压下读写速度有区别我用的3.3V系统里最大时钟频率能到400kHz标准模式100kHz也没问题为了稳妥起见初始化I2C时钟时直接设成100kHz或者200kHz很少出幺蛾子。1.1 存储结构与地址映射AT24C64内部有128个页每页64字节正好是8K字节8 * 1024 8192字节。页这个概念特别重要因为它直接决定了写操作的效率和稳定性。如果你要写入的数据跨过了页边界就得拆分成两次或多次写操作否则数据会循环覆盖到当前页开头这是个非常经典的坑。设备地址方面AT24C64的器件地址是7位高4位固定为1010低3位由A2、A1、A0硬件引脚决定最后1位是读写方向位。所以一个总线上最多能挂8颗AT24C64地址从0xA0到0xAE包括读写位。我用的板子上A0、A1、A2全部接地所以设备地址就是0xA0写和0xA1读代码里直接用0xA0左移一位或者用0xA0作为基地址都行习惯上写成#define AT24C64_ADDR 0xA0。1.2 页写与字节写的本质区别AT24C64支持两种写模式字节写和页写。字节写就是每次只写1个字节时序简单但效率低。页写可以连续写多个字节但最多只能写64字节而且不能跨页。这里的关键在于页写的“页”边界是固定的比如地址0x00到0x3F是第0页0x40到0x7F是第1页以此类推。如果你试图从0x3E开始写4个字节其实只会写到0x3E、0x3F然后地址计数器翻到0x00继续写把页开头的数据覆盖了这绝对是驱动里最要命的bug。所以驱动里最核心的接口不单单是“写数据”而是要封装一个“跨页安全写入”的函数。我封装了三种接口单字节读写、任意长度跨页写、连续读。实际项目中大部分场景只需要这三种就够。2. 驱动文件的整体设计与接口定义写驱动文件不是把几个函数堆在一起就行得想好调用方是谁、返回什么状态、超时怎么处理。我的驱动分三个层级底层是I2C物理层用HAL库或者SCCB接口实现中间层是AT24C64协议层负责组织地址、处理页边界上层是应用层直接提供“从某地址读N字节”和“往某地址写N字节”的傻瓜接口。2.1 硬件抽象层设计为了可移植性底层I2C读写我单独封装了两个函数i2c_write_bytes和i2c_read_bytes参数包含设备地址、寄存器或内存地址、数据指针和长度。这样无论用STM32的HAL库、ESP-IDF的I2C驱动还是自己用GPIO模拟I2C只需要改这两个函数体协议层代码完全不用动。这是驱动文件最值得花时间的地方不要图省事把硬件操作直接写在AT24C64驱动里不然后期换平台要疯。2.2 协议层三个关键函数协议层我设计了这几个函数AT24C64_WriteBytes(uint16_t addr, uint8_t *data, uint16_t len)任意长度写入内部自动处理页边界。AT24C64_ReadBytes(uint16_t addr, uint8_t *data, uint16_t len)任意长度读取I2C读不用考虑页边界但要注意重复起始位。AT24C64_WriteByte(uint16_t addr, uint8_t data)和AT24C64_ReadByte(uint16_t addr)简易接口内部调用上面两个。这里有个设计点写操作之后必须等待EEPROM内部写周期完成。AT24C64的写周期典型值是5ms最大5ms但实际测试发现不同批次芯片有差异所以我用轮询ACK的方式来检测设备是否忙而不是简单延时5ms。具体做法是发送设备地址后看是否有ACK应答如果没有说明内部还在擦写继续等待直到有ACK为止。3. 核心代码实现与逐段解析直接看代码比空谈理论管用。下面这段是我整理好的驱动核心支持STM32 HAL库别的平台改底层函数就行。3.1 初始化与底层I2C封装#include at24c64.h #include i2c.h #define AT24C64_DEV_ADDR 0xA0 // 硬件地址全部接地 static HAL_StatusTypeDef I2C_WriteBytes(uint8_t dev_addr, uint8_t *data, uint16_t len) { return HAL_I2C_Master_Transmit(hi2c1, dev_addr, data, len, 100); } static HAL_StatusTypeDef I2C_ReadBytes(uint8_t dev_addr, uint8_t *data, uint16_t len) { return HAL_I2C_Master_Receive(hi2c1, dev_addr, data, len, 100); }HAL库自带的HAL_I2C_Master_Transmit会在发送完数据和地址后自动处理停止位这对EEPROM操作够用。注意设备的写地址是0xA0但HAL库函数要求传入8位地址所以实际传入的是0xA0因为AT24C64的7位地址0x50左移一位就是0xA0HAL库内部会自己处理读写位。这块别搞混了很多人直接把0x50传给函数导致通信失败。3.2 等待写周期完成static void AT24C64_WaitReady(void) { uint8_t tmp 0; while (HAL_I2C_Master_Transmit(hi2c1, AT24C64_DEV_ADDR, tmp, 1, 10) ! HAL_OK) { // 如果设备忙NACK会返回错误继续轮询 HAL_Delay(1); } }这个函数利用了AT24C64一个特性在内部写周期进行时设备对任何通信都不发ACK。所以只要发送一个字节看是否返回成功就能判断写没写完。比傻等5ms靠谱得多尤其在连续写入大块数据时能省下不少时间。3.3 页边界计算与任意长度写函数void AT24C64_WriteBytes(uint16_t addr, uint8_t *data, uint16_t len) { uint16_t page_size 64; uint16_t offset_in_page addr % page_size; uint16_t first_chunk page_size - offset_in_page; while (len 0) { uint16_t write_len (len first_chunk) ? first_chunk : len; // 组织要发送的buffer先2字节地址再数据 uint8_t buf[66]; buf[0] (uint8_t)(addr 8); buf[1] (uint8_t)(addr 0xFF); memcpy(buf[2], data, write_len); I2C_WriteBytes(AT24C64_DEV_ADDR, buf, write_len 2); AT24C64_WaitReady(); addr write_len; data write_len; len - write_len; first_chunk page_size; // 后续都从页边界开始 } }这里最容易出错的是first_chunk的计算。比如addr是30页大小64那本页还能写34字节。如果数据长度超过34第一段就写34字节剩余数据从下一个页的地址0x40开始写这时offset就是0所以每次写完后把first_chunk重置为64。这个逻辑必须严格依赖地址递增不能想当然用固定块大小拆分。3.4 读取函数与随机读实现void AT24C64_ReadBytes(uint16_t addr, uint8_t *data, uint16_t len) { uint8_t addr_buf[2]; addr_buf[0] (uint8_t)(addr 8); addr_buf[1] (uint8_t)(addr 0xFF); // 先发送地址然后重复起始位读数据 HAL_I2C_Master_Transmit(hi2c1, AT24C64_DEV_ADDR, addr_buf, 2, 100); HAL_I2C_Master_Receive(hi2c1, AT24C64_DEV_ADDR | 0x01, data, len, 100); }读取不需要处理页边界因为读操作只是让地址计数器自动递增芯片会从头到尾把数据吐出来超过地址范围才会循环。但要注意HAL_I2C_Master_Receive的地址要加0x01变成读地址。有些HAL库版本要求你传入7位地址函数内部自己处理最好查一下手册确认。3.5 简易接口与测试用例uint8_t AT24C64_ReadByte(uint16_t addr) { uint8_t tmp 0; AT24C64_ReadBytes(addr, tmp, 1); return tmp; } void AT24C64_WriteByte(uint16_t addr, uint8_t data) { AT24C64_WriteBytes(addr, data, 1); }这三个函数组合起来基本覆盖了所有业务需求。我习惯在上电初始化时先写一组已知数据再读出来对比一次确认驱动没问题。4. 实测中遇到的坑与排查技巧实录驱动写完不代表万事大吉调试阶段我踩过的坑足够写满一页纸。这里挑几个高概率遇到的问题每个都附带排查思路。4.1 数据写不进读出来全是0xFF这种问题八成是I2C通信根本没建立。先用逻辑分析仪抓波形看SDA上有没有正确的设备地址。最常见的原因有三个设备地址搞错比如把0xA0写成了0x50上拉电阻没接或者阻值太大导致SDA拉不低还有是I2C时钟频率太高某些EEPROM批次不支持400kHz降回100kHz再试。还有一个容易忽略的点如果单片机和EEPROM供电电压不一致那就必须加电平转换电路不然I2C引脚可能被钳位。4.2 写超过一页后数据错乱这个我一开始也中招了以为芯片坏了后来用逻辑分析仪一看芯片地址计数器在跨页时没有自动归位而是翻到了页开头。原因是我的写入函数只做了固定64字节拆分没有考虑起始地址不是页边界的情况。正确做法就是上面代码里的offset_in_page计算先把第一段写到页尾剩余再从下页开始。4.3 连续读写时偶发丢数据偶发丢数据比完全不通更折磨人。最后排查到是I2C中断优先级问题因为系统里有定时器和看门狗在跑I2C中断被高优先级任务打断导致时序不完整。解决办法是把I2C中断优先级调低或者用阻塞式传输并关闭中断。如果你是在RTOS环境下给I2C传输加个互斥锁也很重要。4.4 写周期未完成导致误写如果写完立刻去读而且没做等待读回来的可能是旧数据更糟糕的是接着做第二次写操作可能直接丢失第一次的数据。所以AT24C64_WaitReady必须在每次写操作后调用尤其是页写多字节时每写完一页都要等。5. 驱动文件的扩展与性能优化思路如果项目里存储的数据量不大但写入频繁可以考虑用标志位来管理存储布局避免整片擦写EEPROM不需要擦写可以直接覆盖写但寿命有限。AT24C64擦写次数是100万次对一般参数存储够用但如果每100ms写一次不到3年就废了。所以我通常会把频繁变化的参数放在一个独立的存储区用磨损均衡的思路轮询写入不同的地址。5.1 如何适配其他EEPROM容量AT24C系列家族里还有AT24C022Kbit、AT24C1616Kbit、AT24C128128Kbit等它们的页大小不同。比如AT24C02页大小8字节AT24C04和AT24C08每页16字节AT24C16以上是每页64字节。驱动里只要把page_size宏定义改一下再调整地址位宽就能通用。这也是驱动文件设计成带参数的原因不要把页大小写死在函数里。5.2 驱动的可测试性设计我习惯在驱动里加一个自检函数AT24C64_Check(void)写一组固定模式比如0x00、0xFF、0xAA、0x55到某个地址再读出来比对。这个函数放到出厂检测流程里特别有用。另外如果有剩余存储空间我还会存一个校验值比如CRC16在数据块末尾上电读取后验证能及时发现自己驱动有没有卖出破绽。6. 最后再分享一点个人经验几次调试之后我现在写AT24C64驱动已经不再急着敲代码了先看原理图确认上拉电阻和地址引脚再用逻辑分析仪把通信波形抓稳最后才动手写代码。驱动这东西封装得好一次调通封装得烂能折腾你三天。如果真的遇到诡异问题先怀疑电源和接线再看时序和地址最后才怀疑芯片本身。AT24C64这芯片皮实极少直接坏掉多数都是驱动逻辑在边界条件上出了疏漏。把这套驱动代码加上页边界处理、等待写周期、自检函数这三板斧基本能让它在项目里安安稳稳跑上很多年。本文还有配套的精品资源点击获取