GD32 MCU硬件I2C不可靠不如软件I2C？来看看红枫派开发版的硬件I2C驱动如何做到稳得一批

在一个评论中，看到网友对硬件I2C的讨论，硬件I2C Busy找不到原因、软件I2C稳得一批。

那么为什么会出现I2C BUSY？硬件I2C真的不如软件I2C吗？怎么让硬件I2C也稳得一批，让我们来一探究竟。

首先我们从I2C时序分析下I2C总线挂死是如何产生的。

我们来看下I2C的时序和流程：

所以总线挂死可能会有几个原因：

1、主机信号挂死了：

主机IO口损坏、I2C状态机异常软件死机

2、主机程序异常：

I2C通信需要主机来主导，主机软件本身异常了I2C信号也不会继续产生。

3、从机拉死了总线：

I2C是线与的，所以从机拉低后总线也挂了，主机无法再次拉高发起新的通信。这种情况一般在信号被干扰时从机丢失clock或者增加了clock导致双方时序没对齐，从机还维持住一个发送0 bit的状态就把SDA拉低了。

首先原因1和2是和程序相关，I2C的状态机流程较多，自行编写驱动确实容易出现问题，只要使用成熟驱动就可以。大家可以直接使用红枫派的I2C驱动就避免这类问题，红枫派的驱动可靠性不比原厂驱动低，经受RTOS、多中断、干扰等全方面打击。

对于原因3，既然是干扰多了clock和少了clock导致从机维持拉低SDA的状态，那我们补齐clock结束这次异常通信不就可以了？

其实这个方法在最新的I2C协议标准中也有说明，不管I2C当前丢失或增加几个clcok，我们只要让主机连续补齐9个clock，在9个clock内时序一定会补齐到ACK环节，此时主机维持SDA高状态就可以让这次通信以NACK进行结束，从机自然会释放总线，这个比强制用推挽模式拉高SDA更安全合理。

那么这个异常恢复在红枫派的驱动里也已经为大家考虑好了，当总线状态出现异常时，驱动里会自动进行处理恢复总线。

那么软件I2C的弊端在哪里呢？

软件I2C一般通过IO口控制和延时进行模拟，这意味着整个通信过程会完全依靠并占用CPU，如果我们运行RTOS、或者有高频中断就会出现模拟时序过程被打断，波形会出现频率变化，波形中途停止等情况，一方面是降低通信效率，另外也可能导致主机没有在关键时间采样或者输出数据，出现通信错误。

红枫派开发板上板载了一个I2C的EEPROM，欢迎大家在软件极其严苛、硬件I2C接口随机进行干扰下验证例程，体验下稳得一批的硬件I2C。