做小批量设备这几年I2C通信这块我一直绕不开。早期项目里用的是轮询方式两块GD32F30x之间跑I2C调试阶段看着挺稳一上现场就露馅主控在等待从机应答的时候把整个系统拖住按键扫描、显示刷新全跟着卡顿更头疼的是偶发数据错位排查起来极其难受。后来彻底改成中断通信把主机和从机的数据交换状态机全部搬到中断里跑才算把这个问题根治。这篇文章就把整个改造过程、踩过的坑、以及一套可以直接抄作业的主从机中断通信方案完整写出来。先说清楚这篇文章适合谁看正在用GD32系列做产品、手里的I2C通信还在用轮询或者半中断半轮询、想彻底理顺主机和从机数据交换的朋友。看完你会知道GD32的I2C中断机制和STM32有什么本质区别、主机发送和接收时该怎么设计中断状态机、从机怎么应对主机的读写请求、以及调试I2C中断问题时最实用的定位手段。1. 整体设计与选型思路为什么必须上中断1.1 轮询方式在现场暴露的真实问题我在第一版方案里用的是最常规的阻塞式轮询。发送一个字节后死等TBE标志接收数据时死等RBNE标志每次传输结束后再等STOP条件完成。这套逻辑在单任务裸机环境下看起来没什么问题但放到真实的设备里就暴露出三个很实际的毛病。第一个是CPU利用率被无效占用。I2C时钟跑400kHz的时候单个字节传输大概需要20多微秒一帧数据十几二十个字节再加上从机处理和应答时间一次完整通信动辄几百微秒到一毫秒。这个过程中主控什么都干不了只能干等标志位翻转。如果你的系统里还有显示刷新、按键扫描、传感器采集这些实时任务时间片被I2C这么一占整体响应就变得黏黏糊糊。第二个是错位问题。轮询模式下如果从机响应慢或者I2C总线上出现一个意外的干扰脉冲状态机很容易跑飞。比如主机发了地址之后从机因为内部处理来不及响应NACK主机的轮询代码还在傻等ADDSEND标志等不到就一直卡死没有任何超时保护最后只能看门狗复位。我在现场就遇到过一次设备每隔几小时死一次最后定位就是I2C等待超时。第三个是扩展性差。后面想在这个I2C总线上再挂一个从机或者增加通信频率轮询代码几乎要重写。中断方案的状态机天然就是按事件拆分的加设备、改协议都只需要调整中断处理逻辑维护成本低很多。1.2 轮询、DMA、中断三种方案怎么选很多人一听高效数据交换第一反应就是上DMA。确实DMA在批量数据传输的时候能把CPU彻底解放出来但I2C的DMA和SPI、UART的DMA不是一个难度等级。I2C和SPI、UART最关键的区别在于SPI和UART的收发双方都有独立的时钟或帧同步机制主机只管往外扔数据就行。I2C不一样它是半双工、带应答机制的总线每个字节传输的节奏由从机的ACK/NACK控制。这意味着DMA在做I2C传输时必须时刻关注总线状态数据传完一个字节后下一拍该发什么得由I2C外设自己根据从机的应答情况来决定。GD32的I2C DMA模式下你依然要处理地址发送、应答控制、停止条件这些状态DMA只是帮你搬数据状态机的复杂度一点没减。DMA适合的场景是一次传输数据量很大比如几十上百字节且双方配合默契、不需要频繁处理异常情况。如果你的数据帧通常只有几个字节比如传感器读取、寄存器配置这类DMA带来的收益非常有限反而因为DMA中断、缓冲区管理增加了代码复杂度。中断方案是中间态每个I2C事件起始、地址、字节传输、停止都会触发中断在中断里判断下一步该干什么。它的状态机是事件驱动的CPU不再空转等待传输过程中可以去处理其他任务。虽然每个字节仍会触发中断、有一点开销但对多数应用来说这个开销完全可接受。我最终选中断方案的直接原因是GD32的I2C外设本身在设计上很适合事件驱动模型它在每个关键节点都会产生独立中断标志只要把状态机理清楚代码会很自然地从轮询改造成中断。而且中断方案对系统的侵入性比DMA小调试方便出了问题用逻辑分析仪一抓就能对上中断时序。1.3 方案架构与模块划分整套方案的架构其实不复杂硬要说核心就是一句话用查表法实现一个可复用的I2C中断状态机。整个模块我拆成四层底层GD32标准库的I2C外设驱动负责寄存器读写、时钟配置、引脚复用。中间层I2C中断处理函数这是整个方案的心脏。主机侧和从机侧各一套状态机分别处理收发流程。应用层业务代码通过一组API发起I2C通信比如I2C_ReadSensorData(slave_addr, reg_addr, buffer, len)发起后函数立即返回通信结果通过回调或者标志位通知。调度层系统主循环或者定时器轮询通信完成标志一旦完成后取走数据。这个架构的好处是业务逻辑和通信细节彻底解耦。主程序只需要关心数据有没有拿到而不用关心I2C总线上发生了什么。2. GD32 I2C外设机制与关键差异2.1 GD32和STM32的I2C外设差异移植前必须知道很多从STM32转过来的朋友第一反应就是把STM32的I2C代码搬过来改改引脚和时钟。如果你这么干过大概率会碰上一些很诡异的现象中断乱触发、状态机卡死、偶尔正常偶尔跑飞。这不是你代码写错了而是GD32的I2C外设和STM32在中断事件模型上有本质差异。STM32的I2C中断事件是分EV5、EV6、EV8、EV9这种事件号的每个事件号对应一个固定的处理时机网上资料和库函数封装都按这个事件号来。很多人在STM32上写I2C中断其实是按事件号的套路在写。GD32沿用了类似的寄存器结构但中断标志位的组合和触发时机并不完全相同尤其是地址发送完成ADDSEND的清除方式、字节传输完成BTC事件的处理顺序、以及从机停止条件STPDET的响应都和STM32有差异。举个例子GD32F30x的ADDSEND标志在主机模式下是地址方向位发送完成等待应答从机模式下是从机地址匹配。这个标志的清除手册上要求读STAT0再读STAT1但库函数封装成了i2c_interrupt_flag_clear(I2Cx, I2C_INT_FLAG_ADDSEND)。如果你按STM32习惯在ADDSEND里读一下SR1再读SR2来清标志GD32上多半也能工作但如果你的库版本较老或者引脚配置有差异会出现标志清了但状态机没往前走的问题。更关键的是中断标志优先级。GD32的I2C中断里如果同时出现了多个事件标志你判断的顺序必须是SBSEND - ADDSEND - TBE/RBNE - BTC —— 这个顺序不能乱。最典型的坑是主机发送数据时地址发送完成ADDSEND和发送缓冲空TBE会先后到来如果你先判断TBE很可能在地址阶段就误认为数据需要发送结果把第一个数据字节当成地址发出去总线直接被拉死。2.2 中断标志位与事件处理顺序GD32F30x的I2C有两个中断向量事件中断EV和错误中断ER。所有正常通信事件都在EV中断里处理总线错误、仲裁丢失、应答失败、过载这四类错误走ER中断。现在把EV中断里最常见的几个标志位按照必须的判断顺序列出来SBSEND起始条件已发送。主机模式下进入下一次动作的入口。主机发出START后这个标志置位此时应该发送从机地址方向位。ADDSEND地址已发送主机模式或地址匹配从机模式。此时说明从机已应答地址下一步根据读写方向决定是发数据还是准备收数据。TBE发送数据寄存器空。表示可以往数据寄存器写下一个字节。注意和BTC字节传输完成区分TBE是你还没开始传这一步BTC是这一步传完了。RBNE接收数据寄存器非空。表示收到一个字节必须尽快读走否则下一字节会覆盖。BTC字节传输完成。多字节传输中建议用它来做一字节结束的边界标记尤其是接收方向配合ACK控制非常关键。STPDET停止条件检测。从机模式下主机发送STOP后置位从机必须软件清除。判断顺序上我的经验是SBSEND 最先ADDSEND 次之然后是 TBE/RBNE最后 BTC。ADDSEND和TBE同时置位的情况确实会出现先处理ADDSEND能确保地址阶段不吞掉第一个数据字节。还有一个坑是关于清除ADDSEND。GD32的库函数确实提供了清除接口但有些型号和早期的库版本里ADDSEND只能用读STAT0再读STAT1的方式清除。如果你在中断里既想用库函数清除又想读寄存器判断方向顺序要理清楚先读方向标志再清除ADDSEND。否则一旦清了状态信息就丢了。2.3 时序配置与参数计算GD32的I2C时钟配置需要两个参数通信速率和占空比。以400kHz快速模式为例标准库函数用法如下i2c_clock_config(I2C0, 400000, I2C_DTCY_2);这个设置的背后是I2C时钟发生器自动根据APB1总线时钟计算分频值。GD32F30x的APB1时钟最高到54MHz如果你跑的APB1不是标准值就需要手动确认库函数计算出来的分频是否正确。判断方法很简单用示波器抓SCL引脚看高电平时间是否正常。我在一个板子上APB1配错成72MHzI2C时钟配置函数按54MHz算的结果SCL频率偏高不少从机直接不响应。上拉电阻的取值也值得说一句。GD32的数据手册对I2C引脚的上拉电流有推荐范围400kHz模式下常见用4.7k欧姆上拉电阻总线电容大一些的场合可以换2.2k。很多人忽略了一个细节I2C引脚必须配置成开漏复用模式GPIO_MODE_AF_OD如果你不小心配置成推挽复用低电平没问题高电平被引脚硬拉从机识别不到正确的电平变化总线根本跑不起来。3. 主机模式I2C中断通信的实现3.1 主机初始化与中断配置主机初始化里除了常规的时钟、引脚、速率配置还有一个经常被忽略的点I2C外设使能的时机。必须在所有参数配置完成后最后再调用i2c_enable否则未配置完成就上总线可能产生一个意外的STOP条件干扰总线上的其他从机。下面是我在GD32F30x上的主机初始化代码基于标准库编写void i2c_master_init(void) { /* 开启GPIO和I2C时钟 */ rcu_periph_clock_enable(RCU_GPIOB); rcu_periph_clock_enable(RCU_AF); rcu_periph_clock_enable(RCU_I2C0); /* I2C引脚复用开漏模式 */ gpio_init(GPIOB, GPIO_MODE_AF_OD, GPIO_OSPEED_50MHZ, GPIO_PIN_6 | GPIO_PIN_7); gpio_pin_remap_config(GPIO_I2C0_REMAP, DISABLE); /* 默认引脚不用重映射 */ /* I2C外设复位确保初始状态干净 */ i2c_software_reset_enable(I2C0); i2c_software_reset_disable(I2C0); /* 配置为400kHz快速模式 */ i2c_clock_config(I2C0, 400000, I2C_DTCY_2); i2c_enable(I2C0); /* 使能事件和错误中断 */ i2c_interrupt_enable(I2C0, I2C_INT_ERR | I2C_INT_BUF | I2C_INT_EV); /* NVIC配置抢占优先级2子优先级0 */ nvic_irq_enable(I2C0_EV_IRQn, 2, 0); nvic_irq_enable(I2C0_ER_IRQn, 2, 0); }注意这里我特意加了一步软件复位。GD32上电后I2C外设状态不确定尤其如果之前跑过其他测试代码外设可能停在某个异常状态。软件复位一下能保证后续中断状态机从干净状态起步。3.2 主机发送中断状态机拆解主机发送一帧数据的中断状态机是整个I2C中断方案的基础理解了它接收方向就顺理成章。发送流程定义为一个简单的状态机空闲 - 起始 - 地址 - 数据... - 停止。用代码来描述这个状态机最直接volatile uint8_t i2c_tx_buffer[32]; volatile uint16_t i2c_tx_len; volatile uint16_t i2c_tx_count; volatile uint8_t i2c_tx_busy; volatile uint8_t i2c_tx_ok; void i2c_master_send_data(uint8_t slave_addr, uint8_t* buf, uint16_t len) { while(i2c_tx_busy); /* 等待上次传输完成 */ memcpy((uint8_t*)i2c_tx_buffer, buf, len); i2c_tx_len len; i2c_tx_count 0; i2c_tx_busy 1; i2c_tx_ok 0; i2c_start_on_bus(I2C0); /* 发起START触发SBSEND中断 */ } void I2C0_EV_IRQHandler(void) { /* 1. 处理起始条件已经发送 */ if(i2c_interrupt_flag_get(I2C0, I2C_INT_FLAG_SBSEND)) { i2c_data_send(I2C0, (slave_addr 1) | 0); /* 发送从机地址写位 */ } /* 2. 处理地址已经发送 */ else if(i2c_interrupt_flag_get(I2C0, I2C_INT_FLAG_ADDSEND)) { i2c_interrupt_flag_clear(I2C0, I2C_INT_FLAG_ADDSEND); /* 地址阶段已过如果还有数据要发直接发第一个字节 */ if(i2c_tx_count i2c_tx_len) { i2c_data_send(I2C0, i2c_tx_buffer[i2c_tx_count]); } else { i2c_stop_on_bus(I2C0); } } /* 3. 处理发送缓冲空 */ else if(i2c_interrupt_flag_get(I2C0, I2C_INT_FLAG_TBE)) { if(i2c_tx_count i2c_tx_len) { i2c_data_send(I2C0, i2c_tx_buffer[i2c_tx_count]); } else { i2c_stop_on_bus(I2C0); } } }这段代码里有一个关键细节ADDSEND处理完第一个字节后后续字节的发送由TBE驱动。因为每次往数据寄存器写完一个字节后硬件把数据移位发送出去发送寄存器空后TBE再次置位于是中断再次进来不断把缓冲区的数据发出去。当所有字节发完后下一次TBE中断里就会执行停止条件。为什么要在TBE里发数据而不是在BTC里因为TBE表示你赶紧把下一个字节填进来而BTC表示这个字节已经传完了。TBE的节奏更早一步让总线没有空闲等待。如果用BTC驱动每发完一个字节后到下个字节写入之间会有一段空窗在400kHz快速模式下会导致实际的帧间隔变长严格要求的从机可能判定超时。3.3 主机接收中断状态机与应答控制细节接收方向比发送方向麻烦得多因为涉及ACK/NACK控制。I2C协议里接收方每收完一个字节都必须回复一个ACK只有最后一个字节可以回复NACK告诉对端别发了。这个NACK的时机如果控制错要么多读一个字节要么少读一个字节。先给结论要读取N个字节N2正确流程是——在收到倒数第2个字节时关闭ACK在收到最后一个字节时读取数据并发STOP。用代码实现volatile uint8_t i2c_rx_buffer[32]; volatile uint16_t i2c_rx_len; volatile uint16_t i2c_rx_count; volatile uint8_t i2c_rx_busy; volatile uint8_t i2c_rx_ok; void i2c_master_read_data(uint8_t slave_addr, uint8_t* buf, uint16_t len) { while(i2c_rx_busy); i2c_rx_len len; i2c_rx_count 0; i2c_rx_busy 1; i2c_rx_ok 0; i2c_ack_enable(I2C0); /* 开启应答 */ i2c_start_on_bus(I2C0); /* 发起START */ } void I2C0_EV_IRQHandler(void) { /* 起始条件已发送 */ if(i2c_interrupt_flag_get(I2C0, I2C_INT_FLAG_SBSEND)) { i2c_data_send(I2C0, (slave_addr 1) | 1); /* 从机地址读位 */ } /* 地址已发送进入接收准备 */ else if(i2c_interrupt_flag_get(I2C0, I2C_INT_FLAG_ADDSEND)) { i2c_interrupt_flag_clear(I2C0, I2C_INT_FLAG_ADDSEND); i2c_rx_count 0; /* 如果只读1个字节要在读之前就关ACK并且准备好读完后发STOP */ if(i2c_rx_len 1) { i2c_ack_disable(I2C0); } } /* 接收缓冲非空 */ else if(i2c_interrupt_flag_get(I2C0, I2C_INT_FLAG_RBNE)) { if(i2c_rx_count i2c_rx_len - 2) { /* 收倒数第2个字节关ACK然后读走数据 */ i2c_rx_buffer[i2c_rx_count] i2c_data_receive(I2C0); i2c_ack_disable(I2C0); } else if(i2c_rx_count i2c_rx_len - 1) { /* 收最后一个字节读走数据后立即发STOP */ i2c_rx_buffer[i2c_rx_count] i2c_data_receive(I2C0); i2c_stop_on_bus(I2C0); i2c_rx_busy 0; i2c_rx_ok 1; } else { i2c_rx_buffer[i2c_rx_count] i2c_data_receive(I2C0); } } }这里有个容易踩的坑如果一次只读一个字节必须在ADDSEND阶段就把ACK关掉。否则从机发送完这个字节后主机因为ACK还开着从机会继续发送下一个字节结果主机不得不多读一个字节再丢调。这种问题用逻辑分析仪看波形特别清楚但排查起来很费劲。另一个坑是STOP发完后的处理。i2c_stop_on_bus只是把停止条件写入控制寄存器硬件实际完成STOP是在几个时钟周期之后。如果主程序马上发起下一次通信可能和STOP时序撞车。所以我在代码里用一个busy标志主程序发起新传输前必须先轮询busy确保上一次传输彻底结束。4. 从机模式I2C中断通信的实现4.1 从机初始化的几个关键点从机初始化和主机最大的不同在于从机不需要主动发起通信只需要把地址匹配和中断准备好剩下的就是等总线上的事件。void i2c_slave_init(uint8_t slave_addr) { rcu_periph_clock_enable(RCU_GPIOB); rcu_periph_clock_enable(RCU_AF); rcu_periph_clock_enable(RCU_I2C1); gpio_init(GPIOB, GPIO_MODE_AF_OD, GPIO_OSPEED_50MHZ, GPIO_PIN_10 | GPIO_PIN_11); i2c_software_reset_enable(I2C1); i2c_software_reset_disable(I2C1); i2c_clock_config(I2C1, 400000, I2C_DTCY_2); i2c_enable(I2C1); /* 配置从机地址 */ i2c_slave_addr_config(I2C1, slave_addr); /* 使能中断 */ i2c_interrupt_enable(I2C1, I2C_INT_ERR | I2C_INT_BUF | I2C_INT_EV); nvic_irq_enable(I2C1_EV_IRQn, 2, 0); nvic_irq_enable(I2C1_ER_IRQn, 2, 0); }这里有个配置顺序问题先使能I2C还是先配从机地址我的经验是先使能I2C再配地址。反过来配置虽然也能工作但在某些GD32型号上有概率出现地址寄存器被外设状态机覆盖的情况导致从机永远匹配不上地址。虽然概率极低但这种问题一旦发生极其隐蔽不如从配置顺序上直接规避。从机地址的位数取决于你是7位地址还是10位地址模式。GD32默认是7位地址模式i2c_slave_addr_config的标准用法传的是7位地址。如果你用10位地址需要额外配置头地址寄存器。多数应用场景7位地址足够了一条总线上挂多个不同地址的从机也没问题。还有一个容易被忽视的配置从机能否响应广播地址0x00。GD32外设有对应的寄存器位控制应答广播地址。如果产品上不需要广播保持默认关闭就行否则总线上别的主机一旦发广播你的从机会被误触发。4.2 从机接收中断处理与主机读写方向判断从机的中断处理看起来和主机很像但内部逻辑有不少差异。从机模式下中断标志的触发不是由本地发起的总线事件决定的而是由总线上主机发起的操作决定的。收到起始条件后紧接着就是地址匹配事件ADDSEND此时必须分辨主机到底想读还是想写。读方向的判断在GD32里很简单地址匹配后读取STAT0寄存器的最低有效位1表示主机要读0表示主机要写。标准库提供了封装函数i2c_slave_rw_get()用起来更直观。下面是从机接收和发送合在一起的完整中断处理void I2C1_EV_IRQHandler(void) { if(i2c_interrupt_flag_get(I2C1, I2C_INT_FLAG_ADDSEND)) { /* 先判断方向再清除ADDSEND标志 */ if(i2c_slave_rw_get(I2C1)) { /* 主机要读从机进入发送模式 */ i2c_tx_count 0; /* 发送缓冲区准备好后第一个字节在后续TBE里发 */ } else { /* 主机要写从机进入接收模式 */ i2c_rx_count 0; } i2c_interrupt_flag_clear(I2C1, I2C_INT_FLAG_ADDSEND); } else if(i2c_interrupt_flag_get(I2C1, I2C_INT_FLAG_RBNE)) { /* 主机写入的数据到达读走并保存 */ if(i2c_rx_count RX_BUF_SIZE) { i2c_rx_buffer[i2c_rx_count] i2c_data_receive(I2C1); } else { i2c_data_receive(I2C1); /* 缓冲满了就丢弃多余字节 */ } } else if(i2c_interrupt_flag_get(I2C1, I2C_INT_FLAG_TBE)) { /* 主机读取时主机每读走一个字节就会触发一次TBE */ if(i2c_tx_count i2c_tx_len) { i2c_data_send(I2C1, i2c_tx_buffer[i2c_tx_count]); } else { /* 已无数据发送0xFF作为占位实际上主机不会读走 */ i2c_data_send(I2C1, 0xFF); } } else if(i2c_interrupt_flag_get(I2C1, I2C_INT_FLAG_STPDET)) { /* 主机发送STOP一帧传输结束 */ i2c_interrupt_flag_clear(I2C1, I2C_INT_FLAG_STPDET); i2c_rx_len i2c_rx_count; i2c_frame_complete 1; } }这里最需要注意的是清除ADDSEND之前就要判断读写方向。ADDSEND标志一旦被清除部分寄存器的方向状态位可能会被更新再去读方向就不准了。GD32的库函数i2c_slave_rw_get读的是STAT0寄存器的当前状态虽然实际测试中清除标志后再读也大概率正确但从严谨角度先判断再清除是最稳妥的写法。4.3 从机发送数据地址匹配后的数据回传从机发送方向的触发逻辑和主机发送完全不同。主机发送是主动往数据寄存器塞数据从机发送是被动的主机发起读操作后从机必须先往数据寄存器写入第一个字节然后等待主机的时钟脉冲把这个字节搬走搬走之后TBE置位再写下一个字节。所以从机发送里有一个预装载的概念在地址匹配中断里就要先把第一个字节准备好。如果你等到TBE了再写第一个字节主机已经在那等着了总线会无谓地延长等待时间极端情况下可能触发主机的超时判断。上面代码里我没有在ADDSEND阶段直接发送第一个字节而是用TxCount0做了一个延时思路。更严谨的做法是在ADDSEND里、清除标志之后立刻发送第一个字节if(i2c_slave_rw_get(I2C1)) { i2c_tx_count 1; /* 表示第一个字节已经预装 */ i2c_data_send(I2C1, i2c_tx_buffer[0]); }然后TBE中断里从i2c_tx_buffer[1]开始继续发。这样主机端从发出读地址到收到第一个数据字节之间的间隔最短总线上不会出现无谓的空闲期。从机发送时如果主机中途读了几个字节就提前发STOP从机的TBE还是会照常触发。这种情况下如果我的发送缓冲区已经清空就需要往数据寄存器写一个占位字节0xFF否则TBE一直置位中断会一直触发形成中断风暴。这是从机代码里一个非常隐蔽的坑。4.4 从机状态复位设计从机还会遇到一个主机侧不常见的问题总线异常时从机自己停不下来。比如主机在传输中途突然复位了从机还在等着下一个数据字节此时总线上既没有时钟也没有停止条件从机的I2C状态机就僵在那里直到下一个有效START到来。这个场景的应对策略不能只靠I2C外设本身需要软件干预。我常用的办法是开一个定时器周期检查从机状态如果从机处于传输中状态但总线上已经超过某段时间没有变化比如2ms没有新的中断触发那就认为主机已经放弃本次传输手动复位从机外设I2C软件复位、重新初始化把内部缓冲区和状态变量清空。void i2c_slave_watchdog_check(void) { if(i2c_rx_busy || i2c_tx_busy) { if(timer_elapsed(last_i2c_event_time) 2) { /* 单位ms */ i2c_software_reset_enable(I2C1); i2c_software_reset_disable(I2C1); i2c_enable(I2C1); i2c_rx_busy 0; i2c_tx_busy 0; } } }从机复位后I2C外设会重新监听总线地址主机如果重试通信从机就能正常响应。这个看门狗方案我在两个项目里都加了效果非常稳定算是从机代码里的必备组件。5. 双机高效数据交换完整实战5.1 项目场景与协议约定用一个实际场景来串起整个方案一块主控板GD32F303I2C0作为主机要周期性读取一块传感器板GD32F103I2C1作为从机的采集数据。传感器板上有三个16位传感器值一共6字节同时主控板需要下发1个字节的配置命令比如修改采样率。通信协议我做了最简封装主机写1个寄存器地址字节表示接下来要操作哪个寄存器。主机发START再发从机地址写位然后发寄存器地址。重启START再发从机地址读位从机返回该寄存器的数据。这种先写寄存器地址再切换为读的复合事务在真实产品里非常常见。主机需要先告诉从机我要读哪个地址的数据然后再把总线切换成读模式。这套协议如果用轮询写状态机极其恶心但放在中断模式下只需要在发送完成的状态里截断一下发起重启动和读地址就行。5.2 主机端完整代码示例主机端我把上面的发送、接收状态机合并成一个更完整的驱动支持先写寄存器地址再读数据的操作volatile uint8_t i2c_master_state; /* 0:空闲 1:写地址 2:写数据 3:读数据 */ void i2c_master_read_register(uint8_t slave_addr, uint8_t reg_addr, uint8_t* buf, uint16_t len) { while(i2c_busy); i2c_slave slave_addr; i2c_reg reg_addr; i2c_rx_len len; i2c_rx_count 0; i2c_busy 1; i2c_master_state 1; i2c_ack_enable(I2C0); i2c_start_on_bus(I2C0); }事件中断里体现这个复合状态机void I2C0_EV_IRQHandler(void) { if(i2c_interrupt_flag_get(I2C0, I2C_INT_FLAG_SBSEND)) { /* 起始条件已发出 */ if(i2c_master_state 1) { i2c_data_send(I2C0, (i2c_slave 1) | 0); /* 地址写 */ } else if(i2c_master_state 3) { i2c_data_send(I2C0, (i2c_slave 1) | 1); /* 地址读 */ } } else if(i2c_interrupt_flag_get(I2C0, I2C_INT_FLAG_ADDSEND)) { i2c_interrupt_flag_clear(I2C0, I2C_INT_FLAG_ADDSEND); if(i2c_master_state 1) { /* 写地址阶段完成发送寄存器地址 */ i2c_data_send(I2C0, i2c_reg); } else if(i2c_master_state 3) { /* 读地址阶段完成准备接收数据 */ i2c_rx_count 0; if(i2c_rx_len 1) { i2c_ack_disable(I2C0); } } } else if(i2c_interrupt_flag_get(I2C0, I2C_INT_FLAG_TBE)) { if(i2c_master_state 1) { /* 寄存器地址发送完成发起重启动切到读模式 */ i2c_master_state 3; i2c_start_on_bus(I2C0); } } else if(i2c_interrupt_flag_get(I2C0, I2C_INT_FLAG_RBNE)) { if(i2c_master_state 3) { if(i2c_rx_count i2c_rx_len - 2) { i2c_rx_buffer[i2c_rx_count] i2c_data_receive(I2C0); i2c_ack_disable(I2C0); } else if(i2c_rx_count i2c_rx_len - 1) { i2c_rx_buffer[i2c_rx_count] i2c_data_receive(I2C0); i2c_stop_on_bus(I2C0); i2c_busy 0; i2c_read_complete 1; } else { i2c_rx_buffer[i2c_rx_count] i2c_data_receive(I2C0); } } } }这段代码里的一个关键点是寄存器地址发送完成后会触发TBE。我在TBE里重新发起START切换为读模式。很多人写到这里会犯迷糊以为在地址发送完成之后就立刻可以切换了但实际是必须等寄存器地址这个字节被从机真正接收也就是TBE/POS状态才能发起下一个START。这个时机错误会导致总线上出现额外的停止或冲突。5.3 从机端完整代码示例从机端除了接收主机写下来的寄存器地址外还要区分当前操作的是配置寄存器还是数据采集寄存器。volatile uint8_t i2c_slave_reg_addr; volatile uint8_t i2c_slave_rx_buf[8]; volatile uint8_t i2c_slave_tx_buf[8]; volatile uint8_t i2c_slave_tx_len; volatile uint8_t i2c_slave_tx_count; void I2C1_EV_IRQHandler(void) { if(i2c_interrupt_flag_get(I2C1, I2C_INT_FLAG_ADDSEND)) { if(i2c_slave_rw_get(I2C1)) { /* 主机要读 */ prepare_slave_tx_data(); /* 根据当前寄存器地址准备好待回传数据 */ i2c_slave_tx_count 1; i2c_data_send(I2C1, i2c_slave_tx_buf[0]); } else { /* 主机要写 */ i2c_slave_rx_count 0; } i2c_interrupt_flag_clear(I2C1, I2C_INT_FLAG_ADDSEND); } else if(i2c_interrupt_flag_get(I2C1, I2C_INT_FLAG_RBNE)) { if(i2c_slave_rx_count 0) { /* 第一个字节是寄存器地址 */ i2c_slave_reg_addr i2c_data_receive(I2C1); i2c_slave_rx_count; } else { /* 后续字节是写入的数据 */ if(i2c_slave_rx_count 8) { i2c_slave_rx_buf[i2c_slave_rx_count - 1] i2c_data_receive(I2C1); } } } else if(i2c_interrupt_flag_get(I2C1, I2C_INT_FLAG_TBE)) { if(i2c_slave_tx_count 6) { i2c_data_send(I2C1, i2c_slave_tx_buf[i2c_slave_tx_count]); } else { i2c_data_send(I2C1, 0xFF); /* 占位数据防止中断风暴 */ } } else if(i2c_interrupt_flag_get(I2C1, I2C_INT_FLAG_STPDET)) { i2c_interrupt_flag_clear(I2C1, I2C_INT_FLAG_STPDET); /* 根据寄存器地址处理收到的数据 */ if(i2c_slave_reg_addr CONFIG_REG) { apply_config(i2c_slave_rx_buf[0]); } } }这套从机代码有个设计细节值得说明接收数据时第一个字节会被识别为寄存器地址后面的字节才是真正的写入数据。这样主机读操作时只发送一个寄存器地址就切换读模式不会污染从机的数据缓冲区写操作时主机在地址后面继续发真正的数据从机也能正确区分。prepare_slave_tx_data() 函数的作用是根据当前选中的寄存器地址从采集缓冲区里拷贝数据到发送缓冲区。实际部署时这个函数会被传感器采集任务调用更新从机I2C中断只负责把最新数据发出去。5.4 中断优先级与系统资源分配双机通信方案里中断优先级的配置直接关系到系统的实时性和稳定性。我现在的配置原则是I2C事件中断优先级高于普通外部中断低于系统滴答定时器。原因是I2C通信的每个事件之间有时序约束比如TBE之后最好尽快写入下一个字节如果被其他高优先级中断打断太久总线上可能出现不必要的等待。而系统滴答定时器如果也被I2C阻塞整个系统的时钟基准就会漂移。NVIC的配置上建议把I2C中断的抢占优先级设为一个中间值比如2子优先级设0。系统滴答用最高优先级外部按钮等交互类中断用最低优先级。这样I2C不会被一般的应用中断拖延太久也不会挤压系统时钟。另外一个资源分配的关键点是不要在I2C中断里做耗时操作。比如上面代码里的apply_config()如果这个函数里有I2C操作或者延时绝对不能直接放在中断里执行。正确做法是在STPDET之后只置一个标志位主循环里检查到标志再去调用apply_config()。6. 常见问题排查与调试经验6.1 高频问题速查表I2C中断方案跑了几个项目后我把最常遇到的问题整理成了一目了然的表按出现频率排序总线卡死SCL为低从机拉低SCL等待主机释放最常见原因是某次传输出现了未处理的错误状态从机没进入正确状态机。解决方案是加软件超时看门狗并检查错误中断处理是否完整。数据错位接收时少一字节或多一字节基本可以锁定是ACK控制时机不对。读N个字节时必须在倒数第2个字节关闭ACK。收发偶发超时多数是TBE驱动发送时写数据慢了一拍总线等待过长。优化方法是把下一字节预写到数据寄存器减少空窗。中断风暴CPU占用飙高常见于从机发送时缓冲区已空但主机还没发STOP。解决方式是发送空数据填占位等STOP到来。地址匹配不上检查从机地址配置是否正确确认是7位模式还是10位模式同时用示波器看波形确认地址字节是否完整。6.2 逻辑分析仪定位问题三步法调试I2C中断问题我的首选工具是逻辑分析仪价格便宜而且直观。拿到一台逻辑分析仪不要去抓整段的波形那样信息量太大反而看不清我习惯分三步定位第一步抓正常通信的完整波形看整体时序。重点确认START条件、地址字节、数据字节、ACK/NACK、STOP条件每一段是否齐全。这一部能筛掉大约60%的问题比如地址没发出去、从机不ACK、停止条件缺失。第二步把采样率拉高放大单个字节的波形看SCL和SDA的电平时序是否严格符合I2C规范。尤其关注数据在SCL高电平期间是否稳定SCL低电平期间数据是否完成切换。这一步能暴露引脚配置错误、上拉电阻不合理这类硬件问题。第三步对照中断处理代码逐段比对波形。比如在TBE中断里写入的每一个字节波形上都应该有一一对应的数据段。如果你发现波形上有数据段但中断计数没增长那就是中断标志的清除时机有误如果中断计数增长了但波形上少了一段那可能是TBE和BTC混用导致漏了一个字节的发送窗口。6.3 几条实用的工程建议最后分享几个工程落地层面的建议都是踩坑总结出来的写得比较随性但真的管用。第一I2C中断处理函数里不要用printf调试。这个坑我犯过好几次调试输出本身就会占用大量时间I2C事件一多中断嵌套就把调试输出和I2C时序搅在一起。正确做法是用GPIO翻转打点在关键事件前后拉高拉低一个空闲引脚用逻辑分析仪抓你的软件状态变化。第二善用一个全局错误计数器。在ER中断里每类错误加一个独立计数器主循环定时读取。现场出现的偶发问题往往靠计数器的增长趋势才能定位触发频率和触发场景。没有这个计数器只会看到偶尔死一下这种模糊现象无从下手。第三多从机挂载时每个从机的地址配置最好用宏定义统一管。不要用魔法数字改起来容易漏而且排查时对着一个数码值很难反应过来对应的是哪个设备。第四从机端一定要加传输完成回调标志。裸机环境下主循环用非阻塞方式轮询回调标志RTOS环境下用信号量或者消息邮箱通知任务。不要在中断里直接操作业务逻辑这是整个方案里最重要的架构原则。最后关于这套中断通信方案我个人在实际操作中最大的收获其实是状态机越简单越可靠。I2C中断本身就是事件驱动的你只需要按事件发生的顺序把每个节点该做的事填进去不需要引入复杂的队列和缓存机制。几个标志位加两个计数器足以覆盖绝大多数主从机数据交换场景。每次回头看自己写的第一版轮询代码都有一种早该换成这套的感觉。