/**

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

* @author    Maoxiao Hu

* @version   V1.0.0

* @date       May-2015

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

* < COPYRIGHT 2015 ISE of SHANDONG UNIVERSITY >

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

**/

除錯STM32的硬體I2C已經有很長一段時間了，幾乎搜遍了所有資料，對於其到底能不能正常工作，今天做一個徹底的研究。

下面是我在測試中得到的幾個結論：

1、硬體I2C的CLK在50kHz及以下的情況下工作，不會出現任何情況下的卡住。（本人測試時間為20h）

2、硬體I2C的CLK在常用的100kHz和400KHz下工作，99%的概率下會在1小時之內卡住，甚至只有幾十秒。

3、硬體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晶片。