1. I2C 在嵌入式驅(qū)動開發(fā)中的真實定位I2C 總線在嵌入式圈子里有個很尷尬的地位幾乎每個 MCU 都帶幾乎每個項目都會用到但真正把它寫穩(wěn)、寫透的人并不多。大部分人的 I2C 經(jīng)驗停留在“調(diào)通一個 OLED”或者“讀一個 EEPROM”的層面一旦遇到多設(shè)備掛載、時鐘拉伸、總線死鎖、休眠喚醒后設(shè)備失聯(lián)這些場景就開始抓瞎。這一期我想把 I2C 驅(qū)動開發(fā)這件事從頭到尾捋一遍。不是那種“I2C 有兩根線一根 SDA 一根 SCL”的科普而是從實際項目出發(fā)講清楚在嵌入式 Linux 和裸機環(huán)境下I2C 驅(qū)動到底該怎么設(shè)計、怎么調(diào)試、怎么避坑。涉及的內(nèi)容會覆蓋 I2C 通信協(xié)議的本質(zhì)、時序細(xì)節(jié)、Linux 下的 i2c-dev 和 i2c-client 兩種驅(qū)動模型、常見外設(shè)EEPROM、OLED、傳感器、編碼器、數(shù)字電位器的讀寫套路以及那些文檔里不會寫但實際項目中一定會遇到的坑。適合的讀者是已經(jīng)能點亮 LED、跑通過串口、對 GPIO 和中斷有基本概念準(zhǔn)備往驅(qū)動層深入的嵌入式開發(fā)者。如果你還在糾結(jié)寄存器怎么配建議先把 GPIO 和時鐘樹搞清楚再來看這篇。I2C 驅(qū)動開發(fā)的核心難點不在協(xié)議本身而在于對時序的精確控制和對異常狀態(tài)的恢復(fù)能力這兩點貫穿全文。2. I2C 協(xié)議層那些被忽略的時序細(xì)節(jié)2.1 起始、停止與重復(fù)起始的實際含義I2C 的物理層很簡單SDA 和 SCL 兩根線加上拉電阻。但協(xié)議層的細(xì)節(jié)決定了你的驅(qū)動能不能在復(fù)雜環(huán)境下穩(wěn)定運行。起始條件START的定義是SCL 為高電平時SDA 從高變低。停止條件STOP是SCL 為高電平時SDA 從低變高。這兩個條件必須由主機產(chǎn)生從機永遠(yuǎn)不能主動發(fā)起。重復(fù)起始Repeated START是很多人忽略的一個點。它的時序和普通起始一樣但它出現(xiàn)在一次傳輸?shù)闹虚g而不是總線空閑時。為什么需要它考慮這樣一個場景你要讀一個 EEPROM 的某個地址標(biāo)準(zhǔn)流程是先寫設(shè)備地址加寫標(biāo)志再寫內(nèi)存地址然后發(fā)起重復(fù)起始再寫設(shè)備地址加讀標(biāo)志最后讀數(shù)據(jù)。如果沒有重復(fù)起始你必須在寫完之后發(fā)一個停止條件再重新發(fā)起始條件。這中間總線會短暫空閑如果系統(tǒng)里有多個主機就可能被其他主機搶走總線。重復(fù)起始保證了整個讀操作是一個原子操作不會被中斷。在實際驅(qū)動代碼里很多硬件 I2C 控制器會自動處理重復(fù)起始你只需要在傳輸結(jié)構(gòu)里把兩個消息連續(xù)提交即可。但軟件模擬 I2C 的時候必須手動實現(xiàn)這個時序否則讀 EEPROM 會失敗。我見過不少人用軟件 I2C 讀 EEPROM 讀不出來最后發(fā)現(xiàn)就是漏了重復(fù)起始。2.2 時鐘拉伸從機的“暫停鍵”時鐘拉伸Clock Stretching是 I2C 協(xié)議里一個非常關(guān)鍵但經(jīng)常被忽視的機制。它允許從機在還沒準(zhǔn)備好數(shù)據(jù)的時候把 SCL 線拉低強制主機等待。這相當(dāng)于從機按下了暫停鍵主機必須等到從機釋放 SCL 之后才能繼續(xù)產(chǎn)生時鐘。為什么需要這個機制因為 I2C 是同步通信主機產(chǎn)生時鐘從機被動響應(yīng)。但有些從機處理速度慢比如某些傳感器完成一次 ADC 轉(zhuǎn)換需要時間或者 EEPROM 在寫周期內(nèi)不響應(yīng)。如果沒有時鐘拉伸主機按自己的節(jié)奏發(fā)時鐘從機跟不上就會丟數(shù)據(jù)。問題在于不是所有主機都支持時鐘拉伸。很多 MCU 的硬件 I2C 外設(shè)對時鐘拉伸的處理有 bug或者根本不支持。比如某些早期的 STM32 型號硬件 I2C 在從機拉伸時鐘時會出錯。這時候要么換軟件模擬要么在驅(qū)動層加延時來規(guī)避。我在實際項目里遇到過 BH1750 光照傳感器在低功耗模式下需要時鐘拉伸但 STM32F1 的硬件 I2C 處理不好最后改成軟件 I2C 才穩(wěn)定。注意如果你的 I2C 總線上掛了多個從機時鐘拉伸的兼容性要逐個確認(rèn)。一個從機拉伸時鐘總線上所有設(shè)備都會受影響。2.3 數(shù)據(jù)幀格式與 ACK/NACK 的邊界情況I2C 的數(shù)據(jù)幀格式是每個字節(jié) 8 位高位先發(fā)后面跟一個 ACK/NACK 位。發(fā)送方釋放 SDA接收方拉低 SDA 表示 ACK保持高電平表示 NACK。這里有幾個邊界情況需要特別注意。第一個是地址幀和數(shù)據(jù)幀的 ACK 來源不同。地址幀的 ACK 由被尋址的從機產(chǎn)生數(shù)據(jù)幀的 ACK 由接收方產(chǎn)生。寫操作時主機發(fā)數(shù)據(jù)從機回 ACK讀操作時從機發(fā)數(shù)據(jù)主機回 ACK。最后一個字節(jié)讀完后主機必須回 NACK然后發(fā)停止條件。如果主機在最后一個字節(jié)回了 ACK從機會繼續(xù)發(fā)下一個字節(jié)導(dǎo)致總線掛死。第二個是 NACK 的處理。主機收到 NACK 通常意味著從機沒準(zhǔn)備好或者地址不對。在驅(qū)動層收到 NACK 后應(yīng)該立即發(fā)停止條件釋放總線而不是繼續(xù)發(fā)時鐘。我見過有人在收到 NACK 后還在循環(huán)發(fā)數(shù)據(jù)結(jié)果整個總線被拉死所有設(shè)備都失聯(lián)。第三個是總線仲裁。多主機環(huán)境下兩個主機同時發(fā)起傳輸誰先拉低 SDA 誰贏。輸?shù)哪且环揭⒓赐顺鲛D(zhuǎn)為從機模式。這個機制在單主機系統(tǒng)里用不到但理解它有助于你明白為什么 I2C 的 SDA 和 SCL 必須用開漏輸出。3. 裸機 I2C 驅(qū)動從寄存器到狀態(tài)機3.1 硬件 I2C 與軟件模擬的選型邏輯裸機環(huán)境下做 I2C 驅(qū)動第一個決策就是硬件 I2C 還是軟件模擬。硬件 I2C 的優(yōu)點是速度快、CPU 占用低、時序精確。缺點是不同 MCU 的硬件 I2C 外設(shè)差異大有些型號的硬件 I2C 有已知 bug調(diào)試起來很痛苦。軟件模擬的優(yōu)點是移植性好、時序可控、不受硬件外設(shè)限制。缺點是速度慢、CPU 占用高、時序精度依賴延時函數(shù)。我的選型原則是這樣的如果 MCU 的硬件 I2C 外設(shè)成熟穩(wěn)定比如 STM32F4 系列、ESP32 系列優(yōu)先用硬件 I2C。如果硬件 I2C 有已知問題比如 STM32F1 的某些型號或者需要非常特殊的時序比如某些非標(biāo)準(zhǔn) I2C 設(shè)備用軟件模擬。另外如果 I2C 總線上有需要時鐘拉伸的設(shè)備而硬件 I2C 不支持也只能用軟件模擬。軟件模擬 I2C 的代碼結(jié)構(gòu)通常是一個狀態(tài)機每個狀態(tài)對應(yīng)一個時序單元。比如起始條件、發(fā)送字節(jié)、接收字節(jié)、發(fā)送 ACK、接收 ACK、停止條件。每個狀態(tài)里控制 SDA 和 SCL 的電平然后延時半個周期。延時的精度決定了 I2C 的實際速率。標(biāo)準(zhǔn)模式 100kHz快速模式 400kHz高速模式 3.4MHz。軟件模擬一般只能做到 100kHz 左右再快延時就不準(zhǔn)了。3.2 狀態(tài)機設(shè)計避免阻塞式延時很多人的軟件 I2C 代碼是阻塞式的發(fā)一個字節(jié)就死等 ACK等不到就卡在那里。這在簡單項目里能用但在復(fù)雜系統(tǒng)里是災(zāi)難。如果從機沒接好或者地址錯了整個系統(tǒng)就卡死了。正確的做法是把 I2C 傳輸設(shè)計成狀態(tài)機每個狀態(tài)執(zhí)行一小步然后返回。主循環(huán)或者定時器中斷里輪詢狀態(tài)機超時了就報錯退出。這樣即使從機沒響應(yīng)系統(tǒng)也不會卡死。狀態(tài)機的狀態(tài)可以這樣劃分IDLE、START、SEND_ADDR、CHECK_ACK、SEND_DATA、RECV_DATA、SEND_ACK、STOP、ERROR。每個狀態(tài)里只做一個動作然后根據(jù)結(jié)果跳轉(zhuǎn)到下一個狀態(tài)。超時機制是必須的。每個狀態(tài)都有一個超時計數(shù)器超過閾值就跳到 ERROR 狀態(tài)發(fā)停止條件釋放總線。超時閾值根據(jù) I2C 速率來定100kHz 下一個字節(jié)大概 90 微秒超時設(shè) 1 毫秒足夠了。3.3 中斷驅(qū)動與 DMA 的取舍硬件 I2C 可以用中斷或者 DMA 來驅(qū)動。中斷方式下每個字節(jié)傳輸完成產(chǎn)生一個中斷CPU 在中斷里處理下一個字節(jié)。DMA 方式下CPU 只需要配置好傳輸參數(shù)DMA 控制器自動搬運數(shù)據(jù)傳輸完成后產(chǎn)生一個中斷。中斷方式的優(yōu)點是實現(xiàn)簡單適合小數(shù)據(jù)量傳輸。缺點是每個字節(jié)都要進中斷CPU 占用高。DMA 方式的優(yōu)點是 CPU 占用低適合大數(shù)據(jù)量傳輸比如讀寫 EEPROM 的連續(xù)頁。缺點是實現(xiàn)復(fù)雜需要處理 DMA 和 I2C 的同步問題。我的建議是如果傳輸數(shù)據(jù)量小于 16 字節(jié)用中斷方式就夠了。如果大于 16 字節(jié)考慮用 DMA。但要注意I2C 的 DMA 傳輸和 SPI 不同I2C 有地址幀、ACK 位這些額外的時序DMA 控制器不一定能自動處理。很多 MCU 的 I2C DMA 只支持?jǐn)?shù)據(jù)階段的搬運地址和 ACK 還是要 CPU 參與。所以實際用起來I2C DMA 的收益沒有 SPI DMA 那么明顯。4. 嵌入式 Linux 下的 I2C 驅(qū)動模型4.1 i2c-dev用戶態(tài)直接操作總線嵌入式 Linux 下操作 I2C 有兩種方式i2c-dev 和 i2c-client。i2c-dev 是把 I2C 適配器暴露成字符設(shè)備用戶態(tài)程序通過 ioctl 直接發(fā)起 I2C 傳輸。這種方式適合快速驗證和簡單應(yīng)用不需要寫內(nèi)核驅(qū)動。使用 i2c-dev 的流程是這樣的打開 /dev/i2c-N 設(shè)備文件然后用 I2C_SLAVE ioctl 設(shè)置從機地址接著用 read/write 或者 I2C_RDWR ioctl 進行數(shù)據(jù)傳輸。I2C_RDWR 是最靈活的可以一次提交多個消息支持重復(fù)起始。#include linux/i2c-dev.h #include linux/i2c.h #include fcntl.h #include sys/ioctl.h #include unistd.h int fd open(/dev/i2c-1, O_RDWR); ioctl(fd, I2C_SLAVE, 0x50); struct i2c_msg msgs[2]; unsigned char addr_buf[1] {0x00}; unsigned char data_buf[16]; msgs[0].addr 0x50; msgs[0].flags 0; msgs[0].len 1; msgs[0].buf addr_buf; msgs[1].addr 0x50; msgs[1].flags I2C_M_RD; msgs[1].len 16; msgs[1].buf data_buf; struct i2c_rdwr_ioctl_data rdwr; rdwr.msgs msgs; rdwr.nmsgs 2; ioctl(fd, I2C_RDWR, rdwr);這段代碼讀 EEPROM 的 0x00 地址開始的 16 個字節(jié)。兩個消息連續(xù)提交第一個寫內(nèi)存地址第二個讀數(shù)據(jù)中間自動插入重復(fù)起始。這是 i2c-dev 最常用的模式。i2c-dev 的優(yōu)點是簡單直接不需要編譯內(nèi)核模塊。缺點是每次傳輸都要進內(nèi)核開銷大而且用戶態(tài)程序要自己處理錯誤和重試。適合調(diào)試階段和簡單應(yīng)用不適合高性能場景。4.2 i2c-client內(nèi)核態(tài)驅(qū)動框架i2c-client 是內(nèi)核態(tài)的 I2C 驅(qū)動模型。你需要實現(xiàn)一個 i2c_driver 結(jié)構(gòu)體注冊到 I2C 核心層然后實現(xiàn) probe、remove、以及具體的讀寫函數(shù)。這種方式適合需要在內(nèi)核態(tài)頻繁訪問 I2C 設(shè)備的場景比如觸摸屏、傳感器、電源管理芯片。i2c-client 驅(qū)動的核心是 i2c_transfer 函數(shù)它和 i2c-dev 的 I2C_RDWR 類似也是提交一組 i2c_msg。區(qū)別在于 i2c_transfer 是在內(nèi)核態(tài)調(diào)用的不需要經(jīng)過字符設(shè)備層。static int mydev_read(struct i2c_client *client, u8 reg, u8 *buf, int len) { struct i2c_msg msgs[2]; int ret; msgs[0].addr client-addr; msgs[0].flags 0; msgs[0].len 1; msgs[0].buf reg; msgs[1].addr client-addr; msgs[1].flags I2C_M_RD; msgs[1].len len; msgs[1].buf buf; ret i2c_transfer(client-adapter, msgs, 2); if (ret 0) return ret; return 0; }i2c-client 驅(qū)動需要在設(shè)備樹或者板級文件里描述設(shè)備信息包括 I2C 總線號、從機地址、中斷引腳等。內(nèi)核啟動時會根據(jù)這些信息匹配驅(qū)動調(diào)用 probe 函數(shù)。probe 函數(shù)里初始化設(shè)備注冊字符設(shè)備或者 input 設(shè)備供用戶態(tài)使用。i2c-client 的優(yōu)點是性能好、可以處理中斷、可以和其他內(nèi)核子系統(tǒng)集成。缺點是需要編譯內(nèi)核模塊調(diào)試起來比用戶態(tài)麻煩。我的經(jīng)驗是如果只是讀個傳感器數(shù)據(jù)用 i2c-dev 就夠了如果要處理中斷、要做電源管理、要和其他驅(qū)動交互就必須用 i2c-client。4.3 設(shè)備樹中的 I2C 節(jié)點配置設(shè)備樹是嵌入式 Linux 描述硬件的方式。I2C 設(shè)備在設(shè)備樹里的節(jié)點通常掛在 I2C 控制器節(jié)點下面。比如i2c1 { status okay; clock-frequency 100000; eeprom50 { compatible atmel,24c02; reg 0x50; }; oled3c { compatible solomon,ssd1306; reg 0x3c; }; };clock-frequency 指定 I2C 總線速率標(biāo)準(zhǔn)模式 100kHz快速模式 400kHz。reg 屬性指定從機地址。compatible 屬性用于匹配驅(qū)動。這里有個坑I2C 從機地址在設(shè)備樹里是 7 位地址不包括讀寫位。但有些數(shù)據(jù)手冊給的地址是 8 位的包含了讀寫位。比如 SSD1306 的數(shù)據(jù)手冊寫從機地址是 0x78這是 8 位地址實際 7 位地址是 0x3C。設(shè)備樹里要填 0x3C不是 0x78。我見過不少人在這里填錯導(dǎo)致驅(qū)動匹配不上。另一個坑是地址沖突。I2C 總線上每個從機地址必須唯一。如果兩個設(shè)備地址相同總線會出問題。有些設(shè)備可以通過引腳配置地址比如 EEPROM 的 A0/A1/A2 引腳。設(shè)計硬件的時候就要規(guī)劃好地址分配避免沖突。5. 典型外設(shè)的 I2C 讀寫套路5.1 EEPROM頁寫與寫周期等待EEPROM 是最經(jīng)典的 I2C 設(shè)備也是學(xué)習(xí) I2C 驅(qū)動的最好樣本。以 AT24C02 為例容量 2Kbit即 256 字節(jié)頁大小 8 字節(jié)。讀操作很簡單寫內(nèi)存地址然后讀數(shù)據(jù)。寫操作稍微復(fù)雜分字節(jié)寫和頁寫。字節(jié)寫是寫一個內(nèi)存地址加一個字節(jié)數(shù)據(jù)。頁寫是寫一個內(nèi)存地址加多個字節(jié)數(shù)據(jù)但不能跨頁。AT24C02 的頁大小是 8 字節(jié)如果你從地址 0x06 開始寫 4 個字節(jié)會寫到 0x06、0x07、0x00、0x01因為地址在頁內(nèi)回繞了。這是 EEPROM 的一個特性也是容易踩的坑。寫操作完成后EEPROM 進入內(nèi)部寫周期通常 5 毫秒。在這期間EEPROM 不響應(yīng)任何 I2C 命令。如果你緊接著發(fā)起下一次寫操作會收到 NACK。正確的做法是寫完之后等待 5 毫秒或者用“應(yīng)答輪詢”的方式反復(fù)發(fā)起起始條件加設(shè)備地址直到收到 ACK 為止。void eeprom_wait_ready(int fd, uint8_t addr) { uint8_t dummy; while (1) { if (i2c_read(fd, addr, dummy, 1) 0) break; usleep(100); } }應(yīng)答輪詢比固定延時更高效因為寫周期可能提前完成。但要注意有些 EEPROM 在寫周期內(nèi)會拉低 SCL 做時鐘拉伸而不是回 NACK。這時候主機要支持時鐘拉伸才能正確等待。5.2 OLED 屏命令與數(shù)據(jù)的分界SSD1306 驅(qū)動的 OLED 屏是 I2C 設(shè)備里比較特殊的一類因為它需要區(qū)分命令和數(shù)據(jù)。SSD1306 的 I2C 傳輸格式是第一個字節(jié)是控制字節(jié)0x00 表示后面跟的是命令0x40 表示后面跟的是數(shù)據(jù)。然后才是實際的內(nèi)容。void oled_write_cmd(int fd, uint8_t cmd) { uint8_t buf[2] {0x00, cmd}; write(fd, buf, 2); } void oled_write_data(int fd, uint8_t data) { uint8_t buf[2] {0x40, data}; write(fd, buf, 2); }初始化 SSD1306 需要發(fā)送一系列命令包括設(shè)置對比度、顯示模式、掃描方向、時鐘分頻等。這些命令的順序不能亂否則屏幕不亮或者顯示異常。我建議直接參考廠商提供的初始化序列不要自己瞎試。0.9 寸 OLED 和 1.3 寸 OLED 的驅(qū)動芯片可能不同。0.9 寸通常是 SSD13061.3 寸通常是 SH1106。SH1106 的顯存是 132x64但屏幕只有 128x64所以每頁有 2 個字節(jié)的偏移。如果你用 SSD1306 的驅(qū)動去驅(qū)動 SH1106顯示會偏移兩列。這個坑我在項目里踩過調(diào)了半天才發(fā)現(xiàn)是驅(qū)動芯片不兼容。5.3 傳感器BH1750 與 AS5600 的讀取差異BH1750 是光照傳感器I2C 地址 0x23ADDR 引腳接地或 0x5CADDR 接 VCC。它的讀取流程是發(fā)送測量命令等待測量完成然后讀 2 個字節(jié)的數(shù)據(jù)。測量時間取決于測量模式連續(xù)高分辨率模式需要 120 毫秒左右。AS5600 是磁編碼器I2C 地址 0x36。它的讀取流程是直接讀角度寄存器得到 12 位的角度值。AS5600 支持硬件 I2C 和軟件 I2C但硬件 I2C 讀取時要注意時序因為 AS5600 的寄存器地址是 16 位的需要發(fā)送兩個字節(jié)的地址。uint16_t as5600_read_angle(int fd) { uint8_t reg[2] {0x0E, 0x00}; uint8_t data[2]; struct i2c_msg msgs[2]; msgs[0].addr 0x36; msgs[0].flags 0; msgs[0].len 2; msgs[0].buf reg; msgs[1].addr 0x36; msgs[1].flags I2C_M_RD; msgs[1].len 2; msgs[1].buf data; i2c_transfer(fd, msgs, 2); return (data[0] 8) | data[1]; }AS5600 的角度寄存器是 0x0E12 位數(shù)據(jù)高 4 位在 0x0E低 8 位在 0x0F。讀出來之后要屏蔽掉高 4 位的無效數(shù)據(jù)。5.4 數(shù)字電位器與 DAC通過 I2C 調(diào)節(jié)電壓用 I2C 數(shù)字電位器或者 DAC 來調(diào)節(jié) DC-DC 的反饋引腳電壓是一個很實用的技巧。DC-DC 的輸出電壓由反饋引腳的分壓電阻決定。如果你在分壓電阻上并聯(lián)一個數(shù)字電位器就可以通過 I2C 動態(tài)調(diào)節(jié)輸出電壓。比如 MCP4725 是 I2C DAC12 位分辨率地址 0x60。它的輸出接一個電阻到 DC-DC 的反饋引腳就可以控制輸出電壓。寫 DAC 的流程是發(fā)送快速寫命令然后發(fā)送 12 位數(shù)據(jù)。void mcp4725_set(int fd, uint16_t value) { uint8_t buf[3]; buf[0] 0x40; buf[1] (value 4) 0xFF; buf[2] (value 4) 0xF0; write(fd, buf, 3); }這個方案的關(guān)鍵是計算電阻值。假設(shè) DC-DC 的反饋電壓是 0.8V上分壓電阻是 10k下分壓電阻是 2k輸出電壓是 0.8 * (102) / 2 4.8V。如果你在 2k 電阻上并聯(lián)一個數(shù)字電位器調(diào)節(jié)電位器的阻值就可以改變下分壓電阻的有效值從而改變輸出電壓。具體計算要用并聯(lián)電阻公式這里不展開。6. 那些讓你加班到凌晨的 I2C 坑6.1 總線死鎖從機拉低 SDA 不放I2C 總線死鎖是最常見也最頭疼的問題?，F(xiàn)象是 SDA 一直被拉低主機發(fā)不了起始條件所有設(shè)備都失聯(lián)。原因通常是從機在傳輸過程中被復(fù)位或者斷電導(dǎo)致它還在等待時鐘但主機已經(jīng)放棄了傳輸。解決方法是手動模擬時鐘脈沖讓從機把剩下的數(shù)據(jù)發(fā)完釋放 SDA。具體操作是把 SCL 配置為 GPIO 輸出發(fā)送 9 個時鐘脈沖然后發(fā)一個停止條件。如果從機是正常的它會在第 9 個時鐘后釋放 SDA。void i2c_bus_recover(int scl_pin, int sda_pin) { gpio_set_output(scl_pin); gpio_set_input(sda_pin); for (int i 0; i 9; i) { gpio_set_low(scl_pin); udelay(5); gpio_set_high(scl_pin); udelay(5); } gpio_set_output(sda_pin); gpio_set_low(sda_pin); udelay(5); gpio_set_high(scl_pin); udelay(5); gpio_set_high(sda_pin); }這個恢復(fù)流程在 Linux 下有現(xiàn)成的實現(xiàn)叫 i2c-gpio-recover。在設(shè)備樹里配置 gpios 屬性內(nèi)核會在總線死鎖時自動調(diào)用恢復(fù)流程。6.2 休眠喚醒后 I2C 設(shè)備失聯(lián)ESP32 休眠喚醒后 I2C 設(shè)備失聯(lián)是一個經(jīng)典問題。原因是休眠時 I2C 控制器斷電喚醒后沒有重新初始化。解決方法是在喚醒后重新配置 I2C 控制器包括時鐘、引腳、速率。另一個可能的原因是休眠時 SDA 或 SCL 被拉低喚醒后從機處于異常狀態(tài)。這時候需要執(zhí)行總線恢復(fù)流程。ESP32 的 I2C 驅(qū)動有一個 i2c_reset_tx_fifo 和 i2c_reset_rx_fifo 函數(shù)可以在喚醒后調(diào)用。還有一種情況是休眠時從機也斷電了喚醒后從機需要重新初始化。比如 OLED 屏喚醒后需要重新發(fā)送初始化命令。這個要在應(yīng)用層處理驅(qū)動層管不了。6.3 上拉電阻選型不是隨便放一個 4.7k 就行I2C 的上拉電阻選型經(jīng)常被忽視。很多人直接抄別人的原理圖放兩個 4.7k 電阻就完事了。但實際上上拉電阻的阻值要根據(jù)總線速率、總線電容、電源電壓來計算。上拉電阻的最大值由上升時間決定。I2C 標(biāo)準(zhǔn)規(guī)定標(biāo)準(zhǔn)模式下上升時間不超過 1000 納秒快速模式下不超過 300 納秒。上升時間 t R * C其中 R 是上拉電阻C 是總線電容?？偩€電容包括 PCB 走線電容、引腳電容、設(shè)備電容通常 10 到 50 皮法。假設(shè)總線電容 50 皮法快速模式上升時間 300 納秒那么 R 300ns / 50pF 6k。所以上拉電阻不能大于 6k。最小值由灌電流決定。I2C 標(biāo)準(zhǔn)規(guī)定標(biāo)準(zhǔn)模式下灌電流不超過 3 毫安快速模式下不超過 6 毫安。電源電壓 3.3V灌電流 3 毫安那么 R 3.3V / 3mA 1.1k。所以上拉電阻在 1.1k 到 6k 之間。4.7k 是一個折中值適合 100kHz 的總線速率和較小的總線電容。如果你的總線速率是 400kHz或者總線電容較大4.7k 可能就太大了導(dǎo)致上升沿變緩?fù)ㄐ攀?。這時候要換小一點的電阻比如 2.2k。6.4 多設(shè)備掛載時的地址沖突與總線負(fù)載多設(shè)備掛載時地址沖突是最直接的問題。但即使地址不沖突總線負(fù)載也會影響通信質(zhì)量。每個設(shè)備都會給總線增加電容設(shè)備越多總線電容越大上升時間越長。如果超過標(biāo)準(zhǔn)限制通信就會出錯。解決方法是減少總線電容比如縮短走線、減少設(shè)備數(shù)量、使用 I2C 多路復(fù)用器如 TCA9548A。TCA9548A 是一個 8 通道 I2C 開關(guān)可以把總線分成 8 個子總線每個子總線上掛不同的設(shè)備。這樣即使多個設(shè)備地址相同也可以分別掛在不同通道上。另一個問題是總線速率。設(shè)備越多支持的最高速率可能越低。比如有些老舊的 EEPROM 只支持 100kHz如果你總線上還掛了支持 400kHz 的傳感器整個總線只能跑 100kHz。這時候要么分開總線要么接受低速。7. 調(diào)試 I2C 的實用工具與方法7.1 i2c-tools命令行快速驗證i2c-tools 是 Linux 下最常用的 I2C 調(diào)試工具。i2cdetect 可以掃描總線上的設(shè)備i2cget 和 i2cset 可以讀寫寄存器。i2cdetect -y 1 i2cget -y 1 0x50 0x00 i2cset -y 1 0x50 0x00 0xABi2cdetect 的原理是向每個地址發(fā)送起始條件加設(shè)備地址看是否收到 ACK。如果收到 ACK說明該地址有設(shè)備。但要注意有些設(shè)備在寫周期內(nèi)不響應(yīng)i2cdetect 可能掃不到。還有些設(shè)備地址是保留的i2cdetect 會跳過。i2cget 和 i2cset 適合快速驗證寄存器讀寫。但它們的傳輸格式是固定的不支持重復(fù)起始。對于需要重復(fù)起始的設(shè)備比如 EEPROMi2cget 可能讀不出來。這時候要用 i2ctransfer它支持自定義消息組合。i2ctransfer -y 1 w10x50 0x00 r16這條命令向 0x50 寫一個字節(jié) 0x00然后讀 16 個字節(jié)。中間自動插入重復(fù)起始。7.2 邏輯分析儀抓時序的終極手段邏輯分析儀是調(diào)試 I2C 的終極武器。它可以把 SDA 和 SCL 的波形抓下來解碼成具體的字節(jié)和 ACK。Saleae 的邏輯分析儀配合它的軟件可以自動解碼 I2C 協(xié)議非常方便。抓波形的時候要注意采樣率。I2C 標(biāo)準(zhǔn)模式 100kHz快速模式 400kHz采樣率至少要 4 倍以上建議 10 倍。比如 400kHz 的總線采樣率設(shè) 4MHz 以上。采樣深度要足夠至少能抓到一個完整的傳輸周期。分析波形的時候重點看幾個地方起始條件是否干凈、地址幀的 ACK 是否正常、數(shù)據(jù)幀的 ACK 是否正常、停止條件是否干凈、有沒有時鐘拉伸、上升沿是否太緩。如果上升沿太緩說明上拉電阻太大或者總線電容太大。7.3 用 GPIO 模擬 I2C 做交叉驗證如果你懷疑硬件 I2C 有問題可以用 GPIO 模擬 I2C 做交叉驗證。把 SDA 和 SCL 配置成 GPIO用軟件模擬時序看能不能通信。如果軟件模擬能通硬件 I2C 不通說明硬件 I2C 的配置有問題。如果軟件模擬也不通說明硬件電路有問題。這個方法雖然笨但非常有效。我在項目里遇到過 STM32 硬件 I2C 在特定條件下死鎖的問題最后就是用 GPIO 模擬驗證的。軟件模擬跑了幾天都沒問題硬件 I2C 幾個小時就死一次最后確認(rèn)是硬件 I2C 外設(shè)的 bug。8. 從驅(qū)動到應(yīng)用I2C 代碼的工程化組織8.1 分層設(shè)計總線層、設(shè)備層、應(yīng)用層I2C 代碼的工程化組織很重要。我通常分三層總線層、設(shè)備層、應(yīng)用層。總線層封裝 I2C 的基本讀寫提供 i2c_read 和 i2c_write 接口。設(shè)備層封裝具體設(shè)備的寄存器讀寫比如 eeprom_read、oled_write_cmd、bh1750_read。應(yīng)用層調(diào)用設(shè)備層的接口實現(xiàn)業(yè)務(wù)邏輯。這樣分層的好處是換 MCU 或者換 I2C 控制器時只需要改總線層設(shè)備層和應(yīng)用層不用動。換設(shè)備時只需要改設(shè)備層總線層和應(yīng)用層不用動?？偩€層的接口設(shè)計要統(tǒng)一。比如int i2c_write(int bus, uint8_t addr, uint8_t *buf, int len); int i2c_read(int bus, uint8_t addr, uint8_t *buf, int len); int i2c_write_read(int bus, uint8_t addr, uint8_t *wbuf, int wlen, uint8_t *rbuf, int rlen);i2c_write_read 是最常用的它封裝了寫地址加重復(fù)起始加讀數(shù)據(jù)的流程。設(shè)備層的函數(shù)都基于這三個接口實現(xiàn)。8.2 錯誤處理與重試策略I2C 通信出錯是常態(tài)尤其是在電磁干擾大的環(huán)境下。錯誤處理策略決定了系統(tǒng)的穩(wěn)定性。我的做法是每次 I2C 傳輸失敗后重試 3 次每次重試之間延時 1 毫秒。如果 3 次都失敗執(zhí)行總線恢復(fù)流程然后再重試 3 次。如果還是失敗返回錯誤給上層。重試的時候要注意不是所有錯誤都值得重試。NACK 錯誤可能是從機沒準(zhǔn)備好重試有用?？偩€死鎖錯誤重試沒用必須先恢復(fù)總線。超時錯誤可能是從機沒響應(yīng)重試也可能沒用。所以錯誤處理要分類不同錯誤不同策略。int i2c_transfer_with_retry(int bus, uint8_t addr, uint8_t *wbuf, int wlen, uint8_t *rbuf, int rlen) { int ret; for (int i 0; i 3; i) { ret i2c_write_read(bus, addr, wbuf, wlen, rbuf, rlen); if (ret 0) return 0; if (ret -EAGAIN) usleep(1000); else if (ret -EBUSY) { i2c_bus_recover(bus); usleep(1000); } } return ret; }8.3 性能優(yōu)化批量傳輸與緩存I2C 的速率有限標(biāo)準(zhǔn)模式 100kHz快速模式 400kHz。每次傳輸都有起始條件、地址幀、ACK 位的開銷實際有效數(shù)據(jù)速率更低。所以性能優(yōu)化的關(guān)鍵是減少傳輸次數(shù)盡量批量傳輸。比如讀 EEPROM如果每次讀一個字節(jié)讀 256 字節(jié)需要 256 次傳輸。如果一次讀 16 字節(jié)只需要 16 次傳輸。如果一次讀 256 字節(jié)只需要 1 次傳輸。當(dāng)然EEPROM 的頁大小有限制不能一次讀太多。但傳感器數(shù)據(jù)通?？梢耘孔x。另一個優(yōu)化是緩存。如果某個寄存器的值不經(jīng)常變可以讀一次緩存起來下次直接用緩存不用再讀。比如 OLED 的初始化命令只需要發(fā)一次不用每次都發(fā)。但要注意緩存的一致性如果設(shè)備狀態(tài)可能被外部改變緩存就要失效。9. 寫在最后一些個人體會I2C 驅(qū)動開發(fā)這件事說難不難說簡單也不簡單。協(xié)議本身很簡單兩根線幾個狀態(tài)。但實際項目里遇到的問題往往不是協(xié)議本身的問題而是硬件、時序、異常處理這些細(xì)節(jié)的問題。我個人的經(jīng)驗是調(diào)試 I2C 問題的時候先確認(rèn)硬件沒問題再確認(rèn)時序沒問題最后才懷疑代碼。硬件問題包括上拉電阻、電源、走線、地址配置。時序問題包括速率、時鐘拉伸、重復(fù)起始。代碼問題包括狀態(tài)機、超時、錯誤處理。按這個順序排查能省很多時間。還有一個體會是不要迷信硬件 I2C。硬件 I2C 雖然快但不同 MCU 的硬件 I2C 差異很大有些型號的硬件 I2C 有已知 bug調(diào)試起來很痛苦。軟件模擬 I2C 雖然慢但可控性強移植性好在很多場景下反而是更穩(wěn)妥的選擇。最后I2C 總線上掛的設(shè)備越多出問題的概率越大。如果項目里 I2C 設(shè)備很多建議用 I2C 多路復(fù)用器把總線分開每個子總線上掛少量設(shè)備。這樣即使某個設(shè)備出問題也不會影響其他設(shè)備。這個經(jīng)驗是我在一個項目里踩了無數(shù)次坑之后總結(jié)出來的希望對你有用。