/**
******************************************************************************
* @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芯片。
