简介：面向STM32F0系列单片机开发者，这份资源提供了驱动24C64/FM24C64这类64K位I²C接口EEPROM的完整C语言源码，解决在STM32F0上配置I²C外设、收发数据与移植适配的核心问题。包内含24Cxx.c与24Cxx.h两个源文件，涵盖I²C总线初始化、GPIO引脚映射、读写命令封装以及中断处理等关键环节，源码体量精简，压缩包仅3KB，适合快速集成到现有工程或嵌入式入门练习。目前已有1566人学习下载，具备一定参考价值。通过研读这两个文件，可以理解EEPROM的页写、随机读等操作时序，并掌握在STM32F0平台上从外设时钟配置到中断服务例程的完整驱动实现思路，进而针对不同硬件布局灵活调整引脚与传输速率，顺利完成移植。
1. 项目概述
1.1 为什么用 FM24C64 而不是普通 EEPROM
接到这个需求的时候，第一反应是确认一件事：用户说的是 24C64，但标题里特意写了 FM24C64。这不是手误，而是特意区分。FM24C64 是 Cypress（现在归 Infineon）出品的铁电存储器，容量同样 64Kbit，I2C 接口，引脚和时序兼容普通 24C64，但内部原理完全不同。普通 24C64 是 EEPROM 浮栅晶体管存储，写入需要电荷泵升压、擦写时间通常要等 5ms 甚至更久，而且擦写寿命标称 100 万次，实际用下来总让人不踏实。FM24C64 是铁电晶体存储，写入不需要擦除步骤，也不存在“写一个字节要等 5ms”的说法，速度能和总线时序同步，寿命标称 1000 亿次（10 的 12 次方），直接拉开好几个数量级。
对于 stm32f0 这种入门级 MCU 来说，搭配 FM24C64 的场景非常明确：设备参数频繁保存、运行日志滚动记录、校准数据每次上电更新。普通 EEPROM 在这类场景下有两个痛点，一个是写一次等 5ms，批量写参数时明显卡顿，另一个是频繁写入很快逼近寿命上限。FM24C64 在这两点上都是碾压级的优势，代价仅仅是单颗价格贵几毛钱到一块多钱，很多工程师在方案选型时会忽略这个差异，等项目量产之后才发现普通 EEPROM 写入寿命不够，再换片子改驱动，底板和软件都要动，成本反而更高。
1.2 这套程序解决的核心问题
我把这套驱动拆成三个层面来讲：第一层是 stm32f0 的 I2C 外设初始化，这个不多说，F0 的 I2C 和 F1 的寄存器设计完全不同，F1 老代码不能直接搬；第二层是 FM24C64 的协议时序实现，包括单字节读写、页写、连续读；第三层是工程实用细节，比如设备检测、写保护处理、异常恢复。读完这篇文章，你可以直接在 stm32f0 平台上把 FM24C64 跑通，不用再翻数据手册一点点抠时序参数。
2. 硬件连接与基础配置
2.1 引脚分配和上拉电阻
FM24C64 的封装是标准的 8 脚 SOIC 或 DIP，引脚定义和 24C64 一致：A0、A1、A2 是地址选择脚，SDA、SCL 是 I2C 数据时钟，WP 是写保护，VCC 和 GND 供电。这里第一个坑就是 A0、A1、A2 不能悬空，必须接确定的电平。FM24C64 的 7 位 I2C 地址高 4 位固定为 1010，低 3 位就是 A2、A1、A0 的输入电平，比如三个脚全部接地，设备地址就是 0x50，写地址 0xA0，读地址 0xA1。如果引脚悬空，芯片内部读取到的电平不确定，地址漂移会造成通信时好时坏，排查起来非常折磨人。
上拉电阻的选择也值得说一下。I2C 总线是开漏结构，SCL 和 SDA 必须有上拉电阻才能输出高电平。常见的选法是 4.7kΩ，但如果总线速率跑 400kHz，而且线上挂的设备多、走线长，4.7kΩ 可能导致上升沿太缓，建议换 2.2kΩ。我通常先在原理图上预留 2.2kΩ 到 4.7kΩ 的封装，实测波形之后再做调整。stm32f0 的内部上拉不要太指望，I2C 应用下内部上拉阻值太大，约 30kΩ 到 50kΩ，只能勉强维持低速率，400kHz 下不建议依赖。
2.2 stm32f0 的 I2C 外设与时钟配置
stm32f0 的 I2C 外设和 stm32f1 差别很大，这点很多人栽过跟头。F1 的 I2C 是传统模块，状态标志散落在多个寄存器里，用库函数操作相对顺手；F0 的 I2C 是新设计的内核，兼容 SMBus，寄存器集中到 CR1、CR2、ISR、ICR 这些寄存器里，状态标志也统一在 ISR 中。所以网上搜到的大部分 F1 I2C 驱动代码，不能直接往 F0 上套。
时钟配置是 F0 I2C 最容易被忽略的部分。I2C 外设的时钟源来自 APB1，而 APB1 的频率又取决于系统时钟和分频配置。F0 的 I2C 时序参数不是简单的分频器设置，而是通过 TIMINGR 寄存器里的 SCLL、SCLH、SDADEL、SCLDEL 四个字段精确控制。比如系统时钟 48MHz，想跑 400kHz 的 I2C，SCLL 和 SCLH 的值需要按公式计算，还要考虑上升沿时间。手动算容易出错，我的建议是先用 CubeMX 生成一份 I2C 初始化代码，把 TIMINGR 的值记下来，之后无论用寄存器还是 HAL 库，都用这套参数，这样可以少踩很多坑。
在 CubeMX 中配置 I2C1，引脚默认是 PB6(SCL) 和 PB7(SDA)，复用功能 AF1。时钟设置里 I2C1 时钟选择 48MHz，速度模式选 Fast Mode，目标频率填 400000。生成代码之后打开 i2c.c，能看到类似这样的时序计算值：
hi2c1.Instance = I2C1; hi2c1.Init.Timing = 0x00702991; hi2c1.Init.OwnAddress1 = 0; hi2c1.Init.AddressingMode = I2C_ADDRESSINGMODE_7BIT;0x00702991 这个值不要随便动，它是按照 48MHz 输入时钟、400kHz 目标频率、I2C 规范上升沿时间反推出来的。如果后续你把系统主频改了，这个值必须重新计算，否则通信时序直接异常。
3. 软件实现与代码解析
3.1 初始化与基础宏定义
无论用寄存器还是 HAL 库，都要先明确 FM24C64 的地址分配。三个地址脚都接地的情况下：
| 项目 | 值 |
|---|---|
| 7 位设备地址 | 0x50 |
| 写地址（8 位） | 0xA0 |
| 读地址（8 位） | 0xA1 |
| 存储容量 | 8192 × 8 bit |
| 内存地址宽度 | 2 字节 |
FM24C64 的容量是 64Kbit，也就是 8KB，内存寻址需要 2 个字节，这和 24C02 之类的 1 字节寻址设备不一样。驱动里凡是涉及地址发送的地方，都要分高字节和低字节两次发送，这个细节如果漏掉，读写地址就会错乱，表现就是读到的数据位置完全不对。
使用 HAL 库的话，初始化代码极简，前面 CubeMX 生成的基础初始化已经完成。自己写的话，寄存器版本的关键代码是开时钟、配 GPIO、配置时序，再加一个使能：
void FM24C64_Init(void) { // 1. 使能 GPIOB 和 I2C1 时钟，F0 的 GPIO 时钟在 AHB 总线上 RCC->AHBENR |= RCC_AHBENR_GPIOBEN; RCC->APB1ENR |= RCC_APB1ENR_I2C1EN; // 2. 配置 PB6/PB7 复用为 I2C1，AF 编号为 1 GPIOB->AFR[0] &= ~(0xFFUL << (6 * 4)); GPIOB->AFR[0] |= (0x01UL << (6 * 4)); // PB6 -> AF1, SCL GPIOB->AFR[0] &= ~(0xFFUL << (7 * 4)); GPIOB->AFR[0] |= (0x01UL << (7 * 4)); // PB7 -> AF1, SDA GPIOB->MODER &= ~(0x3UL << (6 * 2)); GPIOB->MODER &= ~(0x3UL << (7 * 2)); GPIOB->MODER |= (0x2UL << (6 * 2)); // PB6 复用模式 GPIOB->MODER |= (0x2UL << (7 * 2)); // PB7 复用模式 GPIOB->OTYPER |= (0x3UL << 6); // 开漏输出 GPIOB->PUPDR &= ~(0xFUL << (6 * 2)); // 不使能内部上下拉 // 3. 配置 I2C 时序，0x00702991 对应 48MHz/400kHz I2C1->TIMINGR = 0x00702991; // 4. 使能 I2C 外设 I2C1->CR1 |= I2C_CR1_PE; }注意 GPIO 配置为开漏输出，这是 I2C 协议的要求。如果误配置为推挽输出，一旦某个设备拉低总线，另一个设备输出高，就会形成短路电流，轻则通信异常，重则烧毁引脚。使用内部上拉的习惯在这里也要改掉，外接上拉电阻的方案更加可靠。
3.2 写入操作：单字节与页写入
FM24C64 的写入操作流程：发送 START，发送设备写地址，等待 ACK，发送内存地址高字节，等待 ACK，发送内存地址低字节，等待 ACK，发送数据字节，等待 ACK，发送 STOP。和普通 24C64 最大的不同是，FM24C64 写完不需要等待内部写周期，总线时序上可以连续操作，但为了代码在两个芯片之间无缝切换，很多人会习惯性加一个短延时，这个不影响功能。
用 HAL 库的话，直接调现成的函数最省事：
uint8_t data = 0x5A; uint16_t addr = 0x1234; HAL_StatusTypeDef status; status = HAL_I2C_Mem_Write(&hi2c1, 0xA0, addr, I2C_MEMADD_SIZE_16BIT, &data, 1, 100); if (status != HAL_OK) { // 写入失败，可能是设备离线、地址错误、总线异常 }这段代码里的 I2C_MEMADD_SIZE_16BIT 参数就是关键，告诉 HAL 库内存地址是 2 字节宽度。如果用了 8BIT，HAL 库只发一个地址字节，FM24C64 会认为这是高字节，而低字节则完全没收到，写入位置直接错掉。
页写入方面，普通 24C64 的页大小是 32 字节，FM24C64 同样兼容这个分页规则。一次页写入发送的数据一旦超过页边界，数据会回卷到页首，覆盖掉页开头的数据，这是必须注意的。所以实现页写入时，要么保证写入长度不超过 32 字节，要么手动拆分，或者写一个跨页边界检测的函数：
uint8_t FM24C64_WritePage(uint16_t addr, uint8_t *buf, uint16_t len) { uint16_t page_remain; uint16_t offset = 0; if (buf == NULL || len == 0) return 1; while (offset < len) { // 计算当前页剩余空间 page_remain = 32 - (addr % 32); if (page_remain > (len - offset)) page_remain = len - offset; if (HAL_I2C_Mem_Write(&hi2c1, 0xA0, addr, I2C_MEMADD_SIZE_16BIT, &buf[offset], page_remain, 100) != HAL_OK) { return 1; } addr += page_remain; offset += page_remain; } return 0; }这里有一个优化点：FM24C64 本质上不要求页写入长度必须限制在 32 字节内，它没有普通 EEPROM 的页缓冲回卷问题。但保留分页逻辑是保守且兼容的做法，可以防止代码将来直接换 24C64 时踩坑。
3.3 读取操作：随机读与连续读
读取 FM24C64 比写入稍微绕一点。随机读要先发一个“伪写”序列，把目标地址写进去，然后重新发 START，再发设备读地址，之后才能从数据线上读数据。连续读则是读完成一个字节后继续接收下一个，MCU 每返回一个 ACK，芯片地址自动加一，直到 MCU 发送 NACK 和 STOP 结束。
HAL 库封装了这套流程，调用非常简单：
uint8_t buf[32]; uint16_t addr = 0x1234; HAL_StatusTypeDef status; status = HAL_I2C_Mem_Read(&hi2c1, 0xA1, addr, I2C_MEMADD_SIZE_16BIT, buf, 32, 100); if (status != HAL_OK) { // 读取失败 }连续读多字节时，芯片地址会从起始地址开始逐一递增，跨越页边界后自动回卷到存储区的开头，这一点和写入时的回卷逻辑不同。如果希望连续读不跨物理区域，可以在应用层做长度限制，比如一次读取不超过 32 字节，或者干脆读取完整区域后再在内存中做拼接。
一个实际经验：FM24C64 的读操作同样没有等待时间，数据手册上标明读周期不消耗写入恢复时间，这比普通 EEPROM 在频繁读场景下更省心。但要注意，如果总线上同时挂了其他 I2C 设备，读操作期间总线的占用时间并不短，连续读 1KB 数据是 8192 个时钟，再加上 ACK 位， 400kHz 下大约 20ms 以上，这期间不能让其他设备的实时性要求受到影响。
3.4 设备在线检测与写保护处理
工程上写驱动，一定要有一个“设备是否存在”的检测函数，否则主机单方面发数据，设备没应答，程序就会卡死或者误报成功。判断 FM24C64 是否在线，最简单方法是发出设备写地址后看是否收到 ACK：
uint8_t FM24C64_IsConnected(void) { HAL_StatusTypeDef status; status = HAL_I2C_IsDeviceReady(&hi2c1, 0xA0, 1, 100); return (status == HAL_OK) ? 1 : 0; }这个函数本质是发一个 START，然后发送设备写地址，监听 ACK/NACK。如果芯片在线，会返回 ACK；如果不在线，总线无响应，超时后 HAL 库返回错误。
WP 脚的处理在实际项目中经常被忽略。FM24C64 的 WP 接高电平时，整个存储区变成只读，写命令都不会生效。很多产品在量产时会把 WP 固定接 GND 保证可写，但如果有防止误写的需求，可以在原理图上把 WP 接到 MCU 的一个 GPIO，软件需要写入时拉低，平时拉高。注意，写入前必须确认这个引脚电平，否则程序跑了一整天，发现数据一直写不进去，排查半天才意识到 WP 被拉高了。
4. 常见问题与排查实录
4.1 通信卡死：标志位未清除
用寄存器方式写 F0 I2C 驱动时，最常见的故障是程序卡死在等待某个标志位的循环里。F0 的 I2C 中断标志清除方式和 F1 不同，很多标志位不是读一下寄存器就自动清除，而是要往 ICR 寄存器写特定位才能清掉。比如 NACKF 标志，一旦设备无应答，NACKF 就会置位，如果不清除，后续所有通信都会受到影响。
标准做法是在每次通信开始前，把 ICR 里相关的标志位全部写 1 清除：
I2C1->ICR |= I2C_ICR_NACKCF | I2C_ICR_STOPCF | I2C_ICR_TXISCF;另外还要注意 ARLO 标志，这是仲裁丢失标志。多主机环境下两个主机同时抢总线时会出现，单主机系统虽然不常见，但总线干扰也可能触发。出现后同样要清标志、重新初始化总线状态，否则后续通信无法继续。
4.2 读回全是 0xFF 或 0x00
FM24C64 上电后的默认值通常不是 0xFF（普通 EEPROM 出厂默认全 0xFF），但很多情况下读回 0xFF 意味着通信没建立起来。排查顺序建议这样走：
第一，确认设备地址。三个地址脚的电平是否和代码里一致，特别检查 PCB 上 A0-A2 是否有虚焊。第二，用示波器或逻辑分析仪抓 SCL 和 SDA 波形，看主机有没有发出 START 信号、地址字节有没有正确发出。第三，确认电压。FM24C64 的 VCC 通常支持 2.7V 到 5.5V，但如果用的是 FM24CL64 低压版本，工作电压范围不同，电压过高或过低都会造成通信异常。第四，检查 SDA 在 ACK 位的时间点上有没有被拉低，如果没有，说明设备根本没响应。
读回全 0x00 的情况相对少见，通常是地址设置到了未初始化的区域，或者芯片本身有问题，可以用示波器看波形确认数据线上是不是真的读到了 0x00。
4.3 写入成功但读出来是旧数据
这类问题的根源通常是写入未生效，但代码没有检测到错误。用 HAL_I2C_Mem_Write 时，如果函数返回 HAL_OK，只表示主机把数据发完了，不表示芯片内部写入成功。普通 24C64 在页写入期间如果主机发新命令，芯片不响应，而 FM24C64 没有这个问题，所以很多 FM24C64 的写入失败其实不是等待时间的问题，而是地址越界或 WP 引脚状态不对。
排查时先读一遍 WP 引脚的电压，再检查写入地址是否落在 0x0000 到 0x1FFF 范围内（8192 字节）。这两个地方都没问题的话，可以做一个回读校验：写完立刻读回来比对，这是最简单有效的自检手段，我习惯把回读校验做成一个统一的接口，调试阶段默认开启。
4.4 总线干扰与重试机制
I2C 总线在工业现场容易受到干扰，表现为偶发的 NACK、总线卡死、数据错位。FM24C64 本身电气特性不错，但板级设计和 MCU 配置如果不注意，抗干扰能力会大打折扣。一个容易忽略的地方是 SDA 和 SCL 两条线不能长距离并行，否则信号串扰严重，走线要尽量短，且不要靠得太近。
软件上建立重试机制非常有必要。我常用的策略是：一次读写操作如果失败，先清除总线状态，发一个 STOP 信号，延时 1ms 后重试，最多重试 3 次。连续 3 次失败才上报错误，这样可以过滤掉大部分瞬时干扰。实测在电机驱动板这样的强干扰环境下，重试机制能把 I2C 通信的可靠性从 95% 提升到接近 100%。
4.5 代码移植到 F1 或 G0 的问题
FM24C64 驱动里，硬件层是跟 MCU 绑定的，但协议层完全通用。如果从 F0 移植到 F1，I2C 外设架构变了，寄存器初始化需要重写，但设备地址、页写入逻辑、回读校验这些函数直接复用。如果移植到 G0 系列，I2C 外设结构和 F0 一致，TIMINGR 寄存器依然是同一个套路，基本可以无缝迁移，只需要重新算一遍时序参数。
一个实用的做法是把设备抽象成两层：底层是 I2C 读写函数，上层是 FM24C64 的地址和数据操作函数。上层完全不依赖具体 MCU 型号，换平台时只需要替换底层的几个函数即可，编译、测试成本都低很多。
5. 扩展应用
驱动跑通之后，FM24C64 的很多特性值得进一步利用。比如它的写入寿命很长，可以把设备的掉电保存参数做成“每次修改立即写入”，而不是像传统 EEPROM 那样只在关机前写一次。另一个常见的玩法是日志功能：系统运行状态按周期写入存储区，配合读指针和写指针实现环形队列，FM24C64 的高速写入可以保证日志记录不丢帧，寿命也能撑住频繁擦写。
我自己用 FM24C64 做过多通道传感器的校准参数存储，每次校准时写几十字节，一天校准十几次，随便用十年都不需要考虑寿命问题。换成普通 24C64 的话，按每天写 100 字节计算，100 万次寿命大约 5 年就会耗尽，对于产品来说这个余量明显不够。FM24C64 的成本优势在这种场景下体现得特别直接：一块钱出头的差价，换来几十年的寿命余量，非常划算。
最后分享一个调试验证的小技巧：写完驱动后，不要直接开始业务逻辑，先写一个存储器全片测试函数，向每个 32 字节页写入模式数据，比如 0x00 到 0xFF 循环，然后回读逐字节比对。这个测试能一次性暴露地址线、页回卷、总线稳定性等几乎所有底层问题。跑通了全片测试，后面无论业务功能怎么叠加，存储部分都可以高枕无忧。
本文还有配套的精品资源，点击获取
