板主, Jason, 多謝, 了解了

I2C SPEC vs SMBUS 2.0 SPEC
如果沒記錯
I2C clock = 0 - 100K (fast speed 400K)
SMBUS clock = 10K - 100K
一般而言,大家會把I2C與SMBUS"視"為一樣的東西.
在於他們使用的protocol型式是一樣的...
當你斤斤計較timming時,I2C與SMBUS應視為不同spec
(本來就是不同的spec,只是有重疊,且一般應用不會出問題)

I2C因為操作頻率可以是0.(沒有timeout機制).
在實務上,如果有device出問題就會造成鎖死.或變很慢...
(基本上,這種情形都是有問題---沒人會故意設計成很慢回應)

(smbus 2.0 spec page:11)
所以在SMBUS中,就規定操作頻率最低為10K
FSMB SMBus Operating Frequency 10 100 KHz See note 1

因此clock High + Low 要在最低頻率10K(100us)內完成.

請參考smbus 2.0 spec, page22.
Figure 4-7: Periodic clock stretching by a slave SMBus device
最上方有一個 1/fSMB,MAX = 100us

I2C Slave 在接收主要是以中斷方式處理，一但收完一個 Byte 進入中斷 SCL 會被硬體拉成 Low，軟體只要將此 Byte 拿走後並在離開中斷前將 SCL 放開即可。PIC16F887 在處理I2C Slave 的時間是很短的，除非是你在中斷裡花太多的時間去處理資料，這樣的中斷處理方式就不對了。所以一般 I2C 接收中斷應只花 20 個指令週期已內先接收資料並儲存，其餘的處理就交給上層的程式。

謝謝

我接收到一個byte後, 需要161us處理(wait state)(PIC16F887)

於I2C SPEC 2.1上, 圖示敍述的wait state是在一個byte+ACK共9個clock後的等待時間, 是沒有錯,

但我的客戶又拿SMBUS 2.0 SPEC的4.3.3來說, wait state不能太久, SPEC中真的很明確定出時間不能大於多少嗎??? 解釋看起來很模糊耶

...the master into a wait state until the slave is ready for the next byte transfer in a type of handshake procedure.

嗯!! 是我沒看仔細看spec, 剛去查一下...果然有wait state.
因為I2C 的操作頻率為 0 - 100K (high speed 400K).
所以可以"無止境"的waitting.

Slave 端如果收完一個 Byte 的資料覺得需要時間處理的話是可以直接將 SCL 拉成 Low 讓 Master 等一下再傳送下一筆的資料的。當然在一般模式下 SCL & SDA 都是由Master 來掌控的，但 Slave 要與 Master 做Handshake 時是可以用拉 SCL 的方式來控制 Master 傳送資料的速度。

如果,沒記錯!!!
SCL是只有master才有"控制"權,slave device"不應該"控制 SCL,
所有SCL都是master送出來的!!!
除非是multi-master,不然不應該有這種問題.

SCL & SDA 在架構上都屬於 Open Collector, 試問一下如果 Slave 一值將 SCL 拉成 ，Master 有何辦法將 SCL 這支腳便成High 呢! 所以SCL被拉成Low 如果拉住的人不放你有耐他何? 因為是 Open Drain 嗎!

大家好:
請問I2C的 "wait state" SPEC有提到可以使用, 但無規範SCL接LOW的時間長短, 是否不管接LOW多久, master都要等, 直到release SCL line呢?

煩請知道的解一下, 謝謝!!