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