I2C通信，别掉坑里——clock stretching

I2C，一种非常常用的低速通信协议，由飞利浦提出，已经被广泛使用。他的实现成本非常低廉，所以深受各种芯片的欢迎。

同时，现在很多处理器，小到单片机，大到处理器，几乎都有I2C硬核。我们几乎不用关心I2C具体是什么样的，只要大致知道几种通信模式即可。

今天，我想跟大家挖掘下这个简单协议背后的一个巨大的坑，千万别把I2C想当然了，其实没那么简单！

这个坑就是——clock stretching。

首先简单介绍下这是什么。

我们都知道，I2C主设备始终控制着时钟线SCL，不论是往设备写还是从设备读。

一般情况下，如果操作对象是EEPROM或者其其他简单设备而言，无所谓。

但是，如果从设备是处理器，在接到主机命令后要去处理一些运算然后得出结果返回给主机。这个时候可能造成来不及处理。怎么办？这时，从设备会主动控制时钟线把它拉低！！！！

直到数据准备好之后再释放时钟线，把控制权交还给MASTER。这也是I2C通信系统中，从机唯一能控制总线到时候！。

关键是很多I2C主机不支持clock stretching功能，所以，无法和带有clock stretching功能的从机通信！！！！！所以，各位在选择主机器件之前，必须要注意这一点，不然整个设计方案可能报废，影响很大。

我的设计方案中，需要USB2I2C的芯片，我选择了FT2232和CY7C65215，这两块芯片虽然都标注支持USB2I2C，但是，前者是对GPIO拟合I2C操作，后者不支持clock stretching！所以，导致很长时间一度I2C通信失败，现在市场上这种ASIC，特别是usb转多个I2C MASTER的，几乎找不到IC，空白市场~~~~~~~(不知道这个信息有木有价值)

所以，在大家今后的设计中，千万要注意，I2C不是想象中那么简单的。

最后，感谢论坛给我的树莓派玩，今天我也很高兴跟大家分享这个树莓派的bug！！！，对了，就是他的I2C功能。bug就出现在clock stretching上。我很无奈放弃了使用他硬件I2C的方案。同时，google也搜到网上有老外也发现了这个bug，贴几张他的图：

I2C通信，虽然简单，但当心，别掉坑里——clock stretching

那个红线的地方就是clock stretching，按道理来说，从机处理期间，时钟线拉低，等待释放后恢复正常，但是，raspi里面的恢复后的第九个时钟非常小！！！，在400k及以上的通信中，有概率造成通信失败！这是病，没药治（无奈）

clock stretching 瞬间：

这个图很明显，最后8个clk后，时钟线拉低

这个图是CYPRESS的usb转serial的桥，可以看见他是一直发的，没有clock stretching功能

总结：

I2C通信是我们平时不太深入研究的东东，因为有现成的模块，但是，在大家碰到复杂情况，或者软件模拟的时候，请注意，这里有个坑，别掉下去了。

特别点名有以下情况的同学要注意：树莓派玩家，软件模拟I2C玩家，FPGA玩家以及系统工程师，硬件工程师