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芯片。