简介面向STM32嵌入式开发者的I2C从机实现范例演示如何仅用GPIO口模拟SDA与SCL时序在无专用I2C外设或需要扩展从机接口时通过中断驱动的状态机完成低延时通信。状态机按主设备操作流程分为等待起始信号、解析从机地址、接收/发送数据、产生应答等阶段各阶段由SCL边沿中断触发迁移避免轮询造成的CPU空耗。代码将核心状态机与硬件移植层分离结构清晰便于根据实际需求调整时序行为。压缩包仅3KB共4个文件含2个C源文件和2个头文件结构紧凑适合学习与二次开发。目前已有4068人学习浏览。资源中可直接借鉴GPIO外部中断配置、状态迁移设计和回调接口预留快速搭建可用的I2C从机demo并可通过读写寄存器、波形调试等方式验证通信正确性对于希望深入理解I2C协议和MCU中断应用的开发者是一份轻量且完整的参考实现。 搜“IO口模拟I2C”满屏基本都是模拟主机拉高拉低延时半周期读回来就完事开心就好。可一旦想用普通GPIO去模拟I2C“从机”能抄的现成代码立刻少一大半——这两件事的难度完全不在一个量级。主机是“我说话你听着”时序全由自己定从机是“对方想什么时候开口就什么时候开口”你必须在每个位周期内完成采样、判断和应答错过一个边沿整帧直接废掉。这篇文章记录的是我用STM32F407的两个普通GPIO把IO口模拟I2C从机完整跑通的过程。背景是这样的手里有一颗MCU需要伪装成一颗I2C传感器让外部主控正常读写同时顺手验证了一个常被问的问题——当硬件I2C外设不够用、或者被其他设备占用时软件模拟从机方案到底能不能在这个平台上稳定工作。实测结论是可以但架构和排错思路跟模拟主机完全是两码事。这篇文章适合正在做多机通信、需要把某颗MCU虚拟成一个从机设备、或者被硬件I2C外设“锁死问题”折磨过的人。1. 从机不是主机的“反向实现”先认清三个残酷差异很多人看到标题的第一反应是主机不就是把SCL拉低拉高、往SDA上放数据吗那从机不就是倒过来实际动手后你会发现方向反了不代表逻辑也能“反着写”。从机面对的是三个主机根本不会遇到的问题这几个问题决定了整个实现方案的走向。1.1 时序的主动权完全不在你手里模拟主机的时候你想什么时候翻转SCL就什么时候翻转延时的精度直接影响数据是否正确但至少时间由自己掌控。从机不行SCL时钟是从外部进来的主机不会等你把状态机准备到位再发下一拍。更麻烦的是起始条件、停止条件、重复起始都由SDA在SCL高电平期间的跳变产生这是完全异步的事件没法靠轮询SCL去预测。我第一次调试时犯过一个典型错误想知道主机什么时候“开口”于是在主循环里反复读SDA引脚电平。结果SCL在100kHz时勉强能跟一换到400kHz主循环里多一个浮点运算都会丢位。后来我才想明白从机模拟的第一原则不是“尽量跑得快”而是“用事件驱动而不是用轮询驱动”。1.2 为什么轮询方案在从机场景必然翻车轮询方案的问题不只是速度还有“不确定性”。主循环里可能存在一段耗时任务比如刷屏、写Flash、跑算法任何一个超过位宽一半的操作都会让从机错过采样窗口。就算你把所有延时都控制得很准主循环里的任务调度延迟也是不可控的定时器中断、串口中断一进来你都不知道自己离开总线多久了。从机模拟的底座必须是外部中断SCL的每个上升沿和下降沿都触发中断在中断上下文里完成位采样和状态推进。这样即使主循环被某个任务卡住几十微秒只要中断没有被全局关闭从机依然能跟着总线走。我实测下来只要中断响应稳定配合适度优化400kHz的I2C完全能跑1Mbps会明显紧张但不是完全不可能。1.3 从机的“实时预算”到底有多紧张我算过一笔账这也是我不建议用“快循环”去兜底的原因总线速率位周期实际有效处理时间100kbps10us足够宽裕400kbps2.5us紧张但可行1Mbps1us只能做寄存器级操作注意这个“位周期”并不是全部都能用来处理逻辑。SCL高电平期间SDA要保持稳定数据采样一般放在上升沿或高电平中点SCL低电平期间SDA允许变化但你必须在下一个高电平到来前把输出准备好。真正能用于中断处理的时间往往只有半个周期甚至更短。看起来400kHz有2.5us一个位但中断进入、退出、寄存器读写一算留给多几行if判断的空间非常有限。所以我最终确定的架构是SCL走外部中断SDA也走外部中断但SDA中断只负责识别起始和停止不负责数据拼接数据拼接全部放在SCL中断里做。这种分工看起来多占了一个中断源实际上把实时性压力分摊开了比把所有逻辑硬塞进一个回调里要稳得多。2. SCL边沿中断SDA边沿检测从机模拟的总体架构直接给出结论我用PA0接SCLPA1接SDA。PA0配置为外部中断上升沿和下降沿都触发PA1也配置为外部中断但只在SDA发生跳变时触发回调里再判断SCL电平用来区分是起始/停止还是普通的数据位翻转。2.1 引脚初始化为什么SCL要配成开漏输出而不是输入刚开始我很自然地把SCL配成输入理由很简单“SCL不是由主机驱动的吗从机只读就好了。”这个想法会在你想使用“时钟拉伸”的时候立刻破产——当从机处理不过来时需要主动拉低SCL让主机暂停如果引脚只是输入就没有拉低的能力。正确的做法是把SCL也配成开漏输出默认输出高电平。开漏输出的特性是高电平靠外部上拉电阻实现外部主机拉低引脚时引脚电平自然变低你想主动拉低时直接写0也能做到。同时开漏输出引脚也能读输入电平外部中断照常触发。SDA同理同样配成开漏输出、默认高电平。这样整条总线保持“线与”逻辑才符合I2C电气规范。下面是我在STM32F407上用的HAL初始化代码GPIO_InitTypeDef GPIO_InitStruct {0}; __HAL_RCC_GPIOA_CLK_ENABLE(); // PA0 - SCL开漏输出上下沿都触发外部中断 GPIO_InitStruct.Pin GPIO_PIN_0; GPIO_InitStruct.Mode GPIO_MODE_IT_RISING_FALLING; GPIO_InitStruct.Pull GPIO_PULLUP; GPIO_InitStruct.Speed GPIO_SPEED_FREQ_VERY_HIGH; HAL_GPIO_Init(GPIOA, GPIO_InitStruct); // PA1 - SDA开漏输出上下沿都触发外部中断 GPIO_InitStruct.Pin GPIO_PIN_1; GPIO_InitStruct.Mode GPIO_MODE_IT_RISING_FALLING; GPIO_InitStruct.Pull GPIO_PULLUP; GPIO_InitStruct.Speed GPIO_SPEED_FREQ_VERY_HIGH; HAL_GPIO_Init(GPIOA, GPIO_InitStruct); // 拉高默认电平避免开机瞬间总线被拉低 HAL_GPIO_WritePin(GPIOA, GPIO_PIN_0 | GPIO_PIN_1, GPIO_PIN_SET); HAL_NVIC_SetPriority(EXTI0_IRQn, 0, 0); HAL_NVIC_SetPriority(EXTI1_IRQn, 1, 0); HAL_NVIC_EnableIRQ(EXTI0_IRQn); HAL_NVIC_EnableIRQ(EXTI1_IRQn);注意几个容易被忽略的细节。GPIO_MODE_IT_RISING_FALLING在HAL库中可以直接同时开启上升沿和下降沿中断不需要手工操作EXTI寄存器。优先级方面SCL中断的优先级要高于SDA中断因为数据位的实时性要求远高于事件识别SDA中断即使稍晚进入只要最终能识别出起始和停止就够了。2.2 状态机骨架地址阶段、ACK、收发数据的推进逻辑从机本质上就是一个状态机。我用枚举定义了这几个状态typedef enum { I2C_S_IDLE, // 空闲等待起始条件 I2C_S_ADDR, // 正在接收地址字节7位地址 R/W位 I2C_S_ADDR_ACK, // 地址字节后的第9个时钟需要回ACK I2C_S_DATA_IN, // 主机写从机正在接收数据字节 I2C_S_DATA_OUT, // 主机读从机正在向主机发送数据字节 I2C_S_DATA_ACK, // 数据字节后的第9个时钟处理ACK/NAK I2C_S_STOP_WAIT // 等待停止条件准备完整复位 } i2c_slave_state_t;状态迁移的核心思想可以总结成一句话用SCL上升沿去“读”SDA用SCL下降沿去“推进”状态。上升沿时SDA已经稳定此刻采样的数据最可靠下降沿是主机允许SDA变化的时间点从机正好利用这段低电平时间更新SDA输出为下一拍做准备。举个例子地址阶段的位拼接每一个SCL上升沿把当前SDA电平移入一个8位移位寄存器。收到8位之后在第9个时钟的SCL下降沿判断地址是否匹配并在第9个时钟的上升沿到来前完成ACK电平的输出。整个过程环环相扣每一步都有明确的时间锚点。2.3 SDA边沿辅助判断起始与停止解决边沿错位问题有朋友会问起始条件和停止条件没有伴随SCL边沿那怎么检测确实单靠SCL中断永远等不到“SCL高电平期间SDA发生跳变”这种事件。所以在SCL中断之外我同时开启了SDA的外部中断。在SDA中断回调里第一件事是读SCL电平void EXTI1_IRQHandler(void) { if (__HAL_GPIO_EXTI_GET_IT(GPIO_PIN_1) ! RESET) { __HAL_GPIO_EXTI_CLEAR_IT(GPIO_PIN_1); if (HAL_GPIO_ReadPin(GPIOA, GPIO_PIN_0) GPIO_PIN_SET) { // SCL为高这是起始条件或停止条件 if (HAL_GPIO_ReadPin(GPIOA, GPIO_PIN_1) GPIO_PIN_RESET) { state I2C_S_ADDR; // 起始条件准备接收地址 bit_cnt 0; addr_shift 0; } else { state I2C_S_IDLE; // 停止条件回到空闲 } } // 如果SCL为低说明只是数据位在SCL低电平时翻转直接忽略 } }这个“先看SCL电平再决定动作”的过滤逻辑是整个检测方案的关键。SCL低电平期间SDA变化是数据位翻转的正常现象比如连续两个字节都是0x00时SDA在一个字节结束后会从低变高、下一字节又从高变低如果不对SCL电平做判断这些跳变会被误认为起始或停止。有了这层过滤起始和停止的判定就变得非常清晰。3. 代码级拆解状态怎么迁数据怎么收ACK怎么回架构清晰之后最容易绊倒人的是具体细节地址匹配、数据收发方向、ACK输出时机。我在这里把每一步拆开写代码片段的思路可以平移到其他M内核单片机上。3.1 地址阶段的位拼接与重复起始处理起始条件之后第一个字节的8位是“7位地址读写位”每一位的采样都发生在SCL上升沿。SCL中断回调里我是这样处理的void EXTI0_IRQHandler(void) { if (__HAL_GPIO_EXTI_GET_IT(GPIO_PIN_0) ! RESET) { __HAL_GPIO_EXTI_CLEAR_IT(GPIO_PIN_0); uint8_t sda HAL_GPIO_ReadPin(GPIOA, GPIO_PIN_1); if (HAL_GPIO_ReadPin(GPIOA, GPIO_PIN_0) GPIO_PIN_SET) { // 上升沿SDA已稳定在这里采样 if (state I2C_S_ADDR) { addr_shift (addr_shift 1) | sda; bit_cnt; } else if (state I2C_S_DATA_IN) { rx_byte (rx_byte 1) | sda; bit_cnt; } } else { // 下降沿推进状态机 if (state I2C_S_ADDR bit_cnt 8) { state I2C_S_ADDR_ACK; prepare_ack_or_nack(); } } } }重复起始条件很值得单独提醒。主机可以在发送完一个字节后、未发停止条件之前再次发起起始条件此时从机必须把状态拉回I2C_S_ADDR重新接收新的地址。重复起始的检测同样依赖SDA中断只要检测到“SCL高电平 SDA下降沿”且此时不是空闲状态就说明是重复起始。我的处理是检测到就把state拉回I2C_S_ADDR同时清空位计数。这个细节如果不处理从机很容易在重复起始后错误地停在数据阶段导致后面所有字节全部错位。3.2 地址匹配与读写方向判断地址字节的8位收完后最高7位是设备地址最低1位是R/W。以7位地址0x18为例在总线上这个字节实际表现为0x30地址左移一位所以比较时要特别注意移位。我用宏定义和简单判断来处理#define I2C_SLAVE_ADDR_7BIT 0x18 uint8_t dev_addr (addr_shift 1) 0x7F; uint8_t rw_bit addr_shift 0x01; if (dev_addr I2C_SLAVE_ADDR_7BIT) { ack_flag 1; if (rw_bit 0) { state I2C_S_DATA_IN; // 主机要写从机 } else { state I2C_S_DATA_OUT; // 主机要读从机 } } else { ack_flag 0; // 地址不匹配回NACK等待停止条件 }地址不匹配时的处理同样重要。不能把从机的内部状态搞乱也不要尝试驱动SDA保持释放状态让SDA维持高电平相当于向主机回一个NACK。主机看到NACK后通常有两种选择发出停止条件结束传输或者重新发起起始。千万不要在地址不匹配时继续参与后续数据阶段否则会和总线上真正的目标设备发生冲突把整个总线的通信搅浑。3.3 ACK输出提前一拍给建立时间留余量ACK怎么回是新手最容易出错的地方。按I2C协议主机在地址字节或数据字节后的第9个时钟高电平时读取SDA从机必须在这期间把SDA拉低。很多人会想当然地写“第9个时钟上升沿才拉低SDA”这在实际调试中经常翻车。主机是在第9个时钟高电平期间采样如果你等到上升沿才拉低SDA主机的采样窗口已经开始SDA电平还没稳定下来结果就是偶发的NACK或者丢字节。正确做法是提前一拍在第8个数据位的下降沿到来时立刻把SDA拉低一直保持到第9个时钟的上升沿之后再根据读写模式决定是否释放。我在中断回调里是这样处理的if (bit_cnt 8) { // 第8位结束SCL刚变低立刻准备ACK if (ack_flag) { SDA_AS_OUTPUT_LOW(); // 回ACK拉低SDA } else { SDA_RELEASE_HIGH(); // 回NACK释放SDA } bit_cnt 0; state I2C_S_DATA_ACK; }对于读操作数据字节的每一位也要在SCL下降沿之后立刻放上SDA绝不能等到上升沿才更新。主机是在SCL高电平期间读取SDA的如果数据在上升沿才更新主机读到的可能是上一位的残留电平。这就是为什么数据输出状态下的SDA更新也必须放在下降沿中断里完成。4. 实测中的三个坑从扫不到地址到丢数据的排查链路软件模拟从机代码写出来是一回事上总线跑又是另一回事。我调试过程中踩到的三个问题几乎每一个都能对应到具体的设计缺陷单独拉出来讲讲排查思路比直接给“正确答案”更有参考价值。4.1 排查链路一主机扫描不到从机波形全对但地址是乱的第一次接好线后上位机里的I2C地址扫描工具发出一个0x18地址从机毫无响应。用逻辑分析仪抓到的时序看起来完全正常起始条件正确、地址波形也确实出现在总线上。但我把地址位逐位和期望值对比后发现从机实际收到的地址比预期左移了一位。排查过程是这样的第一轮先怀疑上拉电阻太小导致边沿被压扁把板子上的4.7k换成2.2k波形是漂亮了问题依旧。第二轮怀疑SCL中断配置确认上升沿和下降沿确实都有触发。第三轮用调试器在中断回调里打断点看addr_shift的累积过程发现每次SCL上升沿读回来的SDA都不是期望的那一位而是SCL下降沿之后已经变化了的下一位数据。根因是我早期的代码在SCL下降沿采样SDA。I2C总线在SCL低电平期间本来就允许SDA变化很多主机会在SCL下降沿前后就把SDA切换到下一位于是下降沿采样采到的往往是“未来的数据”。把采样点改到SCL上升沿之后addr_shift立刻正确。这也是我后来把“采样一律在上升沿、状态推进一律在下降沿”写进代码注释的原因。4.2 排查链路二ACK信号存在但主机仍然上报NACK地址能识别之后第二个坑出现在ACK上。从逻辑分析仪上看第9个时钟高电平期间SDA确实被拉低了但主机一直报NACK重试多次偶尔能成功一次。这次我先从主机侧排查怀疑主机的I2C控制器配置有问题。换用示波器观察波形后才注意到一个细节SDA从高到低的下降沿几乎贴着第9个时钟的上升沿发生主机采样那一刻SDA可能刚开始下降建立时间明显不足。问题根源就在ACK动作的时机上。我原本是在第9个时钟上升沿才去拉低SDA虽然中断处理速度很快但站在主机的视角建立时间确实不够。把ACK拉低动作提前到第8位下降沿之后波形上第9个时钟高电平时SDA已经稳定为低主机立刻就能识别到ACK。从那以后我再没在这个项目里见过NACK报错。4.3 排查链路三400kHz下连续多字节传输丢字节地址和单字节读写都正常后我开始跑连续8字节的读写测试结果每到第三、四个字节就会出现错位数据整体往后移像是少了一个时钟。这次定位用了二分法先在100kHz下反复跑连续几百字节都没问题换到400kHz后几分钟内必现这说明问题和实时响应时间强相关。接着我把SCL中断的优先级调到最高把中断回调里占用时间较长的浮点运算全部移出只保留位拼接和状态迁移主循环只做缓冲区的搬运。实测下来只要SCL中断回调足够精简400kHz下连续传输也很稳定。如果以后遇到类似现象建议先确认编译器优化是否被设成了O0再把能挪出中断的逻辑全部挪出去。软从机对中断代码的长度极度敏感这也是它和硬件I2C外设最大的区别——硬件外设帮你扛住了位级时序软件模拟就只能靠自己优化。5. 硬件层面绕不开的几件事开漏上拉、电平匹配与时钟拉伸代码层面的坑填得差不多了硬件上的问题同样会消耗大量调试时间。这几个点不会在编译期报错但会在某个莫名其妙的深夜让你怀疑人生。5.1 开漏上拉是“必须的”不是可选项I2C是典型的“线与”总线SCL和SDA都允许多设备同时控制。如果图省事把GPIO配成推挽输出一旦主机和从机同时对同一根线输出相反电平轻则波形异常重则直接烧引脚。正确做法是SCL和SDA都配成开漏输出板级加上拉电阻。上拉电阻的取值要看总线上挂了多少个设备、走线有多长。我测试用的单板、两三个设备4.7k比较稳妥如果总线负载较重可以降到2.2k。上拉电阻越大边沿越缓越小驱动电流偏大。标准模式100kHz用4.7k到10k都能跑快速模式我习惯用2.2k到4.7k之间实际以逻辑分析仪看到的边沿质量为准。5.2 电平转换3.3V从机接5V主机的自救方案STM32F407的大多数IO并不是5V容忍如果你把一个3.3V的模拟从机直接接到5V的I2C总线上总线高电平会超过IO口的绝对最大额定值。典型的故障表现是低电平正常但高电平被IO内部钳位二极管压住波形变成梯形速率稍高就完全无法通信。两个可行的处理方案第一查数据手册确认引脚是不是FT5V容忍引脚如果是FT引脚可以直接接5V总线第二在3.3V和5V之间加I2C专用电平转换芯片比如PCA9306或TCA9517不要用普通数字缓冲器普通缓冲器会破坏I2C的“线与”结构。没有芯片的临时方案可以用两个MOSFET搭双向电平转换电路但批量产品里我强烈建议直接用转换芯片稳定省心。5.3 时钟拉伸可以缓和实时压力但要有意识去用时钟拉伸是I2C协议里一个不太显眼但非常实用的机制从机可以在任意SCL低电平期间主动把SCL拉低主机检测到SCL仍然是低电平就不会继续下一个位周期直到从机释放SCL。这意味着当软从机任务较重、中断响应出现波动时可以通过时钟拉伸给系统争取额外的处理时间。但这里有个前提不是所有主机都支持时钟拉伸。一些严格的读卡器、摄像头主机甚至会在检测到时钟拉伸后直接超时返回错误。我的测试环境里STM32做主机的标准库配置是支持时钟拉伸的所以我故意在调试期间加过一次短暂的SCL拉低来验证主机行为确认主机会停止等待而不是报错。如果真要拿它兜底记得把“释放SCL”的动作放在中断回调所有处理逻辑的最后确保从机状态已经完整准备好再放主机继续跑。最后分享一个我自己的调试习惯第一次调通模拟从机时我反复跟逻辑分析仪较劲逐步放大抓到的波形去对每一位效率很低。后来我把每次修改都固化成一个“先录波形、再改代码”的流程——先看主机到底发的是什么再想从机该怎么响应而不是凭感觉猜。软从机这东西本质上是在跟协议时序抢时间先看见总线上的真实状况再动手写状态机能省掉大量直觉判断试错的成本。本文还有配套的精品资源点击获取