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