简介：本资源是一套面向嵌入式开发初学者与中级工程师的AT24C64 EEPROM驱动实现，专为基于I²C总线的微控制器系统设计，解决外置非易失存储器的数据读写、配置保存与掉电续存等典型需求。压缩包共3个文件（1KB），含核心驱动源码drv_at24c64.c（实现初始化、页读写、应答等待及基础错误处理）、配套头文件drv_at24c64.h（定义I²C地址、函数原型与配置宏），以及一份说明性文本文件，辅助理解使用场景与集成方法。代码结构清晰、注释完整，已适配常见MCU平台，可直接纳入Keil/IAR/STM32CubeIDE等工程，大幅降低I²C EEPROM接入门槛。目前已有451人学习下载，读者可直接获取开箱即用的模块化驱动组件、规范的接口封装逻辑，以及关键通信时序与页写入边界处理等实战细节，显著提升嵌入式固件中数据持久化功能的开发效率与可靠性。
1. AT24C64驱动文件：一块8KB EEPROM芯片的“心跳控制器”，嵌入式开发者调试I²C外设时最常翻出来的那套底层代码
你手头有一块STM32F103C8T6最小系统板，接上AT24C64——这个经典8KB串行EEPROM芯片，想存个设备校准参数、记录断电前的状态快照，或者实现固件升级时的配置热切换。但一通I²C初始化后，HAL_I2C_Master_Transmit()返回HAL_BUSY，示波器上看SCL被拉死，地址0x50发过去没ACK，甚至MCU直接卡死进HardFault。这时候你真正需要的，不是又一篇讲I²C协议原理的博客，而是一份能直接烧进工程、改两行就跑通、出问题有迹可循的AT24C64驱动文件。它不依赖HAL库高级封装，也不堆砌RTOS抽象层，就是裸机级的寄存器操作+状态机轮询+页写保护逻辑+地址自动递增处理——专为资源受限的Cortex-M3/M0场景打磨。如果你正在做工业传感器节点、智能电表本地存储、或任何需要掉电不丢数据且不能用Flash模拟EEPROM的项目，这份驱动就是你调试I²C总线时反复打开、逐行比对、最终拍板量产的那套“可信基线”。
2. 驱动架构与核心模块拆解：从I²C物理层握手到8KB地址空间映射的完整链路
2.1 物理层适配：为什么必须重写I²C底层而非直接调用HAL
AT24C64对时序极其敏感：标准模式下SCL高电平时间需≥4μs，低电平≥4.7μs；起始条件建立时间≥4.7μs；而很多HAL库默认配置的GPIO翻转速度过快，或在中断优先级配置不当情况下，导致SCL被意外拉低超时。更关键的是，AT24C64的页写（Page Write）机制要求单次写入不超过32字节（其内部页大小为32B），且地址必须落在同一页面内——这无法通过HAL_I2C_Master_Transmit()一次性传入任意长度buffer来安全实现。因此本驱动采用纯GPIO模拟I²C + 状态机轮询方案：
- SDA/SCL引脚全程由软件控制推挽/开漏模式切换
- 所有延时使用
__NOP()循环而非SysTick，避免中断干扰时序 - 每次写操作前强制检测总线空闲（SCL & SDA均为高）
- 地址计算时自动对齐到页边界（
addr & 0xFFE0）
提示：该设计牺牲了少量CPU占用率，换来的是在无RTOS、无DMA、甚至无SysTick的极简Bootloader中100%可靠运行的能力。
2.2 地址空间管理：8KB如何映射到7位I²C地址+16位内存偏移
AT24C64物理容量为64Kbit = 8KB，但I²C协议仅支持7位设备地址（实际传输8位含R/W位）。其地址编码规则如下：
| A2 | A1 | A0 | 对应设备地址（7位） |
|---|---|---|---|
| 0 | 0 | 0 | 0x50 |
| 0 | 0 | 1 | 0x51 |
| ... | ... | ... | ... |
| 1 | 1 | 1 | 0x57 |
而芯片内部8KB空间由16位地址指针寻址（0x0000 ~ 0x1FFF）。驱动中定义：
#define AT24C64_BASE_ADDR 0x50U // 硬件A2/A1/A0接地时的7位地址 #define AT24C64_PAGE_SIZE 32U // 页写最大字节数 #define AT24C64_TOTAL_SIZE 0x2000U// 8KB = 0x2000 bytes所有读写函数均接收uint16_t addr参数，内部自动拆分为：
- 高8位 → I²C子地址（Subaddress）发送字节1
- 低8位 → I²C子地址（Subaddress）发送字节2
例如写入地址0x1234：先发0x12，再发0x34，然后跟数据流。
2.3 核心状态机：at24c64_write_page()如何规避页写越界风险
页写是提升写入效率的关键，但也是最容易翻车的环节。本驱动将页写封装为独立函数，严格校验三重边界：
// at24c64.c HAL_StatusTypeDef at24c64_write_page(uint16_t start_addr, const uint8_t *data, uint16_t len) { uint16_t page_start = start_addr & ~(AT24C64_PAGE_SIZE - 1); // 向下取整到页首 uint16_t page_end = page_start + AT24C64_PAGE_SIZE - 1; // 当前页末地址 if (start_addr > page_end || (start_addr + len - 1) > page_end) { return HAL_ERROR; // 跨页写入直接拒绝 } // 1. 发送起始条件 + 设备地址 + 写标志 if (i2c_start_condition() != HAL_OK) return HAL_ERROR; if (i2c_send_address(AT24C64_BASE_ADDR, I2C_WRITE) != HAL_OK) return HAL_ERROR; // 2. 发送16位内存地址（大端） if (i2c_send_byte((start_addr >> 8) & 0xFF) != HAL_OK) return HAL_ERROR; if (i2c_send_byte(start_addr & 0xFF) != HAL_OK) return HAL_ERROR; // 3. 循环发送数据（len ≤ 32） for (uint16_t i = 0; i < len; i++) { if (i2c_send_byte(data[i]) != HAL_OK) return HAL_ERROR; } // 4. 发送停止条件 i2c_stop_condition(); // 5. 等待写入完成（最大10ms） return at24c64_wait_ready(10); }关键点说明：
start_addr & ~(AT24C64_PAGE_SIZE - 1)是经典的页对齐位运算（32=0x20 → 0x1F → 取反得0xFFE0），比除法快一个数量级at24c64_wait_ready(10)内部执行“发送设备地址+读标志→检测ACK”循环，利用AT24C64写入期间不响应ACK的特性判断是否就绪- 所有
i2c_*函数均返回HAL_StatusTypeDef，便于上层统一错误处理
2.4 读操作优化：连续读（Current Address Read）与随机读（Random Read）双模式支持
AT24C64支持两种高效读取方式：
- Current Address Read：上次访问后地址指针保持，再次读取自动递增（适合顺序读整个扇区）
- Random Read：显式发送目标地址后再读（适合跳读离散参数）
驱动提供两个接口：
// 随机读：指定地址开始读n字节 HAL_StatusTypeDef at24c64_read_random(uint16_t addr, uint8_t *buf, uint16_t len); // 当前地址读：从当前指针位置连续读（需先执行一次随机读或写操作初始化指针） HAL_StatusTypeDef at24c64_read_current(uint8_t *buf, uint16_t len);at24c64_read_random()实现要点：
HAL_StatusTypeDef at24c64_read_random(uint16_t addr, uint8_t *buf, uint16_t len) { // Step1: 发送设备地址+写标志，设置内存地址（伪写） if (i2c_start_condition() != HAL_OK) return HAL_ERROR; if (i2c_send_address(AT24C64_BASE_ADDR, I2C_WRITE) != HAL_OK) return HAL_ERROR; if (i2c_send_byte((addr >> 8) & 0xFF) != HAL_OK) return HAL_ERROR; if (i2c_send_byte(addr & 0xFF) != HAL_OK) return HAL_ERROR; i2c_stop_condition(); // Step2: 发送设备地址+读标志，开始接收 if (i2c_start_condition() != HAL_OK) return HAL_ERROR; if (i2c_send_address(AT24C64_BASE_ADDR, I2C_READ) != HAL_OK) return HAL_ERROR; for (uint16_t i = 0; i < len; i++) { if (i == len - 1) { // 最后一字节：发NACK + 停止 if (i2c_receive_byte_nack(&buf[i]) != HAL_OK) return HAL_ERROR; } else { // 中间字节：发ACK继续接收 if (i2c_receive_byte_ack(&buf[i]) != HAL_OK) return HAL_ERROR; } } i2c_stop_condition(); return HAL_OK; }参数说明：
i2c_receive_byte_ack()：接收字节后拉低SDA发ACK，请求下一字节i2c_receive_byte_nack()：接收字节后释放SDA（高阻态），主机发STOP- 此设计避免了HAL库中
HAL_I2C_Master_Receive()可能因超时中断导致的ACK/NACK错位问题
3. 编译与移植指南：从STM32CubeMX生成工程到驱动无缝接入的实操步骤
3.1 GPIO引脚配置：为什么SCL必须接推挽输出而SDA要开漏
在main.c中初始化I²C引脚时，必须严格遵循电气特性：
- SCL引脚：配置为
GPIO_MODE_OUTPUT_PP（推挽输出），因AT24C64要求主控主动驱动时钟沿 - SDA引脚：配置为
GPIO_MODE_INPUT_OD（开漏输入）+ 外部上拉电阻（通常4.7kΩ），因SDA为双向线，需支持从机（EEPROM）主动拉低
CubeMX配置示例（以PA9/PA10为例）：
// MX_GPIO_Init() GPIO_InitStruct.Pin = GPIO_PIN_9; // SCL on PA9 GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP; GPIO_InitStruct.Pull = GPIO_NOPULL; GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_HIGH; HAL_GPIO_Init(GPIOA, &GPIO_InitStruct); GPIO_InitStruct.Pin = GPIO_PIN_10; // SDA on PA10 GPIO_InitStruct.Mode = GPIO_MODE_INPUT_OD; // 关键！必须开漏 GPIO_InitStruct.Pull = GPIO_PULLUP; // 外部已有上拉？此处可设NOPULL HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);注意：若使用内部弱上拉（
GPIO_PULLUP），需确认其阻值是否满足I²C总线电容负载要求（通常≤400pF），否则上升沿过缓导致通信失败。强烈建议外接4.7kΩ精密电阻。
3.2 时钟频率校准：如何用示波器验证SCL周期是否符合AT24C64规格
AT24C64标准模式最大时钟频率为100kHz，对应周期10μs。但实际__NOP()延时受编译器优化等级影响极大。驱动中定义：
// at24c64_conf.h #define I2C_DELAY_US(x) do { \ volatile uint32_t _i = (x) * 6; /* 1 NOP ≈ 166ns @ 6MHz SYSCLK */ \ while (_i--) __NOP(); \ } while(0)实测校准步骤：
- 在
i2c_scl_high()函数末尾添加HAL_GPIO_WritePin(GPIOA, GPIO_PIN_12, GPIO_PIN_SET);（用空闲IO打信号） - 在
i2c_scl_low()开头添加HAL_GPIO_WritePin(GPIOA, GPIO_PIN_12, GPIO_PIN_RESET); - 示波器探头接PA12，测量高/低电平时间，调整
_i系数直至SCL周期稳定在10±0.5μs - 记录最终系数写入
I2C_DELAY_US宏（如*7或*5）
此步骤不可跳过——某次我因未校准，在-40℃低温环境下SCL低电平不足4.7μs，导致批量产品偶发写入失败，返工三天。
3.3 工程集成：四步完成驱动接入（不含HAL库冲突处理）
假设你使用STM32CubeIDE生成的Keil工程，集成路径如下：
Step 1：添加源文件
- 将
at24c64.c/at24c64.h复制到Core/Src/和Core/Inc/目录 - 在
Core/Inc/main.h中添加：#include "at24c64.h"
Step 2：声明全局变量
在main.c顶部（/* Private variables ---------------------------------------------------------*/下方）添加：
/* Private variables ---------------------------------------------------------*/ I2C_HandleTypeDef hi2c1; // 若使用HAL_I2C，此句保留但不初始化 // AT24C64专用GPIO句柄（无需HAL，仅存引脚定义） #define AT24C64_SCL_PORT GPIOA #define AT24C64_SCL_PIN GPIO_PIN_9 #define AT24C64_SDA_PORT GPIOA #define AT24C64_SDA_PIN GPIO_PIN_10Step 3：修改初始化函数
在MX_GPIO_Init()末尾追加：
// AT24C64 I2C引脚初始化（覆盖CubeMX生成的默认配置） GPIO_InitTypeDef GPIO_InitStruct = {0}; __HAL_RCC_GPIOA_CLK_ENABLE(); GPIO_InitStruct.Pin = AT24C64_SCL_PIN; GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP; GPIO_InitStruct.Pull = GPIO_NOPULL; GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_HIGH; HAL_GPIO_Init(AT24C64_SCL_PORT, &GPIO_InitStruct); GPIO_InitStruct.Pin = AT24C64_SDA_PIN; GPIO_InitStruct.Mode = GPIO_MODE_INPUT_OD; GPIO_InitStruct.Pull = GPIO_PULLUP; HAL_GPIO_Init(AT24C64_SDA_PORT, &GPIO_InitStruct);Step 4：编写测试用例
在main()函数while(1)循环中加入：
uint8_t test_data[16] = {0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08, 0x09,0x0A,0x0B,0x0C,0x0D,0x0E,0x0F,0x10}; uint8_t read_back[16] = {0}; // 写入地址0x0000 if (at24c64_write_page(0x0000, test_data, 16) == HAL_OK) { HAL_Delay(10); // 等待写入完成 // 读回验证 if (at24c64_read_random(0x0000, read_back, 16) == HAL_OK) { if (memcmp(test_data, read_back, 16) == 0) { // LED闪烁表示成功 HAL_GPIO_TogglePin(GPIOB, GPIO_PIN_0); } } } HAL_Delay(500);4. 常见问题排查：那些让嵌入式老手抓狂的AT24C64玄学故障与血泪解法
4.1 现象：at24c64_write_page()始终返回HAL_TIMEOUT，示波器看SCL被拉低后不再释放
原因：AT24C64写入过程中会主动拉低SCL（Clock Stretching），此时主控必须等待其释放。但驱动中at24c64_wait_ready()超时时间设置过短（如5ms），而实际写入最大耗时达10ms（尤其在高温环境）。
解决：将at24c64_wait_ready()的timeout参数从5改为15，并在循环内增加SCL电平检测：
HAL_StatusTypeDef at24c64_wait_ready(uint16_t timeout_ms) { uint32_t start = HAL_GetTick(); while (HAL_GetTick() - start < timeout_ms) { if (i2c_start_condition() == HAL_OK) { // 尝试发起START，成功说明总线空闲 i2c_stop_condition(); return HAL_OK; } HAL_Delay(1); } return HAL_TIMEOUT; }4.2 现象：随机读（at24c64_read_random）返回全0xFF，但示波器确认SCL/SDA波形正常
原因：SDA引脚配置为GPIO_MODE_OUTPUT_PP（推挽输出），导致EEPROM无法拉低SDA线发ACK。这是新手最高频的配置错误。
解决：严格检查MX_GPIO_Init()中SDA引脚配置，必须为GPIO_MODE_INPUT_OD且外接上拉电阻。用万用表量测SDA引脚对地电压，空闲时应为3.3V，通信时应有明显波动。
4.3 现象：页写（32字节）成功，但写入地址0x001F后下一个字节写到0x0020失败，返回HAL_ERROR
原因：驱动中页边界计算错误。start_addr & ~(AT24C64_PAGE_SIZE - 1)在start_addr=0x001F时结果为0x0000，page_end=0x001F，而0x001F+1=0x0020 > 0x001F触发越界保护。
解决：修改页写校验逻辑，允许跨页但分两次调用：
// 替换原校验段 uint16_t remaining = len; uint16_t offset = 0; while (remaining > 0) { uint16_t page_left = AT24C64_PAGE_SIZE - (start_addr % AT24C64_PAGE_SIZE); uint16_t to_write = (remaining < page_left) ? remaining : page_left; if (at24c64_write_page(start_addr + offset, data + offset, to_write) != HAL_OK) { return HAL_ERROR; } offset += to_write; remaining -= to_write; start_addr += to_write; // 地址自动推进 } return HAL_OK;4.4 现象：设备在-20℃以下环境频繁丢失数据，室温下完全正常
原因：AT24C64的写入时间随温度升高而缩短，但低温下延长。原驱动中at24c64_wait_ready()固定10ms超时，在-40℃时最大写入时间可达20ms。
解决：增加温度补偿机制。若MCU内置温度传感器可用，则动态调整超时：
int16_t temp = HAL_ADCEx_TempSensor_GetTemp(); // 示例API uint16_t base_timeout = 10; if (temp < 0) base_timeout = 20; else if (temp < 25) base_timeout = 12; at24c64_wait_ready(base_timeout);4.5 现象：同一块PCB上多片AT24C64（地址0x50/0x51），只有0x50能通信
原因：A2/A1/A0引脚未明确接VCC/GND，处于浮空状态，受PCB走线电容耦合影响随机翻转。
解决：用10kΩ电阻将未使用的地址引脚硬拉至确定电平。例如只用0x50和0x51，则A2固定接GND，A1接GND（0x50）或VCC（0x51），A0悬空但加100kΩ下拉电阻防干扰。
5. 二次开发实战：为AT24C64驱动添加CRC校验与磨损均衡，支撑工业级数据可靠性
5.1 数据完整性加固：在写入前自动计算并存储CRC16-CCITT
工业场景中，EEPROM数据可能因电源跌落、EMI干扰导致静默损坏。单纯靠读写校验不够，必须引入前向纠错能力。本方案在每页（32B）末尾附加2字节CRC16-CCITT校验码，结构如下：
| 字节偏移 | 0~30 | 31 | 32~33 |
|---|---|---|---|
| 内容 | 用户数据 | 页内有效字节数（1~32） | CRC16校验码 |
驱动新增函数：
// 计算CRC16-CCITT（初始值0xFFFF，多项式0x1021） static uint16_t crc16_ccitt(const uint8_t *data, uint16_t len, uint16_t init) { uint16_t crc = init; for (uint16_t i = 0; i < len; i++) { crc ^= (uint16_t)data[i] << 8; for (uint8_t j = 0; j < 8; j++) { if (crc & 0x8000) crc = (crc << 1) ^ 0x1021; else crc <<= 1; } } return crc; } // 带CRC的页写（自动填充长度和CRC） HAL_StatusTypeDef at24c64_write_page_crc(uint16_t start_addr, const uint8_t *data, uint16_t len) { if (len > 31) return HAL_ERROR; // 预留1字节存长度+2字节CRC uint8_t buf[32]; memcpy(buf, data, len); buf[len] = (uint8_t)len; // 存储实际长度 uint16_t crc = crc16_ccitt(buf, len + 1, 0xFFFF); buf[len + 1] = (crc >> 8) & 0xFF; buf[len + 2] = crc & 0xFF; return at24c64_write_page(start_addr, buf, len + 3); }验证逻辑：
读取时先检查长度字节，再计算CRC并与存储值比对：
HAL_StatusTypeDef at24c64_read_page_crc(uint16_t start_addr, uint8_t *data, uint16_t *len) { uint8_t buf[32]; if (at24c64_read_random(start_addr, buf, 32) != HAL_OK) return HAL_ERROR; uint8_t stored_len = buf[31]; if (stored_len > 31) return HAL_ERROR; uint16_t stored_crc = ((uint16_t)buf[32] << 8) | buf[33]; uint16_t calc_crc = crc16_ccitt(buf, stored_len + 1, 0xFFFF); if (calc_crc != stored_crc) { return HAL_ERROR; // CRC不匹配，数据损坏 } memcpy(data, buf, stored_len); *len = stored_len; return HAL_OK; }5.2 磨损均衡策略：用“影子页”机制延长8KB EEPROM寿命至100万次擦写
AT24C64标称擦写次数为100万次，但若固定地址（如0x0000）频繁更新，该地址单元会率先失效。解决方案是逻辑地址映射：将用户请求的“逻辑地址”映射到物理页，每次写入选择当前擦写次数最少的页。
实现步骤：
- 预留元数据区：用最后1页（0x1FE0~0x1FFF）存储32个页的擦写计数（每页2字节，共64字节）
- 写入时查找最小计数页：遍历元数据找到count最小的物理页号
- 更新映射表：在元数据区记录“逻辑页→物理页”映射关系
- 读取时查表转换：根据逻辑地址查出对应物理页，再读取
核心数据结构定义：
#define METADATA_PAGE_ADDR 0x1FE0 #define MAX_PHYSICAL_PAGES 256 // 8KB / 32B = 256 pages typedef struct { uint16_t erase_count[MAX_PHYSICAL_PAGES]; // 每页擦写次数 uint16_t logical_to_physical[256]; // 逻辑页号→物理页号映射 } at24c64_metadata_t; static at24c64_metadata_t g_meta;初始化元数据（首次上电）：
void at24c64_init_metadata(void) { // 读取元数据页 uint8_t meta_buf[32]; if (at24c64_read_random(METADATA_PAGE_ADDR, meta_buf, 32) == HAL_OK) { // 解析计数和映射表 for (int i = 0; i < 256; i++) { g_meta.erase_count[i] = ((uint16_t)meta_buf[i*2] << 8) | meta_buf[i*2+1]; } // 映射表暂不解析，按需加载 } else { // 首次运行，全置0 memset(g_meta.erase_count, 0, sizeof(g_meta.erase_count)); at24c64_write_page_crc(METADATA_PAGE_ADDR, (uint8_t*)&g_meta.erase_count, 512); } }关键技巧：元数据页本身也需磨损均衡！因此at24c64_write_page_crc()在写元数据时，采用循环缓冲区策略：每次写入元数据到下一个空闲页（如0x1FE0→0x1FF0→0x1FE0），并在页首存序列号，读取时扫描所有候选页取最新者。
5.3 实战验证：用J-Link RTT实时监控EEPROM健康度
为验证磨损均衡效果，接入J-Link RTT（Real Time Transfer）打印关键指标：
#include "SEGGER_RTT.h" void at24c64_print_health(void) { uint16_t min_cnt = 0xFFFF, max_cnt = 0; for (int i = 0; i < 256; i++) { if (g_meta.erase_count[i] < min_cnt) min_cnt = g_meta.erase_count[i]; if (g_meta.erase_count[i] > max_cnt) max_cnt = g_meta.erase_count[i]; } SEGGER_RTT_printf(0, "EEPROM Health: Min=%d, Max=%d, Delta=%d\n", min_cnt, max_cnt, max_cnt - min_cnt); }在主循环中每10秒调用一次，观察Delta值是否长期<100。若Delta持续增大，说明均衡算法失效，需检查映射表更新逻辑。
从那以后我每次给客户交付带EEPROM的固件，都会在产测阶段强制跑满1000次写入循环，用RTT日志确认Delta < 5才放行。因为真正的可靠性，不是写在datasheet里的100万次，而是你亲眼看着它在真实工况下均匀磨损的每一帧日志。希望帮到你。
本文还有配套的精品资源，点击获取
