1. 從模式設(shè)計(jì)與總線魯棒性為什么時(shí)鐘延展和死鎖恢復(fù)是I2C從機(jī)的必修課做嵌入式開發(fā)的朋友對(duì)I2C總線肯定不陌生兩根線SDA、SCL掛一堆設(shè)備布線簡單、協(xié)議成熟幾乎是傳感器、EEPROM、OLED屏的標(biāo)配接口。但真正在項(xiàng)目里把I2C從機(jī)做到“穩(wěn)如老狗”的人并不多大部分教程只教你如何讀寫寄存器卻很少講清楚兩件事時(shí)鐘延展Clock Stretching到底該怎么落地以及總線死鎖Bus Deadlock發(fā)生后怎么恢復(fù)。我最近在做一個(gè)基于STM32的傳感器采集板主控通過I2C掛了三顆從設(shè)備一顆EEPROM、一顆光照傳感器、一塊0.96寸OLED。調(diào)試階段遇到了兩個(gè)非常典型的問題一是OLED在刷新大量數(shù)據(jù)時(shí)偶爾會(huì)拉低SCL不放導(dǎo)致主控直接卡死在等待ACK的狀態(tài)二是EEPROM在連續(xù)頁寫的時(shí)候如果主控時(shí)序太快從機(jī)來不及處理數(shù)據(jù)就會(huì)丟。這兩個(gè)問題的根源都指向同一個(gè)方向——從模式設(shè)計(jì)中對(duì)總線魯棒性的考慮不足。這篇文章我會(huì)從實(shí)際項(xiàng)目出發(fā)把時(shí)鐘延展的實(shí)現(xiàn)原理、從機(jī)狀態(tài)機(jī)的設(shè)計(jì)思路、死鎖檢測與恢復(fù)的完整方案講透。內(nèi)容會(huì)涉及I2C協(xié)議底層時(shí)序、GPIO模擬與硬件外設(shè)的取舍、狀態(tài)機(jī)設(shè)計(jì)模式在從機(jī)代碼中的應(yīng)用以及實(shí)測中踩過的坑。適合有一定I2C基礎(chǔ)、正在做多設(shè)備總線項(xiàng)目、或者被總線卡死問題折磨過的嵌入式開發(fā)者。如果你只會(huì)用HAL庫的HAL_I2C_Master_Transmit那這篇文章可能會(huì)讓你重新理解I2C從機(jī)端到底在干什么。2. 核心思路拆解從機(jī)不是“被動(dòng)挨打”時(shí)鐘延展是它的反擊手段2.1 I2C從機(jī)的真實(shí)處境為什么需要時(shí)鐘延展很多人對(duì)I2C的理解停留在“主控發(fā)起、從機(jī)應(yīng)答”的層面覺得從機(jī)就是個(gè)聽話的奴隸主控給時(shí)鐘它就跟著走。但實(shí)際情況是從機(jī)內(nèi)部往往有自己的處理節(jié)奏。比如EEPROM在收到一個(gè)字節(jié)后需要幾毫秒的時(shí)間把數(shù)據(jù)寫入存儲(chǔ)單元這段時(shí)間它無法響應(yīng)新的數(shù)據(jù)再比如OLED控制器在刷新顯存時(shí)內(nèi)部狀態(tài)機(jī)可能正忙如果主控這時(shí)候硬塞數(shù)據(jù)過來從機(jī)要么丟數(shù)據(jù)要么直接拉低總線表示“我還沒準(zhǔn)備好”。時(shí)鐘延展就是I2C協(xié)議給從機(jī)的一個(gè)合法“拖延”手段。具體做法是從機(jī)在需要更多處理時(shí)間時(shí)主動(dòng)把SCL線拉低并保持主控檢測到SCL被拉低后會(huì)進(jìn)入等待狀態(tài)直到從機(jī)釋放SCL才繼續(xù)產(chǎn)生時(shí)鐘脈沖。這個(gè)過程完全符合I2C規(guī)范不是bug而是feature。但問題在于很多硬件I2C外設(shè)對(duì)時(shí)鐘延展的支持并不完整。比如某些STM32系列的硬件I2C從機(jī)模式在時(shí)鐘延展期間如果主控發(fā)送了STOP條件從機(jī)會(huì)直接掛掉需要重新初始化。這就是為什么我在這個(gè)項(xiàng)目里最終選擇了GPIO模擬從機(jī)狀態(tài)機(jī)的方案雖然犧牲了一點(diǎn)速度但換來了對(duì)總線狀態(tài)的完全掌控。2.2 方案選型硬件I2C從機(jī) vs GPIO模擬從機(jī)先給一個(gè)直觀的對(duì)比表格這是我實(shí)測下來的結(jié)論對(duì)比項(xiàng)硬件I2C從機(jī)GPIO模擬從機(jī)時(shí)鐘延展支持部分系列支持但行為不一致完全可控想拉多久拉多久死鎖恢復(fù)需要重新初始化外設(shè)可能丟失狀態(tài)直接操作GPIO靈活恢復(fù)最高速率400kHz甚至1MHz通常100kHz~200kHzCPU占用低中斷驅(qū)動(dòng)高需要輪詢或邊沿中斷代碼復(fù)雜度低HAL庫直接調(diào)用高需要自己實(shí)現(xiàn)狀態(tài)機(jī)多設(shè)備兼容性受限于外設(shè)特性可針對(duì)每個(gè)設(shè)備定制時(shí)序我最終選擇GPIO模擬的原因很直接項(xiàng)目里的OLED對(duì)時(shí)序要求比較特殊硬件I2C在時(shí)鐘延展后經(jīng)常出現(xiàn)SCL釋放時(shí)機(jī)不對(duì)的問題導(dǎo)致OLED顯示花屏。換成GPIO模擬后我可以在從機(jī)狀態(tài)機(jī)里精確控制每一個(gè)時(shí)鐘沿的行為包括在什么條件下拉低SCL、拉低多長時(shí)間、什么時(shí)候釋放。2.3 狀態(tài)機(jī)設(shè)計(jì)模式在從機(jī)代碼中的落地從機(jī)代碼本質(zhì)上是一個(gè)事件驅(qū)動(dòng)的狀態(tài)機(jī)。I2C總線上的事件包括起始條件檢測、地址匹配、數(shù)據(jù)位采樣、ACK/NACK發(fā)送、停止條件檢測。用設(shè)計(jì)模式的話來說這是一個(gè)典型的**狀態(tài)模式State Pattern**應(yīng)用場景。我定義了幾個(gè)核心狀態(tài)IDLE總線空閑等待起始條件ADDR_MATCH收到地址字節(jié)判斷是否匹配本機(jī)地址RX_DATA接收數(shù)據(jù)字節(jié)準(zhǔn)備寫入緩沖區(qū)TX_DATA發(fā)送數(shù)據(jù)字節(jié)從緩沖區(qū)讀取CLOCK_STRETCH需要延展時(shí)鐘拉低SCLWAIT_STOP等待停止條件準(zhǔn)備回到IDLE每個(gè)狀態(tài)都有明確的進(jìn)入條件、執(zhí)行動(dòng)作和退出條件。比如從RX_DATA進(jìn)入CLOCK_STRETCH的條件是“接收緩沖區(qū)滿”或“需要處理時(shí)間”執(zhí)行動(dòng)作是“拉低SCL并啟動(dòng)定時(shí)器”退出條件是“定時(shí)器超時(shí)或處理完成”。這種設(shè)計(jì)的好處是死鎖恢復(fù)變得非常自然。如果狀態(tài)機(jī)在某個(gè)狀態(tài)停留超過預(yù)設(shè)閾值比如CLOCK_STRETCH超過100ms就觸發(fā)恢復(fù)流程強(qiáng)制釋放SCL和SDA發(fā)送9個(gè)時(shí)鐘脈沖嘗試復(fù)位總線然后重新初始化狀態(tài)機(jī)。整個(gè)過程不需要重啟MCU也不需要重新配置外設(shè)。3. 核心細(xì)節(jié)解析時(shí)鐘延展的時(shí)序計(jì)算與死鎖恢復(fù)的硬件操作3.1 時(shí)鐘延展的時(shí)序要求與參數(shù)計(jì)算時(shí)鐘延展不是隨便拉低SCL就行它必須滿足I2C規(guī)范里的時(shí)序要求。以標(biāo)準(zhǔn)模式100kHz為例SCL低電平時(shí)間最小為4.7μs高電平時(shí)間最小為4.0μs。從機(jī)拉低SCL后主控檢測到SCL為低會(huì)停止產(chǎn)生時(shí)鐘脈沖但主控內(nèi)部通常有一個(gè)超時(shí)計(jì)數(shù)器如果SCL被拉低超過一定時(shí)間不同主控不一樣STM32一般是25ms左右主控會(huì)認(rèn)為總線故障并報(bào)錯(cuò)。所以從機(jī)在時(shí)鐘延展時(shí)拉低SCL的時(shí)間不能超過主控的超時(shí)閾值。我的做法是在CLOCK_STRETCH狀態(tài)里啟動(dòng)一個(gè)定時(shí)器定時(shí)器周期設(shè)為10ms每次超時(shí)后檢查處理是否完成如果沒完成就繼續(xù)拉低但累計(jì)拉低時(shí)間超過20ms就強(qiáng)制釋放避免觸發(fā)主控超時(shí)。具體參數(shù)計(jì)算如下主控超時(shí)閾值假設(shè)為25ms查STM32參考手冊I2C_TIMEOUT寄存器安全余量留5ms所以從機(jī)最大拉低時(shí)間設(shè)為20ms定時(shí)器周期10ms這樣最多兩次超時(shí)后釋放釋放后行為如果處理仍未完成返回NACK讓主控重試注意不同主控的超時(shí)閾值差異很大比如某些Linux主控的I2C超時(shí)是1秒而一些低端MCU可能只有幾毫秒。實(shí)際項(xiàng)目中一定要先確認(rèn)主控的超時(shí)參數(shù)再設(shè)定從機(jī)的時(shí)鐘延展上限。3.2 死鎖的成因分析與檢測方法I2C死鎖的典型表現(xiàn)是SCL被某個(gè)設(shè)備持續(xù)拉低主控?zé)o法產(chǎn)生時(shí)鐘脈沖總線完全卡死。成因主要有三種從機(jī)在發(fā)送ACK時(shí)被復(fù)位從機(jī)正在拉低SDA表示ACK突然斷電或復(fù)位SDA保持低電平主控認(rèn)為總線忙。時(shí)鐘延展超時(shí)后從機(jī)未釋放SCL從機(jī)狀態(tài)機(jī)跑飛SCL一直被拉低。主控在從機(jī)準(zhǔn)備數(shù)據(jù)時(shí)發(fā)送了STOP從機(jī)狀態(tài)機(jī)處于中間狀態(tài)SCL和SDA的電平不確定。檢測死鎖的方法很簡單在總線空閑時(shí)主控沒有發(fā)起傳輸讀取SCL和SDA的電平。如果SCL為低說明有設(shè)備在拉低時(shí)鐘線這就是死鎖。我的代碼里在主循環(huán)中每100ms檢測一次if (HAL_GPIO_ReadPin(I2C_SCL_PORT, I2C_SCL_PIN) GPIO_PIN_RESET) { // 總線死鎖啟動(dòng)恢復(fù)流程 i2c_bus_recovery(); }3.3 死鎖恢復(fù)的硬件操作步驟恢復(fù)流程的核心是發(fā)送9個(gè)時(shí)鐘脈沖讓所有從機(jī)的狀態(tài)機(jī)復(fù)位到IDLE狀態(tài)。具體步驟如下配置SCL為推挽輸出SDA為輸入釋放SDA循環(huán)9次SCL拉低至少4.7μsSCL拉高至少4.0μs檢查SDA是否釋放如果釋放說明從機(jī)已經(jīng)退出數(shù)據(jù)發(fā)送狀態(tài)發(fā)送STOP條件SDA從低到高同時(shí)SCL為高重新初始化從機(jī)狀態(tài)機(jī)代碼實(shí)現(xiàn)void i2c_bus_recovery(void) { // 步驟1配置GPIO gpio_set_output(I2C_SCL_PORT, I2C_SCL_PIN); gpio_set_input(I2C_SDA_PORT, I2C_SDA_PIN); // 步驟2發(fā)送9個(gè)時(shí)鐘脈沖 for (int i 0; i 9; i) { gpio_write(I2C_SCL_PORT, I2C_SCL_PIN, 0); delay_us(5); gpio_write(I2C_SCL_PORT, I2C_SCL_PIN, 1); delay_us(5); } // 步驟3檢查SDA if (gpio_read(I2C_SDA_PORT, I2C_SDA_PIN) 0) { // SDA仍被拉低可能需要硬件檢查 return; } // 步驟4發(fā)送STOP條件 gpio_set_output(I2C_SDA_PORT, I2C_SDA_PIN); gpio_write(I2C_SDA_PORT, I2C_SDA_PIN, 0); delay_us(5); gpio_write(I2C_SCL_PORT, I2C_SCL_PIN, 1); delay_us(5); gpio_write(I2C_SDA_PORT, I2C_SDA_PIN, 1); delay_us(5); // 步驟5重新初始化狀態(tài)機(jī) i2c_slave_state IDLE; }提示9個(gè)時(shí)鐘脈沖是I2C規(guī)范推薦的做法因?yàn)橐粋€(gè)字節(jié)是8位加上ACK位正好9個(gè)時(shí)鐘。如果從機(jī)正在發(fā)送數(shù)據(jù)9個(gè)脈沖后它會(huì)完成當(dāng)前字節(jié)并釋放SDA。4. 實(shí)操過程從機(jī)狀態(tài)機(jī)的完整實(shí)現(xiàn)與調(diào)試記錄4.1 硬件連接與GPIO配置我的硬件平臺(tái)是STM32F103C8T6I2C從機(jī)使用PB6SCL和PB7SDA。這兩個(gè)引腳配置為開漏輸出外部接4.7kΩ上拉電阻到3.3V。開漏輸出的好處是任何設(shè)備都可以拉低總線但不會(huì)出現(xiàn)推挽輸出的短路問題。GPIO初始化代碼void i2c_slave_gpio_init(void) { GPIO_InitTypeDef GPIO_InitStruct {0}; __HAL_RCC_GPIOB_CLK_ENABLE(); // SCL和SDA都配置為開漏輸出 GPIO_InitStruct.Pin GPIO_PIN_6 | GPIO_PIN_7; GPIO_InitStruct.Mode GPIO_MODE_OUTPUT_OD; GPIO_InitStruct.Pull GPIO_NOPULL; GPIO_InitStruct.Speed GPIO_SPEED_FREQ_HIGH; HAL_GPIO_Init(GPIOB, GPIO_InitStruct); // 初始狀態(tài)釋放總線 HAL_GPIO_WritePin(GPIOB, GPIO_PIN_6 | GPIO_PIN_7, GPIO_PIN_SET); }這里有個(gè)細(xì)節(jié)開漏輸出模式下寫1是釋放總線寫0是拉低總線。讀取引腳電平時(shí)需要先寫1釋放再讀IDR寄存器。我見過有人直接讀ODR寄存器結(jié)果永遠(yuǎn)讀到0這就是沒理解開漏輸出的工作原理。4.2 狀態(tài)機(jī)主循環(huán)與中斷配合從機(jī)狀態(tài)機(jī)的運(yùn)行方式有兩種純輪詢和邊沿中斷輪詢。純輪詢的CPU占用太高我采用的是SCL下降沿中斷主循環(huán)處理的混合模式。SCL下降沿中斷里只做一件事記錄當(dāng)前狀態(tài)并設(shè)置一個(gè)標(biāo)志位。主循環(huán)檢測到標(biāo)志位后根據(jù)狀態(tài)執(zhí)行相應(yīng)的動(dòng)作。這樣中斷服務(wù)程序很短不會(huì)阻塞其他任務(wù)。void EXTI9_5_IRQHandler(void) { if (__HAL_GPIO_EXTI_GET_IT(GPIO_PIN_6) ! RESET) { __HAL_GPIO_EXTI_CLEAR_IT(GPIO_PIN_6); scl_falling_flag 1; } } void main_loop(void) { if (scl_falling_flag) { scl_falling_flag 0; i2c_slave_state_machine(); } // 其他任務(wù) }狀態(tài)機(jī)的核心邏輯void i2c_slave_state_machine(void) { switch (i2c_slave_state) { case IDLE: if (sda_is_low() scl_is_high()) { // 檢測到起始條件 i2c_slave_state ADDR_MATCH; bit_count 0; rx_byte 0; } break; case ADDR_MATCH: rx_byte (rx_byte 1) | sda_read(); bit_count; if (bit_count 8) { if ((rx_byte 0xFE) SLAVE_ADDR) { // 地址匹配發(fā)送ACK sda_low(); i2c_slave_state (rx_byte 0x01) ? TX_DATA : RX_DATA; } else { // 地址不匹配釋放總線 sda_high(); i2c_slave_state IDLE; } bit_count 0; } break; case RX_DATA: rx_byte (rx_byte 1) | sda_read(); bit_count; if (bit_count 8) { rx_buffer[rx_index] rx_byte; sda_low(); // 發(fā)送ACK bit_count 0; if (rx_index RX_BUFFER_SIZE) { i2c_slave_state CLOCK_STRETCH; } } break; case CLOCK_STRETCH: scl_low(); // 拉低SCL if (process_data() || stretch_timeout()) { scl_high(); // 釋放SCL i2c_slave_state RX_DATA; rx_index 0; } break; // 其他狀態(tài)... } }4.3 時(shí)鐘延展的實(shí)測波形與參數(shù)調(diào)整我用邏輯分析儀抓了時(shí)鐘延展的波形發(fā)現(xiàn)一個(gè)關(guān)鍵問題從機(jī)拉低SCL后主控并不是立刻停止時(shí)鐘而是會(huì)再發(fā)送一個(gè)完整的時(shí)鐘脈沖。這是因?yàn)橹骺卦赟CL高電平期間采樣SDA如果從機(jī)在SCL高電平期間拉低SCL主控可能已經(jīng)完成了采樣下一個(gè)時(shí)鐘周期才會(huì)檢測到SCL被拉低。所以從機(jī)拉低SCL的時(shí)機(jī)很關(guān)鍵必須在SCL低電平期間拉低這樣主控在下一個(gè)高電平周期就會(huì)檢測到SCL為低從而進(jìn)入等待狀態(tài)。我的代碼里是在SCL下降沿中斷里判斷是否需要延展如果需要就立刻拉低SCL這樣時(shí)機(jī)正好。實(shí)測波形顯示從機(jī)拉低SCL后主控在約2μs內(nèi)停止時(shí)鐘輸出SCL保持低電平直到從機(jī)釋放。整個(gè)延展過程持續(xù)了8ms主控沒有報(bào)超時(shí)錯(cuò)誤。4.4 死鎖恢復(fù)的現(xiàn)場記錄調(diào)試過程中我人為制造了一次死鎖在從機(jī)發(fā)送ACK時(shí)用調(diào)試器暫停CPU然后復(fù)位主控。結(jié)果SCL被從機(jī)拉低主控?zé)o法產(chǎn)生時(shí)鐘總線卡死?；謴?fù)流程的現(xiàn)場記錄主循環(huán)檢測到SCL為低觸發(fā)i2c_bus_recovery()發(fā)送9個(gè)時(shí)鐘脈沖邏輯分析儀顯示SDA在第7個(gè)脈沖后釋放發(fā)送STOP條件總線回到空閑狀態(tài)重新初始化狀態(tài)機(jī)主控恢復(fù)正常通信整個(gè)過程耗時(shí)約200μs沒有影響其他任務(wù)的運(yùn)行。如果沒有這個(gè)恢復(fù)機(jī)制就只能手動(dòng)斷電重啟這在工業(yè)現(xiàn)場是不可接受的。5. 常見問題與排查技巧實(shí)錄5.1 時(shí)鐘延展不生效的三種原因原因一主控不支持時(shí)鐘延展。有些低端MCU的硬件I2C外設(shè)不支持從機(jī)時(shí)鐘延展檢測到SCL被拉低后直接報(bào)總線錯(cuò)誤。解決辦法是換用GPIO模擬主控或者降低通信速率。原因二從機(jī)拉低SCL的時(shí)間太短。如果從機(jī)在SCL高電平期間拉低主控可能已經(jīng)完成了當(dāng)前位的采樣下一個(gè)時(shí)鐘周期才會(huì)檢測到。解決辦法是在SCL下降沿中斷里拉低SCL。原因三上拉電阻太大。如果上拉電阻是10kΩSCL的上升沿會(huì)變緩主控可能誤判SCL為低。解決辦法是換用4.7kΩ或更小的上拉電阻。5.2 死鎖恢復(fù)失敗的排查步驟現(xiàn)象可能原因排查方法發(fā)送9個(gè)脈沖后SDA仍為低從機(jī)硬件故障斷開從機(jī)測量SDA對(duì)地電阻恢復(fù)后通信仍失敗狀態(tài)機(jī)未正確復(fù)位檢查狀態(tài)機(jī)變量是否全部重置頻繁觸發(fā)恢復(fù)總線電容過大測量SCL上升時(shí)間減小上拉電阻恢復(fù)后數(shù)據(jù)錯(cuò)亂從機(jī)緩沖區(qū)未清空在恢復(fù)流程中清空所有緩沖區(qū)5.3 實(shí)操心得三個(gè)容易忽略的細(xì)節(jié)細(xì)節(jié)一SCL和SDA的初始化順序。上電時(shí)應(yīng)該先釋放SDA再釋放SCL最后配置為開漏輸出。如果順序反了可能產(chǎn)生一個(gè)假的起始條件導(dǎo)致從機(jī)誤觸發(fā)。細(xì)節(jié)二中斷優(yōu)先級(jí)。SCL下降沿中斷的優(yōu)先級(jí)不能太高否則會(huì)阻塞其他中斷也不能太低否則可能錯(cuò)過時(shí)鐘沿。我一般設(shè)置為中等優(yōu)先級(jí)比SysTick低比串口高。細(xì)節(jié)三時(shí)鐘延展的超時(shí)保護(hù)。從機(jī)拉低SCL的時(shí)間一定要有上限否則主控超時(shí)后從機(jī)還在拉低總線就徹底死了。我的做法是設(shè)置一個(gè)20ms的硬超時(shí)超時(shí)后強(qiáng)制釋放SCL并返回NACK。注意如果項(xiàng)目中同時(shí)存在多個(gè)I2C從機(jī)時(shí)鐘延展的時(shí)序要留足余量。比如EEPROM的頁寫時(shí)間最大5msOLED的刷新時(shí)間可能10ms從機(jī)的最大延展時(shí)間要大于這些值但又要小于主控的超時(shí)閾值。5.4 多設(shè)備總線上的地址沖突與仲裁項(xiàng)目里掛了三顆從機(jī)地址分別是0xA0EEPROM、0x23光照傳感器、0x3COLED。地址不沖突但調(diào)試時(shí)發(fā)現(xiàn)一個(gè)問題OLED在上電初始化時(shí)會(huì)拉低SDA約50ms這段時(shí)間如果主控去訪問EEPROM會(huì)收到NACK。解決辦法是在主控代碼里加一個(gè)上電延時(shí)等所有從機(jī)初始化完成后再開始通信。另外從機(jī)的地址匹配邏輯要嚴(yán)格只響應(yīng)完全匹配的地址不要用掩碼匹配否則可能誤響應(yīng)其他設(shè)備的地址。6. 從模式設(shè)計(jì)的擴(kuò)展思考把魯棒性做成默認(rèn)能力6.1 狀態(tài)機(jī)的可測試性設(shè)計(jì)從機(jī)狀態(tài)機(jī)寫完后怎么驗(yàn)證它真的能處理各種異常我的做法是注入故障用調(diào)試器強(qiáng)制修改狀態(tài)變量模擬狀態(tài)跑飛用信號(hào)發(fā)生器在SCL上疊加毛刺模擬噪聲干擾用可調(diào)電源緩慢降低電壓模擬供電不穩(wěn)。每次注入故障后觀察狀態(tài)機(jī)是否能自動(dòng)恢復(fù)到IDLE狀態(tài)。實(shí)測下來加了死鎖恢復(fù)機(jī)制后90%的異常都能在200μs內(nèi)自動(dòng)恢復(fù)剩下的10%需要重新初始化外設(shè)但不需要重啟MCU。6.2 時(shí)鐘延展與低功耗的平衡項(xiàng)目里有電池供電的需求MCU大部分時(shí)間在休眠。I2C從機(jī)在休眠時(shí)不能響應(yīng)總線所以主控在訪問前需要先發(fā)一個(gè)喚醒信號(hào)。我的做法是用一個(gè)額外的GPIO作為喚醒線主控拉低喚醒線后從機(jī)退出休眠并初始化I2C狀態(tài)機(jī)。時(shí)鐘延展在低功耗場景下要慎用因?yàn)槔蚐CL會(huì)阻止主控進(jìn)入低功耗模式。如果從機(jī)需要長時(shí)間處理數(shù)據(jù)更好的做法是返回NACK讓主控稍后重試而不是一直拉低SCL。6.3 從模式設(shè)計(jì)模式到其他總線的遷移這套狀態(tài)機(jī)死鎖恢復(fù)的思路不僅適用于I2C也可以遷移到SPI、UART等總線。SPI雖然沒有時(shí)鐘延展但從機(jī)可以通過拉低MISO或發(fā)送特定標(biāo)志位來表示“忙”UART可以通過流控信號(hào)RTS/CTS實(shí)現(xiàn)類似效果。核心思想是一樣的從機(jī)要有主動(dòng)表達(dá)“我還沒準(zhǔn)備好”的能力同時(shí)要有從異常狀態(tài)恢復(fù)的機(jī)制。把這兩個(gè)能力做成默認(rèn)配置而不是事后補(bǔ)丁總線的魯棒性會(huì)提升一個(gè)檔次。我在實(shí)際項(xiàng)目中的體會(huì)是I2C從機(jī)代碼的復(fù)雜度主要不在正常流程而在異常處理。時(shí)鐘延展和死鎖恢復(fù)這兩塊代碼量不大但調(diào)試時(shí)間占了整個(gè)I2C模塊的70%。建議在做類似項(xiàng)目時(shí)先把邏輯分析儀接上把各種異常場景都抓一遍波形再動(dòng)手寫代碼能少走很多彎路。