嵌入式I2C驱动设计：从轮询到中断状态机的实战解析

1. 项目概述：从“轮询等待”到“事件驱动”的I2C编程哲学

在嵌入式开发领域，I2C总线因其简洁的两线制（SDA、SCL）和主从多机架构，成为了连接各类传感器、EEPROM、RTC等外设的经典选择。然而，很多工程师在编写I2C驱动程序时，往往陷入一种“轮询等待”的思维定式：发送一个字节，然后死等中断标志位或状态寄存器，确认后再发送下一个。这种方式在低速、简单的应用中或许可行，但在面对高速总线、复杂时序要求（如SMBus协议）或需要MCU同时处理其他任务时，就显得捉襟见肘，效率低下且容易因干扰导致总线挂死。

今天要分享的，是我在十多年前基于Microchip PIC24F系列单片机，实现的一套全中断驱动、状态机管理的通用I2C/EEPROM读写程序。这套代码的核心思想，是彻底抛弃“痴迷等待”，拥抱“事件驱动”。就像在高级语言（如Delphi、C#）中我们为按钮点击、定时器到期编写事件处理函数一样，在MCU上，我们也应该为“收到ACK”、“数据寄存器空”、“收到STOP信号”这些硬件事件编写处理逻辑。当事件发生时，中断服务程序（ISR）被触发，根据当前状态决定下一步动作，然后迅速退出，将CPU时间还给主循环或其他任务。这种异步、非阻塞的编程模式，是构建高效、可靠、可扩展嵌入式系统的基石。

本文将深入拆解这套程序的每一个细节，从状态机设计、中断处理流程，到EEPROM读写保护、缓冲区管理，以及如何将其适配到SMBus等更复杂的协议。无论你是正在为PIC24F的“不太标准”的I2C模块而头疼，还是希望提升自己嵌入式底层驱动的架构能力，相信这篇来自一线实战的总结都能给你带来启发。我们不仅会看代码“怎么写”，更要深究“为什么这么写”。

2. 核心架构解析：状态机与中断的完美融合

2.1 为何选择“全中断”+“状态机”？

在深入代码之前，必须先理解这个架构选择的必然性。传统的“查询式”I2C驱动，其流程通常是线性的、阻塞的。例如，写一个字节到EEPROM的伪代码可能是这样的：

