在一個評論中,看到網友對硬件I2C的討論,硬件I2C Busy找不到原因、軟件I2C穩得一批。
那么為什么會出現I2C BUSY?硬件I2C真的不如軟件I2C嗎?怎么讓硬件I2C也穩得一批,讓我們來一探究竟。
首先我們從I2C時序分析下I2C總線掛死是如何產生的。
我們來看下I2C的時序和流程:
所以總線掛死可能會有幾個原因:
1、主機信號掛死了:
主機IO口損壞、I2C狀態機異常軟件死機
2、主機程序異常:
I2C通信需要主機來主導,主機軟件本身異常了I2C信號也不會繼續產生。
3、從機拉死了總線:
I2C是線與的,所以從機拉低后總線也掛了,主機無法再次拉高發起新的通信。這種情況一般在信號被干擾時從機丟失clock或者增加了clock導致雙方時序沒對齊,從機還維持住一個發送0 bit的狀態就把SDA拉低了。
首先原因1和2是和程序相關,I2C的狀態機流程較多,自行編寫驅動確實容易出現問題,只要使用成熟驅動就可以。大家可以直接使用紅楓派的I2C驅動就避免這類問題,紅楓派的驅動可靠性不比原廠驅動低,經受RTOS、多中斷、干擾等全方面打擊。
對于原因3,既然是干擾多了clock和少了clock導致從機維持拉低SDA的狀態,那我們補齊clock結束這次異常通信不就可以了?
其實這個方法在最新的I2C協議標準中也有說明,不管I2C當前丟失或增加幾個clcok,我們只要讓主機連續補齊9個clock,在9個clock內時序一定會補齊到ACK環節,此時主機維持SDA高狀態就可以讓這次通信以NACK進行結束,從機自然會釋放總線,這個比強制用推挽模式拉高SDA更安全合理。
那么這個異?;謴驮诩t楓派的驅動里也已經為大家考慮好了,當總線狀態出現異常時,驅動里會自動進行處理恢復總線。
那么軟件I2C的弊端在哪里呢?
軟件I2C一般通過IO口控制和延時進行模擬,這意味著整個通信過程會完全依靠并占用CPU,如果我們運行RTOS、或者有高頻中斷就會出現模擬時序過程被打斷,波形會出現頻率變化,波形中途停止等情況,一方面是降低通信效率,另外也可能導致主機沒有在關鍵時間采樣或者輸出數據,出現通信錯誤。
紅楓派開發板上板載了一個I2C的EEPROM,歡迎大家在軟件極其嚴苛、硬件I2C接口隨機進行干擾下驗證例程,體驗下穩得一批的硬件I2C。
-
單片機
+關注
關注
6008文章
44062瀏覽量
622631 -
嵌入式
+關注
關注
5001文章
18394瀏覽量
291024 -
硬件
+關注
關注
11文章
2943瀏覽量
65059 -
IIC
+關注
關注
11文章
287瀏覽量
37903 -
GD32
+關注
關注
7文章
351瀏覽量
23785
發布評論請先 登錄
相關推薦
評論