在一個(gè)評論中,看到網(wǎng)友對硬件I2C的討論,硬件I2C Busy找不到原因、軟件I2C穩(wěn)得一批。
那么為什么會(huì)出現(xiàn)I2C BUSY?硬件I2C真的不如軟件I2C嗎?怎么讓硬件I2C也穩(wěn)得一批,讓我們來一探究竟。
首先我們從I2C時(shí)序分析下I2C總線掛死是如何產(chǎn)生的。
我們來看下I2C的時(shí)序和流程:


所以總線掛死可能會(huì)有幾個(gè)原因:
1、主機(jī)信號掛死了:
主機(jī)IO口損壞、I2C狀態(tài)機(jī)異常軟件死機(jī)
2、主機(jī)程序異常:
I2C通信需要主機(jī)來主導(dǎo),主機(jī)軟件本身異常了I2C信號也不會(huì)繼續(xù)產(chǎn)生。
3、從機(jī)拉死了總線:
I2C是線與的,所以從機(jī)拉低后總線也掛了,主機(jī)無法再次拉高發(fā)起新的通信。這種情況一般在信號被干擾時(shí)從機(jī)丟失clock或者增加了clock導(dǎo)致雙方時(shí)序沒對齊,從機(jī)還維持住一個(gè)發(fā)送0 bit的狀態(tài)就把SDA拉低了。
首先原因1和2是和程序相關(guān),I2C的狀態(tài)機(jī)流程較多,自行編寫驅(qū)動(dòng)確實(shí)容易出現(xiàn)問題,只要使用成熟驅(qū)動(dòng)就可以。大家可以直接使用紅楓派的I2C驅(qū)動(dòng)就避免這類問題,紅楓派的驅(qū)動(dòng)可靠性不比原廠驅(qū)動(dòng)低,經(jīng)受RTOS、多中斷、干擾等全方面打擊。

對于原因3,既然是干擾多了clock和少了clock導(dǎo)致從機(jī)維持拉低SDA的狀態(tài),那我們補(bǔ)齊clock結(jié)束這次異常通信不就可以了?
其實(shí)這個(gè)方法在最新的I2C協(xié)議標(biāo)準(zhǔn)中也有說明,不管I2C當(dāng)前丟失或增加幾個(gè)clcok,我們只要讓主機(jī)連續(xù)補(bǔ)齊9個(gè)clock,在9個(gè)clock內(nèi)時(shí)序一定會(huì)補(bǔ)齊到ACK環(huán)節(jié),此時(shí)主機(jī)維持SDA高狀態(tài)就可以讓這次通信以NACK進(jìn)行結(jié)束,從機(jī)自然會(huì)釋放總線,這個(gè)比強(qiáng)制用推挽模式拉高SDA更安全合理。
那么這個(gè)異常恢復(fù)在紅楓派的驅(qū)動(dòng)里也已經(jīng)為大家考慮好了,當(dāng)總線狀態(tài)出現(xiàn)異常時(shí),驅(qū)動(dòng)里會(huì)自動(dòng)進(jìn)行處理恢復(fù)總線。

那么軟件I2C的弊端在哪里呢?
軟件I2C一般通過IO口控制和延時(shí)進(jìn)行模擬,這意味著整個(gè)通信過程會(huì)完全依靠并占用CPU,如果我們運(yùn)行RTOS、或者有高頻中斷就會(huì)出現(xiàn)模擬時(shí)序過程被打斷,波形會(huì)出現(xiàn)頻率變化,波形中途停止等情況,一方面是降低通信效率,另外也可能導(dǎo)致主機(jī)沒有在關(guān)鍵時(shí)間采樣或者輸出數(shù)據(jù),出現(xiàn)通信錯(cuò)誤。
紅楓派開發(fā)板上板載了一個(gè)I2C的EEPROM,歡迎大家在軟件極其嚴(yán)苛、硬件I2C接口隨機(jī)進(jìn)行干擾下驗(yàn)證例程,體驗(yàn)下穩(wěn)得一批的硬件I2C。
-
單片機(jī)
+關(guān)注
關(guān)注
6061文章
44914瀏覽量
646635 -
嵌入式
+關(guān)注
關(guān)注
5138文章
19524瀏覽量
314697 -
硬件
+關(guān)注
關(guān)注
11文章
3459瀏覽量
67176 -
IIC
+關(guān)注
關(guān)注
11文章
306瀏覽量
39135 -
GD32
+關(guān)注
關(guān)注
7文章
418瀏覽量
25135
發(fā)布評論請先 登錄
I2C總線通信原理 如何設(shè)計(jì)I2C總線電路
I2C總線的優(yōu)缺點(diǎn)分析
I2C總線與Arduino的接口示例
I2C總線的工作模式介紹
I2C總線故障排除技巧
I2C總線與單片機(jī)的連接
I2C總線設(shè)備地址設(shè)置方法
I2C總線應(yīng)用實(shí)例分析
RISC V的I2C操作
【GD32 MCU 入門教程】GD32 MCU 常見外設(shè)介紹(7)I2C 模塊介紹

評論