void EEPROM_WriteByte(uint8_t addr, uint8_t data) { I2C_SendStart(); while(!I2C_StartSent()); // 等待START完成 I2C_SendSlaveAddr(WRITE); while(!I2C_AddrAcked()); // 等待地址应答 I2C_SendByte(addr); while(!I2C_ByteAcked()); // 等待地址字节应答 I2C_SendByte(data); while(!I2C_ByteAcked()); // 等待数据字节应答 I2C_SendStop(); while(!I2C_StopSent()); // 等待STOP完成 }

这段代码最大的问题是CPU利用率极低。在每一个while循环中，CPU都在空转，等待一个硬件标志位。对于一款可能还要处理按键、显示、通信的MCU来说，这是巨大的浪费。更危险的是，如果总线上从机无响应（比如器件损坏、线路干扰），程序就会永远卡在某个while循环中，即“总线挂死”，整个系统可能因此瘫痪。

而“全中断”+“状态机”的方案，则完全解决了这些问题：

1. 非阻塞：所有等待硬件事件的过程都由中断自动处理，主循环（或其他任务）可以继续执行，极大提高了系统整体吞吐量和响应性。
2. 高可靠性：状态机清晰地定义了通信的每一个步骤和可能的分支（如ACK/NAK处理、错误恢复），程序逻辑严谨，不易因意外状态而跑飞。
3. 灵活性：状态机本身就是一个抽象层。通过改变状态定义和转移逻辑，同一套驱动框架可以轻松适配I2C、SMBus、甚至自定义的两线协议，只需更换状态处理函数即可。
4. 易于调试：当前通信进行到哪一步，完全由状态变量I2CRegs.State记录。在调试时，只需观察这个变量，就能对总线通信过程了如指掌，远比在多个标志位间跳转要清晰。

2.2 关键数据结构设计：一切状态的容器

程序的核心是两个全局数据结构：I2CREGS和I2CBITS。它们使用_PERSISTENT关键字修饰，确保在软件复位后数据不丢失，这对于从总线错误中恢复非常有用。

typedef struct tagI2CREGS { unsigned char State; // 运行状态编码，状态机的灵魂 unsigned char I2CAddr; // 器件地址 (如0xA0/0xA1) unsigned int RWAddr; // 器件内部读写地址 (EEPROM地址) unsigned int Count; // 运行计数器，记录已发送/接收的字节数 unsigned int TxCount; // 本次操作待发送的字节数 unsigned int RxCount; // 本次操作待接收的字节数 unsigned int MaxCount; // 器件最大容量，用于地址宽度判断 unsigned char TxBuffer[16]; // 发送缓冲区 unsigned char RxBuffer[256];// 接收缓冲区 } I2CREGS; typedef struct tagI2CBITS { union { unsigned char I2CFlag; struct { unsigned char BusyFlag: 1; // 1=总线忙，0=总线空闲 unsigned char ReadFlag: 1; // 1=激活读回调 unsigned char WriteFlag: 1; // 1=激活写回调 }; }; } I2CBITS;

设计要点解析：

• State变量：这是状态机的核心。它不仅仅记录标准I2C状态（如0x18代表主发送地址已收到ACK），还扩展了程序自定义的状态（如I2C_MT_ADDRL_ACK），用于处理多字节地址等特定流程。
• 双缓冲区设计：TxBuffer和RxBuffer分离。写操作时，用户数据填入TxBuffer；读操作时，数据从总线存入RxBuffer，用户再从RxBuffer取出。这种分离使得读写API非常清晰。
• MaxCount的作用：这是一个巧妙的设计。通过判断MaxCount是否大于256（0x100），程序可以动态决定EEPROM的地址是1字节还是2字节。例如，24LC256（32K字节）需要2字节地址，而24LC02（256字节）只需要1字节。这使驱动可以兼容不同容量的EEPROM，而无需重新编译。
• 位域结构体：I2CBITS使用位域来管理几个关键的布尔标志。BusyFlag用于防止重入（同一时间只能进行一次I2C操作），ReadFlag和WriteFlag用于在中断中安全地通知主循环“操作完成，可以处理数据了”。

2.3 PIC24F I2C模块的“个性”与应对策略

原文中作者吐槽“PIC24F的I2C不太标准”，“一点都没I2C的‘大家闺秀’的样子”。这主要指的是其状态寄存器I2C1STAT的位定义与标准I2C状态码的映射关系不那么直观，以及一些细微的行为差异。但作者也肯定了其“STOP还能激活中断”的特性，这比某些ARM或AVR芯片需要软件查询STOP完成要好。

我们的驱动策略是以我为主，抽象隔离。我们不完全依赖硬件提供的标准状态码，而是基于硬件中断和几个关键标志位（I2C1STATbits.S和I2C1STATbits.P），在自己的状态机I2CRegs.State中定义一套清晰、符合逻辑的状态流程。硬件状态寄存器仅作为触发中断和判断ACK/NACK的依据，核心逻辑完全由我们的软件状态机控制。这样，即使更换到另一款I2C外设行为略有差异的MCU，也只需调整最底层的中断标志读取部分，上层的状态机和应用API几乎可以保持不变。

3. 中断服务程序（ISR）深度剖析：事件处理的艺术

整个驱动的引擎是I2CExec()函数，它被放置在I2C主中断的服务程序中。PIC24F的中断服务程序（ISR）通常写法是void __attribute__((interrupt, no_auto_psv)) _MI2C1Interrupt(void)，并在其中调用I2CExec()。为了聚焦逻辑，我们略去编译器特性，直接分析核心。

3.1 中断触发与状态分发

I2CExec()函数一进来，首先判断是什么事件触发了中断：

void I2CExec(void) { if (I2C1STATbits.S) { // 检测到START或ReSTART条件 // 处理发送/接收过程中的各种状态 switch (I2CRegs.State) { // ... 各个状态的处理 } } else if (I2C1STATbits.P) { // 检测到STOP条件 // 通信结束，处理成功回调 if (I2CRegs.State == I2C_SUCCEEDED) { if (I2CRegs.I2CAddr & 1) // 最低位为1表示读 I2CBits.ReadFlag = 1; else I2CBits.WriteFlag = 1; } } else { // 无法识别的状态，按错误处理 I2cExit(); } }

这里体现了两个关键点：

1. 事件分类：I2C通信的核心事件就是START/ReSTART和STOP。S标志位置位，意味着总线进入了“数据传输阶段”，需要根据我们预设的状态机一步步推进。P标志位置位，意味着一次完整的事务（可能包含多次START/STOP）结束了，是时候进行“后处理”（如调用用户回调）。
2. 状态验证：在STOP中断里，并不是无脑认为操作成功。它检查I2CRegs.State == I2C_SUCCEEDED，只有状态机最终走到了成功状态，才会置位完成标志。这防止了通信中途出错（调用了I2cExit()发送STOP）也被误认为成功。

3.2 主发送（Master Transmitter）流程详解

我们以一次完整的EEPROM“写操作”为例，跟踪状态机的流转。假设我们要向地址0x0100写入2个字节{0xAA, 0x55}。

1. 用户调用I2CWriteBuffers(0x0100, 2)，并填充TxBuffer。

2. 状态I2C_START(0x08)：I2cStart()函数设置状态为I2C_START，并置位SEN启动START条件。当中断发生，进入I2CExec()，S标志为真，进入switch。

   case I2C_START: I2C1TRN = I2CRegs.I2CAddr & 0xfe; // 发送写地址(0xA0) I2CRegs.State = I2C_MT_SLA_ACK; // 下一个状态：等待地址ACK break;

   这里I2CRegs.I2CAddr在初始化时被设为0xA0，& 0xfe是为了确保最低位（R/W位）为0，表示写操作。

3. 状态I2C_MT_SLA_ACK(0x18)：当从机（EEPROM）回应ACK后，再次进入中断。

   case I2C_MT_SLA_ACK: if (!I2C1STATbits.ACKSTAT) { // 收到ACK if (I2CRegs.MaxCount > 0x100) { // 需要2字节地址 I2C1TRN = I2CRegs.RWAddr >> 8; // 发送高8位地址(0x01) I2CRegs.State = I2C_MT_ADDRH_ACK; } else { // 1字节地址 I2C1TRN = I2CRegs.RWAddr; // 发送地址(对于小容量) I2CRegs.State = I2C_MT_ADDRL_ACK; I2CRegs.Count = 0; // 清空发送字节计数器 } } else { // 收到NACK，从机无应答 I2cExit(); // 触发错误处理 } break;

   关键细节：I2CRegs.Count在发送地址后清零，为后续发送数据字节做准备。I2cExit()函数会发送STOP条件，并将状态置为I2C_FAILED，同时置高WP引脚（如果连接了写保护）以保护EEPROM。

4. 状态I2C_MT_ADDRH_ACK(0x3a) 和I2C_MT_ADDRL_ACK(0x3b)：这两个是自定义状态，用于处理两字节地址的ACK。流程类似，发送地址低字节，并最终进入I2C_MT_ADDRL_ACK状态。在I2C_MT_ADDRL_ACK状态中，有一个至关重要的操作：

   case I2C_MT_ADDRL_ACK: if (I2CRegs.TxCount) { // 如果有数据要写 WP = 0; // 解除EEPROM的写保护！ } // 注意：这里没有break！会继续执行下一个case case I2C_MT_DATA_ACK: if (!I2C1STATbits.ACKSTAT) { if (I2CRegs.Count < I2CRegs.TxCount) { I2C1TRN = I2CRegs.TxBuffer[I2CRegs.Count++]; } else if (I2CRegs.Count == I2CRegs.TxCount) { I2cStop(); // 所有数据发送完毕，结束 } else { I2cExit(); // 计数器异常，错误处理 } } else { I2cExit(); // 数据未被ACK，可能写保护生效 } break;

   精妙之处：

   • 写保护时机：写保护（WP = 0）的时机是在收到地址低字节ACK之后，即将发送第一个数据字节之前。这是最安全、最精准的时机。过早解除保护，可能在寻址阶段误写入；过晚解除，可能错过数据写入窗口。这体现了作者对硬件时序的深刻理解。
   • case的穿透（Fall-through）：I2C_MT_ADDRL_ACK状态后没有break，会直接执行I2C_MT_DATA_ACK的代码。这是因为在发送完地址后，无论是收到地址ACK还是数据ACK，MCU需要执行的动作逻辑是相似的：判断是否还有数据要发送。这种写法精简了代码。

5. 状态I2C_MT_DATA_ACK(0x28)：每成功发送一个数据字节并收到ACK，就会进入这个状态。I2CRegs.Count递增，直到等于I2CRegs.TxCount，然后调用I2cStop()。

6. 结束与回调：I2cStop()函数发送STOP条件，并将状态设为I2C_SUCCEEDED。当STOP条件在总线上产生后，硬件会再次触发中断，此时I2C1STATbits.P为真。在I2CExec()的STOP处理分支中，由于状态是成功的，且本次是写操作（I2CRegs.I2CAddr最低位为0），所以置位I2CBits.WriteFlag。注意：用户回调函数I2CWriteCallBack()并不是在中断中直接调用的，而是通过置位一个标志，由主循环查询并调用。这是中断服务程序设计的黄金法则：快进快出。在ISR中只做最紧急、最简单的操作（操作硬件寄存器、更新状态和标志），复杂的逻辑（如处理接收到的数据）放到主循环中。

3.3 主接收（Master Receiver）流程与“ReSTART”的运用

读操作比写操作多一个步骤：先发送写地址告知EEPROM要读的内部地址，然后发送一个ReSTART信号，再发送读地址开始接收数据。这就是所谓的“复合格式”。

1. 用户调用I2CReadBuffers(0x0100, 10)，希望从地址0x0100读取10个字节。

2. 前几个状态（I2C_START,I2C_MT_SLA_ACK,I2C_MT_ADDRH_ACK,I2C_MT_ADDRL_ACK）与写操作完全相同，目的是将读指针设置到EEPROM的0x0100地址。

3. 关键区别在I2C_MT_DATA_ACK状态中，当发送计数器I2CRegs.Count等于I2CRegs.TxCount时（注意，对于纯读操作，TxCount为0，所以这个条件在发送完地址后立即满足）：

   if (I2CRegs.I2CAddr & 1) { // 如果本次操作的最终目标是读 I2cReStart(); // 发送ReSTART信号 }

   I2cReStart()函数将状态设置为I2C_REP_START，并置位RSEN位。

4. 状态I2C_REP_START(0x10)：ReSTART信号发送完成后，进入此状态。

   case I2C_REP_START: I2C1TRN = I2CRegs.I2CAddr | I2C_READ; // 发送读地址(0xA1) I2CRegs.State = I2C_MR_SLA_ACK; break;

   这里I2C_READ定义为1，所以I2CRegs.I2CAddr | 1的结果就是0xA1，表示读操作。

5. 后续进入主接收状态流（I2C_MR_SLA_ACK,I2C_MR_DATA,I2C_MR_DATA_EN,I2C_MR_DATA_STOP）。接收数据时，需要先使能接收（RCEN=1），读取数据寄存器（I2C1RCV）后，根据是否还要接收更多数据，发送ACK或NACK给从机。

   case I2C_MR_DATA: if (I2CRegs.Count < I2CRegs.RxCount) { I2CRegs.RxBuffer[I2CRegs.Count++] = I2C1RCV; // 保存数据 if (I2CRegs.Count < I2CRegs.RxCount) { I2C1CONbits.ACKDT = 0; // 发送ACK，要求继续读 I2CRegs.State = I2C_MR_DATA_EN; } else { I2C1CONbits.ACKDT = 1; // 发送NACK，告知从机这是最后一个字节 I2CRegs.State = I2C_MR_DATA_STOP; } I2C1CONbits.ACKEN = 1; // 启动发送(非)应答位 } break; case I2C_MR_DATA_EN: I2C1CONbits.RCEN = 1; // 使能接收下一个字节 I2CRegs.State = I2C_MR_DATA; break;

   这个流程清晰地展示了“接收一个字节 -> 回应ACK/NACK -> 准备接收下一个字节”的循环，直到接收完所需数量的字节，最后发送STOP条件，并置位ReadFlag。

4. 实战要点、避坑指南与高级技巧

4.1 硬件连接与初始化细节

1. 开漏输出与上拉电阻：I2C总线要求SDA和SCL线为“线与”逻辑，必须使用开漏输出模式，并外接上拉电阻（通常4.7kΩ）。代码中ODC_SCL1 = 1;和ODC_SDA1 = 1;就是将这两个引脚配置为开漏输出。务必在硬件上连接上拉电阻，否则总线无法拉高。
2. 波特率计算：I2C1BRG = (FCY / (2 * I2CBAUD)) - 1;。FCY是指令周期频率（Fosc/2），I2CBAUD是期望的I2C时钟频率。例如，FCY=16MHz，想要400kHz的I2C时钟，则I2C1BRG = (16,000,000 / (2 * 400,000)) - 1 = 19。注意：实际波特率可能会有误差，在高速（如1MHz）或长距离布线时需特别关注波形。
3. 写保护（WP）引脚：很多EEPROM芯片（如24LC系列）都有一个WP引脚，接高电平时禁止写入，接低电平允许写入。代码中将其作为一个普通GPIO控制。最佳实践是像本驱动一样，仅在发送数据前极短的时间内拉低WP，操作完成后立即拉高，最大限度防止意外写入。

4.2 中断优先级与重入保护

IPC4bits.MI2C1P0 = 1; IPC4bits.MI2C1P1 = 1; IPC4bits.MI2C1P2 = 1; _MI2C1IE = 1;

这里将主I2C中断优先级设为最高（7）。对于I2C这种实时性要求高的外设，建议设置为较高优先级，避免被其他长时间的中断阻塞，导致总线超时。同时，I2CBits.BusyFlag提供了简单的软件重入保护。在I2cStart()中会置位该标志，在I2cStop()或I2cExit()中清零。用户调用读写函数前，可以检查此标志，防止在上一次操作未完成时启动新的操作。

4.3 错误处理与总线恢复

I2cExit()函数是错误处理的中心。在任何状态中检测到NACK、计数器异常或未知状态，都会调用它。它的职责是：

1. 发送STOP条件，尝试将总线恢复到空闲状态。
2. 置高WP引脚，保护EEPROM。
3. 将状态设置为I2C_FAILED，并清除BusyFlag。 一个健壮的系统应该在主循环中监控操作完成标志（ReadFlag/WriteFlag）的同时，也检查BusyFlag是否在合理时间内被清除。如果BusyFlag长时间为1，可能意味着总线已挂死，需要更激进的总线恢复程序（例如，尝试连续发送多个STOP条件，或者临时将SDA、SCL配置为GPIO输出低电平再释放）。

4.4 从“I2C驱动”到“SMBus协议栈”

本驱动被作者称为“通用的I2C/SMBUS通讯中断处理程序”。其扩展性就体现在状态机的抽象和回调函数的设计上。要支持SMBus，主要需做以下扩展：

1. 命令字：将I2CRegs.RWAddr字段的含义扩展为“命令字（Command）”。
2. PEC校验：SMBus的Packet Error Checking需要发送/接收一个额外的CRC8字节。可以在发送/接收缓冲区末尾预留位置，在状态机中增加处理PEC字节的状态。
3. 超时管理：SMBus协议有严格的超时规定（如35ms的bus timeout）。需要在状态机中集成一个硬件定时器，在每次状态转移时重置超时计数器，若超时则调用I2cExit()。
4. 协议回调：可以定义更丰富的回调函数，例如SMBusAlertCallBack()、TimeoutCallBack()等，通过I2CBITS中的标志位来触发。

4.5 与“老外倒塌的非中断状态机”程序对比

原文附带的i2cEmem.c是一个典型的状态机轮询实现。它有一个大的switch-case，在一个被主循环频繁调用的函数I2CEMEMdrv()中执行。其状态变量是函数内的静态变量，通过检查一个全局标志jDone（在中断中置位）来判断硬件操作是否完成。

两种模式的本质区别：

• 本驱动（中断驱动）：硬件事件主动通知CPU，CPU立即响应，状态机在中断上下文推进。优势：响应极快，CPU利用率高，等待时间可被用于处理其他任务。劣势：中断上下文编程需谨慎，不能有阻塞操作。
• 老外程序（轮询状态机）：CPU主动查询硬件状态，在主循环中逐步推进状态机。优势：程序流程全部在主循环，简单直观，没有中断嵌套的复杂性。劣势：CPU大量时间浪费在等待上，或者需要复杂的超时机制，系统实时性差。

对于现代强调效率和实时性的嵌入式系统，中断驱动无疑是更优的选择。本驱动将两者的优点结合：用中断保证实时响应，用状态机保证逻辑清晰，用标志位进行中断与主循环的通信，架构非常经典。

5. 移植与适配到其他MCU平台的思考

这套驱动框架的价值在于其思想，而非局限于PIC24F。将其移植到STM32、GD32、ESP32等平台，需要关注以下几点：

1. 硬件抽象层（HAL）接口：将PIC24F特有的寄存器操作（如I2C1CONbits.SEN = 1;）封装成独立的函数，例如I2C_GenerateSTART()、I2C_SendData()、I2C_GetFlagStatus()。驱动核心的状态机I2CExec()则调用这些抽象函数。
2. 中断事件映射：不同MCU的I2C中断事件可能不同。有的可能将TXE（发送寄存器空）、RXNE（接收寄存器非空）、STOPF等分为不同中断。你需要分析，哪些事件需要触发状态机推进。通常，将“地址发送完成”、“数据字节发送完成”、“数据字节接收完成”、“STOP检测”这几个事件映射到中断即可。
3. 状态码定义：标准I2C状态码（如0x08, 0x18, 0x28等）是通用的，可以保留。自定义的状态（如I2C_MT_ADDRL_ACK）可能需要根据新平台的中断事件精细调整。
4. 时钟与延时：不同MCU的指令速度和外设时钟不同，初始化时的波特率计算和中断服务程序中的简短延时（如果需要）需要调整。

移植的过程，正是深入理解目标平台I2C外设和巩固“事件驱动状态机”这一设计模式的最佳实践。当你成功地将这套框架移植到新的平台后，你会发现，以后面对任何I2C器件，编写驱动都将变得有章可循，从容不迫。