結論：?(即在模擬i2c主：在主設置SCL為高后，要超時判斷SCL是否為高，再發后面的時序）

?

現象(如下圖)：

由于在發送讀命令之后，即ACk之后，下面從設備需要準備數據時間，（大約10us,一個時鐘的時間），此時還在I2C中斷中，因此SCLK上是被拉低。由于主設備，并未檢查該SCLK信號，導致下一個數據的第一個時鐘信號被拉低，而不知道，而當做有效信號采樣，結果導致數據采用出錯；我們自己的主設備，采用硬件I2C，有判斷總線是否占用和超時機制，故沒有這個問題。

I2C的時鐘可能被從設備拉低，從示波器看好像主少發了時鐘（只有8個時鐘，實際應該9個，最前面一個被從設備拉低了），實際是從設備拉低，這時候主設備最好檢查時鐘信號變高后，再發時鐘信號脈沖！

（還在調試愛立信電源PMBUS問題：主發第九個時鐘未檢查總線，此時從設備把SCL拉低《此時從設備正在做相應數據處理，所以拉低總線》，導致ACK應答失敗，從示波器看好像少發了第九時鐘；方法發第九個時鐘的時候檢查SCL電平，發現它變高后，才發第九個時鐘）

?

原因：通信中，從設備由于某種原因（數據處理或準備）拉低SCL時鐘線（此時總線屬于被占用狀態），而主設備并未判斷SCL的是否為高空閑，而繼續通信，導致失敗

?

解決方法：在通信中，要隨時檢查SCL電平，當它為低的時候，需要超時等待，等它為高時候，再發新的SCL信號

?(即在代碼中，主設置SCL為高后，要超時判斷SCL是否為高，再發后面的時序）

另：個人認為硬件i2c有總線占用和超時判斷，相對于模擬i2c更好； 但硬件i2c容易出現死鎖的問題

?

Clock Stretching--http://www.i2c-bus.org/clock-stretching/

In an I2C communication the master device determines the clock speed. Unlike RS232 the I2C bus provides an explicit clock signal which relieves master and slave from synchronizing exactly to a predefined baud rate.

However, there are situations where an I2C slave is not able to co-operate with the clock speed given by the master and needs to slow down a little. This is done by a mechanism referred to asclock stretching.

An I2C slave is allowed to hold down the clock if it needs to reduce the bus speed. The master on the other hand is required to read back the clock signal after releasing it to high state and wait until the line has actually gone high.

Bandwith

Clockstretching sounds a bit odd but is common practice. However the total bandwith of the shared bus might be significantly decreased. So, especially for I2C buses shared by multiple devices it is important to estimate the impacts of clock-stretching. So do not make the slowest I2C device dominate your bus performance

總結

以上是生活随笔為你收集整理的i2c的时钟延展问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。