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