简介：一份面向STC单片机开发者的模拟I2C通信程序源码包，针对部分STC型号不支持硬件I2C接口的问题，使用GPIO引脚精确模拟SCL时钟线与SDA数据线，完整实现起始/停止信号、数据收发、应答检测等协议时序。压缩包仅2个文件，包含i2c.c源文件和i2c.h头文件，i2c.c提供起始/停止/读写等核心函数实现，i2c.h声明接口便于工程调用，包体仅1KB，轻量易移植。已有848人学习下载，适合正在学习I2C协议或需要在STC平台上外接传感器、存储器、显示屏等I2C设备的开发者参考。代码中涉及波特率延时设置、多设备地址切换、错误处理与兼容性设计等要点，可帮助读者快速理解软件模拟I2C的底层逻辑，并在此基础上适配自己的硬件项目。 STM32F407用HAL库实现软件模拟I2C，这事我折腾过好几轮。最开始图省事直接用硬件I2C外设，结果跟某款传感器通信时老是随机卡死，排查了两天才发现是硬件I2C在异常时序下容易锁死总线。后来换了GPIO模拟，不但问题消失，代码还能无缝移植到其它引脚和芯片上。这篇文章就把我踩过的坑和最终稳定运行的方案完整分享出来。
1. 为什么放着硬件I2C不用，非要GPIO模拟
很多初学者看到"模拟I2C"第一反应是：STM32F407不是自带多个硬件I2C外设吗？直接用不就行了？这话对，但仅限于理想情况。
实际项目中，我选择GPIO模拟I2C的原因很现实：
- 引脚分配自由：硬件I2C的引脚是固定的（如PB6/PB7对应I2C1），一旦PCB布线冲突就得改板。模拟I2C可以用任意两个GPIO，布线压力小很多。
- 时序完全可控：硬件I2C的时序由外设自动生成，出问题时你只能调时钟配置，看不到具体波形。模拟I2C的每一拍都是代码控制的，逻辑分析仪一抓，问题一目了然。
- 兼容性更好：有些器件的I2C时序比较"挑剔"，比如需要很长的启动保持时间，或者应答时序偏慢。硬件外设调起来麻烦，模拟代码改延时函数就行。
- 省一个外设资源：F407的I2C外设数量有限，如果项目里还需要挂多个总线或做其它用途，模拟I2C能释放硬件外设给更需要的场景。
- 代码可移植性强：同一份模拟I2C代码，改两个宏定义的引脚，就能从F407挪到F103、G030甚至其它厂家的MCU上，硬件I2C则没这么方便。
当然，模拟I2C也有代价：占用CPU时间。因为所有时序都由代码翻转GPIO实现，高速通信时CPU没法干别的。但I2C本身常用于配置寄存器、读取传感器数据，速率一般不超过400kHz，大多数场景下CPU开销完全可以接受。
2. 模拟I2C的核心原理
I2C总线只有两根线：SCL（时钟）和SDA（数据）。所有通信协议都建立在这两根线的电平变化上。理解了这一点，模拟I2C的逻辑就清晰了。
2.1 开漏输出与上拉电阻
I2C协议要求SCL和SDA必须是开漏输出结构。所谓开漏，就是GPIO只能主动拉低到GND，想输出高电平得靠外部上拉电阻把电平"拉"上去。
这带来两个关键特性：
- 线与功能：多个设备可以同时挂在总线上，任何一个设备拉低总线，总线就是低电平。这实现了多主机仲裁和从机时钟拉伸（Clock Stretching）。
- 电平转换方便：上拉电阻接3.3V就是3.3V电平，接5V就是5V电平（前提是GPIO容忍5V），无需额外转换芯片。
所以，模拟I2C的第一步是配置GPIO为开漏输出模式。在STM32的HAL库中，这对应：
GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_OD; // 开漏输出2.2 时钟频率如何量化
I2C速率（比如100kHz或400kHz）本质上取决于SCL高电平和低电平的持续时间。模拟时，这个时间由延时函数控制。
我的做法是写一个带参数的延时函数，通过调整延时值来控制速率：
#define I2C_DELAY_TIME 5 // 半周期延时，单位us，适当调整得到目标频率 static void i2c_delay(void) { volatile uint32_t i = I2C_DELAY_TIME; while (i--) { __NOP(); } }一个完整的SCL周期包含高电平延时和低电平延时，如果各延时5us，周期就是10us，对应100kHz。想要400kHz就把延时空循环次数降到1左右。不过延时函数的实际耗时跟编译器优化级别、主频都有关系，最好用逻辑分析仪实测校准。
注意：不同优化等级下，
volatile变量的循环次数相同但实际耗时可能不同。项目发布版本一定要用-O2或更高优化等级，Debug模式测出来的时序不代表最终表现。
2.3 起始、停止、应答信号的逻辑
I2C通信中最基础的动作是起始信号（START）、停止信号（STOP）和应答位（ACK）。它们的时序逻辑其实非常简单：
- 起始信号：SCL为高电平时，SDA产生一个高到低的下降沿。
- 停止信号：SCL为高电平时，SDA产生一个低到高的上升沿。
- 应答信号：主机在第9个时钟周期释放SDA控制权，读取从机拉低的电平。如果是高电平，表示NACK（无法应答或通信结束）。
这个逻辑用伪代码表示就是：
起始：SDA高 → SCL高 → SDA拉低 → SCL拉低 停止：SDA低 → SCL高 → SDA拉高关键点在于：SDA的电平变化必须发生在SCL为低电平期间，只有在起始和停止信号时，才允许在SCL高电平期间改变SDA。这就是I2C协议的"数据有效性"规则：数据在SCL高电平期间必须保持稳定。
3. HAL库下模拟I2C的完整实现
我以STM32F407VET6为例，使用STM32CubeMX生成工程框架，然后手动添加模拟I2C代码。选两个GPIO：PB8做SCL，PB9做SDA。硬件上这两个引脚各接一个4.7kΩ上拉电阻到3.3V。
3.1 CubeMX的GPIO配置
在STM32CubeMX中，把PB8和PB9配置为GPIO_Output：
- GPIO mode: Output Open Drain（开漏输出）
- GPIO Pull-up/Pull-down: Pull-up（内部上拉，和外部上拉电阻并联保险用）
- Maximum output speed: High（高速模式，减少翻转沿的上升时间）
- Initial level: High（避免上电瞬间总线意外被拉低）
这里要说明一下为什么同时开内部上拉。正常情况下I2C需要有外部上拉电阻，但如果在原型验证阶段忘记焊电阻，内部上拉还能让总线勉强工作。量产设计建议只保留外部上拉，因为内部上拉阻值约30-50kΩ，对400kHz高速模式来说阻抗太高，信号边沿会变缓。
3.2 底层引脚操作宏定义
宏定义能让代码更简洁，也方便后续换引脚：
#define I2C_SCL_PIN GPIO_PIN_8 #define I2C_SCL_PORT GPIOB #define I2C_SDA_PIN GPIO_PIN_9 #define I2C_SDA_PORT GPIOB #define I2C_SCL_H() HAL_GPIO_WritePin(I2C_SCL_PORT, I2C_SCL_PIN, GPIO_PIN_SET) #define I2C_SCL_L() HAL_GPIO_WritePin(I2C_SCL_PORT, I2C_SCL_PIN, GPIO_PIN_RESET) #define I2C_SDA_H() HAL_GPIO_WritePin(I2C_SDA_PORT, I2C_SDA_PIN, GPIO_PIN_SET) #define I2C_SDA_L() HAL_GPIO_WritePin(I2C_SDA_PORT, I2C_SDA_PIN, GPIO_PIN_RESET)读SDA的时候要注意，开漏模式下读取引脚电平需要把引脚切回输入模式，或者使用HAL库的读引脚函数：
#define I2C_SDA_READ() HAL_GPIO_ReadPin(I2C_SDA_PORT, I2C_SDA_PIN)HAL_GPIO_ReadPin在开漏输出模式下也能正常工作，读取的是引脚实际电平，不需要切换模式。
3.3 起始与停止信号的实现
这是模拟I2C最关键的两个时序函数：
/** * @brief I2C起始信号 * 时序：SCL高电平期间，SDA产生下降沿 */ void i2c_start(void) { I2C_SDA_H(); I2C_SCL_H(); i2c_delay(); I2C_SDA_L(); // SCL为高时，SDA由高变低 i2c_delay(); I2C_SCL_L(); // 拉低SCL，准备传输数据 i2c_delay(); } /** * @brief I2C停止信号 * 时序：SCL高电平期间，SDA产生上升沿 */ void i2c_stop(void) { I2C_SDA_L(); i2c_delay(); I2C_SCL_H(); i2c_delay(); I2C_SDA_H(); // SCL为高时，SDA由低变高 i2c_delay(); }这两个函数的时序逻辑都不复杂，但有一个容易踩坑的地方：起始信号生成之前，要确保SDA和SCL都处于高电平。如果上次通信在异常状态中结束，总线上可能残留低电平。稳妥的做法是在i2c_start开头先强制拉高两个引脚，配合延时让电平稳定。我在实际项目中还加了一个"总线恢复"机制，后面会详细讲。
3.4 字节发送与接收
发送一个字节，核心逻辑是高位先行，逐位判断数据位，并在SCL高电平期间保持SDA稳定：
/** * @brief I2C发送一个字节 * @param data: 要发送的数据 * @retval 从机应答位：0表示ACK，1表示NACK */ uint8_t i2c_send_byte(uint8_t data) { uint8_t i; for (i = 0; i < 8; i++) { if (data & 0x80) // 高位先发 I2C_SDA_H(); else I2C_SDA_L(); data <<= 1; i2c_delay(); I2C_SCL_H(); // SCL拉高，从机在此时采样SDA i2c_delay(); I2C_SCL_L(); // SCL拉低，为下一位做准备 i2c_delay(); } // 释放SDA，等待从机应答 I2C_SDA_H(); i2c_delay(); I2C_SCL_H(); // 第9个时钟，读取应答位 i2c_delay(); uint8_t ack = I2C_SDA_READ(); // 读取SDA电平，低电平为ACK I2C_SCL_L(); i2c_delay(); return ack; }注意上面的关键一行：data <<= 1。这里用的是"先判断最高位再左移"的方式，每次判断data & 0x80，然后左移一位，下一位自然就到最高位了。这个写法比data & (1 << (7 - i))效率高，也更简洁。
接收一个字节类似，只不过SDA方向变成了输入。我前面提到开漏模式可以直接读引脚，因此不需要切换模式：
/** * @brief I2C接收一个字节 * @param ack: 主机应答标志，0发送ACK继续接收，1发送NACK结束接收 * @retval 接收到的数据 */ uint8_t i2c_recv_byte(uint8_t ack) { uint8_t i, data = 0; // 释放SDA，交还总线控制权给从机 I2C_SDA_H(); for (i = 0; i < 8; i++) { data <<= 1; // 先左移，因为要一位一位收 I2C_SCL_H(); // SCL拉高，从机发送数据 i2c_delay(); if (I2C_SDA_READ()) // 采样SDA电平 data |= 0x01; I2C_SCL_L(); // SCL拉低，从机准备下一位 i2c_delay(); } // 发送应答位：ACK拉低SDA，NACK释放SDA if (ack) I2C_SDA_H(); // NACK else I2C_SDA_L(); // ACK i2c_delay(); I2C_SCL_H(); // 第9个时钟 i2c_delay(); I2C_SCL_L(); i2c_delay(); return data; }3.5 组合成完整的读写函数
有了上面的基础函数，就能组合成标准的主机读写流程。以读取某寄存器为例，流程是：起始信号 → 写入从机地址+写标志 → 写入寄存器地址 → 重新起始信号 → 写入从机地址+读标志 → 读取数据 → 发送NACK → 停止信号。
/** * @brief 向I2C设备的寄存器写入一个字节 * @param dev_addr: 从机设备地址(7位) * @param reg_addr: 寄存器地址 * @param data: 要写入的数据 * @retval 0成功，1失败 */ uint8_t i2c_write_reg(uint8_t dev_addr, uint8_t reg_addr, uint8_t data) { i2c_start(); // 发送设备地址+写标志，地址左移1位，最低位为0表示写 if (i2c_send_byte((dev_addr << 1) | 0)) { i2c_stop(); return 1; } // 发送寄存器地址 if (i2c_send_byte(reg_addr)) { i2c_stop(); return 1; } // 发送数据 if (i2c_send_byte(data)) { i2c_stop(); return 1; } i2c_stop(); return 0; } /** * @brief 从I2C设备的寄存器读取一个字节 * @param dev_addr: 从机设备地址(7位) * @param reg_addr: 寄存器地址 * @param data: 读取的数据存储指针 * @retval 0成功，1失败 */ uint8_t i2c_read_reg(uint8_t dev_addr, uint8_t reg_addr, uint8_t *data) { i2c_start(); // 先写寄存器地址 if (i2c_send_byte((dev_addr << 1) | 0)) { i2c_stop(); return 1; } if (i2c_send_byte(reg_addr)) { i2c_stop(); return 1; } // 重启起始信号，切换为读模式 i2c_start(); if (i2c_send_byte((dev_addr << 1) | 1)) { i2c_stop(); return 1; } // 读取数据，最后一个字节发送NACK表示读取结束 *data = i2c_recv_byte(1); i2c_stop(); return 0; }这个地址处理的写法值得单独说明一下。I2C设备地址有两种形式：7位地址和8位地址。上面代码里dev_addr是7位地址，左移一位后最低位填入读写标志。很多STM32的硬件I2C库会自动帮你左移，但软件模拟时必须自己完成这一步。如果设备数据手册写的是8位地址形式（比如0xA0），那就不需要左移，直接使用即可。新手最容易在这个地方懵。
4. 实测调试与常见问题排查
代码写完后，理论上一编译就能用，但实际调试时我几乎每次都会遇到新问题。下面是我在调试模拟I2C时踩过的最典型的几个坑。
4.1 用逻辑分析仪验证波形
模拟I2C最大的优势就是可以用逻辑分析仪直接验证时序。我的调试流程是：
- 把SCL和SDA分别接到逻辑分析仪的CH0和CH1，设置采样率不低于2MHz。
- 运行代码，捕捉通信波形。
- 对照I2C协议手册逐字节查看数据。
- 重点检查起始/停止信号的建立时间，以及每个字节的应答位。
我用的逻辑分析仪是几十块钱的8通道USB逻辑分析仪，配Saleae软件（兼容模式）。对100kHz的I2C信号来说，2MHz采样率绰绰有余。曾经遇到一次通信异常，抓波形发现SDA在起始信号之前有一个意外下降沿，仔细检查才发现是上电初始化顺序问题：GPIO配置之前，引脚处于浮空状态，外部设备通过上拉电阻对引脚充电导致电平不稳定。解决方法是初始化时先把引脚拉高再配置模式。
4.2 总线死锁恢复
这是模拟I2C开发者会遇到的经典问题。从机没有复位或受到干扰时，可能处于异常状态，表现为：主机发送起始信号后，从机一直将SDA拉低，导致主机无法发送起始信号（因为SDA无法变高），总线看起来就"卡死"了。
硬件I2C遇此情况会置位错误标志位，但软件模拟则可能陷入死循环。我总结了一套有效的总线恢复方案：
/** * @brief 模拟I2C总线恢复 * 尝试将总线恢复到空闲状态，最多翻转SCL 9次 * @retval 0成功，1失败 */ uint8_t i2c_bus_recovery(void) { uint8_t i; // 先将SDA释放，SCL拉高 I2C_SDA_H(); I2C_SCL_H(); i2c_delay(); // 检查SDA是否已被释放（变为高电平） if (I2C_SDA_READ()) { return 0; // 总线已恢复 } // 若SDA仍为低，尝试SCL时钟翻转，让从机释放SDA for (i = 0; i < 9; i++) { I2C_SCL_L(); i2c_delay(); I2C_SCL_H(); i2c_delay(); if (I2C_SDA_READ()) { // 总线释放了，发送停止信号结束恢复 I2C_SCL_H(); i2c_delay(); I2C_SDA_H(); i2c_delay(); return 0; } } return 1; // 9个时钟都无法恢复，可能需要硬件复位 }这个恢复机制的原理是：总线上如果有从机正在输出数据（拉低SDA），它会监控SCL的边沿。通过对外发送多至9个时钟脉冲（一个完整字节+应答位），从机会完成当前的数据传输阶段，释放总线。实测下来，这个方案能解决绝大多数总线卡死问题。
注意：总线恢复的前提是硬件接线正确、从机供电正常。如果从机本身已经死机到连SCL都不认，那软件手段无法恢复，只能硬件复位从机（如果有复位引脚，可以接一个GPIO专门控制）。
4.3 上拉电阻与通信速率的取舍
上拉电阻的阻值直接影响I2C通信的稳定性和最高速率。阻值越小，上升沿越快，但低电平时的电流越大；阻值越大，功耗越小，但上升沿变缓，高速通信时信号边沿可能不满足协议要求。
以3.3V供电的F407为例，我实测过不同阻值的表现：
| 上拉电阻 | 100kHz | 400kHz | 说明 |
|---|---|---|---|
| 1kΩ | 稳定 | 稳定 | 功耗略大，约3.3mA低电平电流 |
| 4.7kΩ | 稳定 | 稳定 | 通用选择，兼顾功耗与信号质量 |
| 10kΩ | 稳定 | 偶尔异常 | 400kHz时上升沿偏缓，偶尔误码 |
如果总线上挂了多个从机设备，等效上拉电阻会减小，可以适当增大阻值。如果是电池供电的物联网设备，可以为了省电选择10kΩ并把通信速率降到100kHz。我的经验是：默认用4.7kΩ，特殊需求再调整。
4.4 地址不匹配的排查
我在调一个新传感器时，经常发现发送了地址后从机一直不回应（NACK）。排查步骤通常是：
- 确认设备地址：很多芯片的地址引脚（如A0/A1/A2）会改变地址。对照数据手册，确认7位地址是否与硬件接线一致。
- 确认地址格式：判断手册中的地址是7位还是8位形式。如果手册写的是8位地址0xD0，那对应的7位地址是0x68。
- 用I2C扫描程序：写一个简单的地址扫描函数，遍历0x01~0x7F所有地址，看哪些地址有应答。这个方法能快速确定设备实际地址。
下面是我常用的地址扫描代码：
void i2c_scan(void) { uint8_t addr; printf("I2C Scan Result:\r\n"); for (addr = 1; addr < 128; addr++) { i2c_start(); if (i2c_send_byte((addr << 1) | 0) == 0) { printf("Found device at 0x%02X\r\n", addr); } i2c_stop(); } }这个扫描需要结合串口打印使用。实测在F407上，160个设备的扫描时间不到1秒（考虑到软件延时的开销，实际会稍微慢一点）。
4.5 时钟延展没处理导致的读数据失败
一些从机设备（特别是部分温湿度传感器）处理速度较慢，在主机发送读取命令后会主动拉低SCL，让主机等待。这个机制叫"时钟延展"（Clock Stretching）。
硬件I2C外设有些会自动处理时钟延展，但软件模拟需要自己检查：在SCL释放高电平后，等待从机释放SCL。
uint8_t i2c_wait_scl_high(uint32_t timeout) { uint32_t count = 0; while (count < timeout) { if (HAL_GPIO_ReadPin(I2C_SCL_PORT, I2C_SCL_PIN) == GPIO_PIN_SET) { return 0; // SCL已变高 } count++; } return 1; // 超时 }这个延时等待函数的引入，意味着之前接收函数中I2C_SCL_H()后要插入等待逻辑。这样做的代价是每一次SCL拉高都要多调用一次读取函数，指令周期会增加不少。但如果确认自己的从机设备不支持时钟延展，可以不用这个机制以提升速度。
5. 模拟I2C的边界与选择建议
最后说说模拟I2C的适用边界。
我目前的项目里，如果是简单设备（温度传感器、EEPROM、RTC、IO扩展芯片等），通信频率不超过400kHz，我基本都用模拟I2C。代码量小、问题直观、移植方便，省了很多调试时间。
如果是需要大规模数据传输（比如和摄像头模组通信）、总线挂载设备很多、或者MCU主频本身较低无法挤出CPU时间的情况，我建议还是优先考虑硬件I2C，甚至可以用SPI替代。
还有一点补充：如果你用的是STM32CubeMX + HAL库开发方式，可以这么理解生成的GPIO初始化和手动添加的模拟I2C代码，两者的关系就像搭积木：CubeMX负责搭基础的引脚配置，模拟I2C是你的业务层。CubeMX重新生成工程后不会影响已有的模拟I2C函数，只要你不是把它们写在CubeMX生成区（/* USER CODE BEGIN */和/* USER CODE END */之外）就行。模块化设计的好处是，以后换任何MCU平台，只要改掉宏定义底层的引脚操作和延时函数，上层的读写逻辑完全不用动。
我习惯把模拟I2C封装成一个独立文件soft_i2c.c和soft_i2c.h，对外只暴露i2c_write_reg、i2c_read_reg、i2c_bus_recovery这几个接口。不管底层是STM32、GD32还是AT32，不管上游是用寄存器还是HAL库，上层代码永远只面对这几个API。这也是我推荐所有做MCU开发的朋友养成的习惯：底层驱动与业务逻辑解耦，移植时能省下大量时间。
最后再分享一个小技巧：写完模拟I2C后，建议把延时函数里的空循环次数抽成一个宏，在调试时通过修改宏快速切换100kHz和400kHz速率，配合逻辑分析仪观察波形变化。我之前调试某颗触控芯片时，就是靠这个方法，对比不同速率下的波形差异，最终发现该芯片在400kHz模式下需要更长的时间设置时钟延展，从而定位了问题根因。有时候问题并不在协议逻辑本身，而在于时序余量不足。掌握模拟I2C的底层细节，对你理解I2C协议本身的帮助，也是硬件I2C外设无法替代的。
本文还有配套的精品资源，点击获取
