STM32 硬件I2C 究竟是不是个坑？

/**

******************************************************************************

* @author    Maoxiao Hu

* @version   V1.0.0

* @date       May-2015

******************************************************************************

* < COPYRIGHT 2015 ISE of SHANDONG UNIVERSITY >

******************************************************************************

**/

调试STM32的硬件I2C已经有很长一段时间了，几乎搜遍了全部资料，对于其到底能不能正常工做，今天作一个完全的研究。

 

下面是我在测试中获得的几个结论：

一、硬件I2C的CLK在50kHz及如下的状况下工做，不会出现任何状况下的卡住。（本人测试时间为20h）

二、硬件I2C的CLK在经常使用的100kHz和400KHz下工做，99%的几率下会在1小时以内卡住，甚至只有几十秒。

三、硬件I2C的CLK在任何频率下工做，在读取或者发送数据时，都绝对不容许其它中断事件打断它的工做，不然必定会卡住，只是时间问题。

综上，硬件I2C的稳定工做状况是：工做在50kHz及如下，而且保证无其它任何中断打断它的工做。这样只适用于某些对速率要求不高的场所，好比EEPROM的读取等，而对于高速器件例如某些型号的AD芯片，就不能用了。

 

若是你必定须要高速率（400KHz）,那么推荐你们使用STM32的替代方案GD32（兆易创新），它与STM32彻底兼容可是解决了STM32的硬件I2C bug，通过本人实际测试，在400KHz的状况下工做，48小时无任何错误发生。可是仍需注意的是不能有外部中断打断I2C的工做。

 

对于ST公司推荐的将I2C工做在DMA和最高优先级的中断，我只能说你们能够根据本身的状况使用，由于若是你使用了ucos ii或者其它实时操做系统，那么这种设置最高优先级的方式是绝对不推荐的。若是你是裸机程序，而且任务数量很少，能够考虑这种DMA+中断的方式，不然必定会出现问题，只是测试时间长短问题。

 

最后须要说明的是：

（1）以上只是考虑了最纯粹的硬件I2C代码，对于某些使用了软件弥补的方法，例如在常常卡住的部分设置超时退出，不在本文的讨论范围内，由于这样已经破坏了正常的I2C协议。

（2）因为使用STM32的较高境界是使用中断调度任务而不是死等循环，而硬件I2C对于中断打断十分忌讳，因此随着你的编程和对操做系统理解水平的提升，你会愈来愈感受STM32硬件I2C是个坑。

 

因此，STM32的硬件I2C确实是个坑，能够正常工做的环境要求十分苛刻，因此本人如今已转而使用GD32芯片。