GD32 MCU硬件I2C不可靠不如軟件I2C？來看看紅楓派開發(fā)版的硬件I2C驅(qū)動如何做到穩(wěn)得一批

在一個評論中，看到網(wǎng)友對硬件I2C的討論，硬件I2C Busy找不到原因、軟件I2C穩(wěn)得一批。

那么為什么會出現(xiàn)I2C BUSY？硬件I2C真的不如軟件I2C嗎？怎么讓硬件I2C也穩(wěn)得一批，讓我們來一探究竟。

首先我們從I2C時序分析下I2C總線掛死是如何產(chǎn)生的。

我們來看下I2C的時序和流程：

所以總線掛死可能會有幾個原因：

1、主機信號掛死了：

主機IO口損壞、I2C狀態(tài)機異常軟件死機

2、主機程序異常：

I2C通信需要主機來主導，主機軟件本身異常了I2C信號也不會繼續(xù)產(chǎn)生。

3、從機拉死了總線：

I2C是線與的，所以從機拉低后總線也掛了，主機無法再次拉高發(fā)起新的通信。這種情況一般在信號被干擾時從機丟失clock或者增加了clock導致雙方時序沒對齊，從機還維持住一個發(fā)送0 bit的狀態(tài)就把SDA拉低了。

首先原因1和2是和程序相關(guān)，I2C的狀態(tài)機流程較多，自行編寫驅(qū)動確實容易出現(xiàn)問題，只要使用成熟驅(qū)動就可以。大家可以直接使用紅楓派的I2C驅(qū)動就避免這類問題，紅楓派的驅(qū)動可靠性不比原廠驅(qū)動低，經(jīng)受RTOS、多中斷、干擾等全方面打擊。

對于原因3，既然是干擾多了clock和少了clock導致從機維持拉低SDA的狀態(tài)，那我們補齊clock結(jié)束這次異常通信不就可以了？

其實這個方法在最新的I2C協(xié)議標準中也有說明，不管I2C當前丟失或增加幾個clcok，我們只要讓主機連續(xù)補齊9個clock，在9個clock內(nèi)時序一定會補齊到ACK環(huán)節(jié)，此時主機維持SDA高狀態(tài)就可以讓這次通信以NACK進行結(jié)束，從機自然會釋放總線，這個比強制用推挽模式拉高SDA更安全合理。

那么這個異常恢復在紅楓派的驅(qū)動里也已經(jīng)為大家考慮好了，當總線狀態(tài)出現(xiàn)異常時，驅(qū)動里會自動進行處理恢復總線。

那么軟件I2C的弊端在哪里呢？

軟件I2C一般通過IO口控制和延時進行模擬，這意味著整個通信過程會完全依靠并占用CPU，如果我們運行RTOS、或者有高頻中斷就會出現(xiàn)模擬時序過程被打斷，波形會出現(xiàn)頻率變化，波形中途停止等情況，一方面是降低通信效率，另外也可能導致主機沒有在關(guān)鍵時間采樣或者輸出數(shù)據(jù)，出現(xiàn)通信錯誤。

紅楓派開發(fā)板上板載了一個I2C的EEPROM，歡迎大家在軟件極其嚴苛、硬件I2C接口隨機進行干擾下驗證例程，體驗下穩(wěn)得一批的硬件I2C。