1. 從零上手為什么要在OpenHarmony上折騰MLX90614第一次拿到這個需求的時候我腦子里冒出來的第一個念頭是紅外測溫這東西不是早就爛大街了嗎隨便找個單片機跑個I2C讀一下寄存器不就完事了。但真正把MLX90614放到OpenHarmony的驅(qū)動框架里跑通才發(fā)現(xiàn)事情遠沒有想象中那么簡單。裸機時代你只需要關心時序?qū)Σ粚?、地址有沒有配錯而在OpenHarmony這種帶HDF驅(qū)動框架、帶設備樹管理、帶HDI接口抽象的系統(tǒng)里你要考慮的東西一下子多了好幾倍。MLX90614是一顆非接觸式紅外溫度傳感器核心原理是通過熱電堆探測目標物體輻射的紅外能量再結合芯片內(nèi)部的環(huán)境溫度做補償計算最終輸出目標溫度和芯片自身溫度兩個值。它出廠就做了校準通過I2C接口讀取默認地址是0x5A測溫范圍覆蓋-70到380攝氏度精度在人體溫度區(qū)間能做到正負0.5度左右。這顆芯片在額溫槍、工業(yè)測溫、智能家居里用得非常多屬于經(jīng)典中的經(jīng)典。那為什么非要把它搬到OpenHarmony上原因很直接現(xiàn)在大量智能硬件項目在往OpenHarmony生態(tài)上遷移尤其是RK3568、Hi3861這類芯片平臺很多場景需要本地化的溫度感知能力。比如智能門禁要測人體溫度、工業(yè)網(wǎng)關要監(jiān)控設備熱狀態(tài)、智能家電要根據(jù)環(huán)境溫度調(diào)節(jié)運行策略。這些場景下你不可能再外掛一個單片機專門讀傳感器而是希望主控直接通過OpenHarmony的驅(qū)動框架把數(shù)據(jù)拿上來交給上層應用去處理。這篇文章適合誰看如果你已經(jīng)寫過Linux驅(qū)動對I2C協(xié)議不陌生但還沒在OpenHarmony上完整走過一遍驅(qū)動開發(fā)流程那這篇內(nèi)容就是給你準備的。如果你是完全的新手也沒關系我會把設備樹配置、HDF驅(qū)動框架、I2C通信協(xié)議這些基礎概念用大白話講清楚讓你能跟著一步步做下來。整個流程我會按照實際項目的開發(fā)順序來展開先搞清楚硬件怎么接再配設備樹然后寫驅(qū)動代碼接著編譯燒錄最后調(diào)試驗證。每一步我都會說明為什么這么做以及我踩過哪些坑。2. 動手之前先把硬件鏈路和通信協(xié)議理清楚2.1 MLX90614的引腳定義與硬件連接方案MLX90614常見封裝是TO-39金屬殼四個引腳VDD、GND、SDA、SCL。供電范圍寬3.3V和5V都能跑但注意SDA和SCL的上拉電壓要跟主控IO電平匹配。我用的RK3568開發(fā)板IO是3.3V電平所以直接把傳感器接在3.3V供電上SDA和SCL各掛一個4.7k的上拉電阻到3.3V。這里有個細節(jié)很多人容易忽略MLX90614的I2C接口支持標準模式和快速模式最高頻率可以到100kHz標準模式或者400kHz快速模式。但實際用下來我建議在OpenHarmony上先跑100kHz等驅(qū)動穩(wěn)定了再嘗試提速。原因后面講調(diào)試的時候會詳細說。接線方式很簡單MLX90614引腳開發(fā)板接口備注VDD3.3V供電正極GNDGND共地SDAI2Cx_SDA數(shù)據(jù)線需上拉SCLI2Cx_SCL時鐘線需上拉上拉電阻的選擇有個經(jīng)驗公式R (Vdd - Vol) / Iol一般I2C總線上拉取4.7k是經(jīng)過驗證的穩(wěn)妥值。如果你總線上掛了多個I2C設備可以適當減小到2.2k但不要低于1k否則功耗會上去而且可能拉不低電平。2.2 I2C通信協(xié)議在MLX90614上的具體表現(xiàn)MLX90614的I2C通信遵循標準的讀寫時序但有幾個特殊點需要記住。它的設備地址是7位地址0x5A寫操作時發(fā)送0xB4讀操作時發(fā)送0xB5。芯片內(nèi)部有一塊RAM和一塊EEPROMRAM地址從0x00到0x1FEEPROM地址從0x20到0x3F。我們最關心的兩個數(shù)據(jù)寄存器是0x06環(huán)境溫度Ta即芯片自身溫度0x07目標溫度Tobj即被測物體溫度讀出來的原始數(shù)據(jù)是16位的低8位和高8位分兩個字節(jié)傳輸。溫度換算公式是T raw * 0.02 - 273.15單位是攝氏度。這個0.02是芯片的分辨率也就是每個LSB代表0.02K。I2C的讀時序是這樣的先發(fā)送起始條件然后發(fā)送設備地址加寫標志0xB4接著發(fā)送要讀的寄存器地址比如0x07然后重新發(fā)送起始條件發(fā)送設備地址加讀標志0xB5接著讀取兩個字節(jié)的數(shù)據(jù)最后發(fā)送停止條件。整個過程需要嚴格遵守時序要求尤其是在OpenHarmony的驅(qū)動框架下I2C控制器的配置會直接影響通信成功率。注意MLX90614在讀取數(shù)據(jù)時有一個PEC校驗字節(jié)如果你在驅(qū)動里開啟了PEC校驗需要多讀一個字節(jié)。我建議初期先關閉PEC等基本通信調(diào)通后再考慮加上。2.3 OpenHarmony驅(qū)動框架對I2C設備的支持方式OpenHarmony的驅(qū)動框架叫HDFHardware Driver Foundation它把驅(qū)動分成內(nèi)核態(tài)和用戶態(tài)兩部分。對于I2C設備通常的做法是在內(nèi)核態(tài)實現(xiàn)一個HDF驅(qū)動通過I2C控制器提供的統(tǒng)一接口去讀寫傳感器。這樣做的好處是驅(qū)動代碼可以復用HDF提供的I2C訪問API不需要直接操作寄存器。HDF的I2C接口主要有幾個關鍵函數(shù)I2cOpen()打開I2C控制器I2cTransfer()執(zhí)行一次I2C傳輸可以組合多個消息I2cClose()關閉I2C控制器在驅(qū)動初始化的時候你需要通過HDF的配置解析機制拿到設備樹里配的I2C總線號和從設備地址然后打開對應的I2C控制器。之后每次讀溫度就構造一個I2cMsg數(shù)組把寫寄存器地址和讀數(shù)據(jù)兩個操作組合成一次傳輸。這種設計的好處是驅(qū)動代碼跟具體的I2C控制器硬件解耦了你換一個芯片平臺只要設備樹改一下驅(qū)動代碼基本不用動。但代價是你需要理解HDF的驅(qū)動模型包括驅(qū)動入口、設備管理、配置解析這些概念。我剛開始接觸的時候也覺得繞但寫過一個完整驅(qū)動之后回頭看這套框架確實比裸機時代自己擼寄存器要規(guī)范得多。3. 設備樹配置讓內(nèi)核認識你的傳感器3.1 設備樹在OpenHarmony中的角色設備樹Device Tree這個東西簡單說就是一份硬件描述文件告訴內(nèi)核“板子上有什么設備、它們掛在哪條總線上、地址是多少、用什么驅(qū)動”。在OpenHarmony里設備樹的作用跟Linux是一樣的但配置方式略有不同。OpenHarmony的設備樹通常放在kernel/linux/config/或者device/目錄下具體路徑取決于你用的芯片平臺。對于RK3568平臺設備樹文件一般在kernel/linux/arch/arm64/boot/dts/rockchip/下面你會看到一堆rk3568-xxx.dts和rk3568-xxx.dtsi文件。你需要找到你實際使用的板級設備樹文件然后在里面添加MLX90614的節(jié)點。3.2 添加MLX90614設備樹節(jié)點的完整步驟第一步找到I2C控制器的節(jié)點。RK3568有多個I2C控制器比如i2c0到i2c5你需要確認你的傳感器實際接在哪條總線上。假設接在i2c3上那就在設備樹里找到i2c3這個節(jié)點。第二步在i2c3節(jié)點下面添加子節(jié)點。代碼大概長這樣i2c3 { status okay; clock-frequency 100000; mlx90614: mlx906145a { compatible melexis,mlx90614; reg 0x5a; status okay; }; };這里有幾個關鍵點要解釋status okay表示啟用這條I2C總線。很多板子的I2C默認是disabled狀態(tài)你不改的話驅(qū)動根本找不到設備。clock-frequency 100000設置I2C總線頻率為100kHz。前面說了初期建議用標準模式。compatible這是驅(qū)動匹配的關鍵字段格式一般是“廠商,型號”。你寫的驅(qū)動里要有一個匹配表里面包含這個字符串內(nèi)核才能把設備和驅(qū)動綁在一起。reg 0x5a從設備地址MLX90614的7位地址就是0x5A。第三步檢查引腳復用配置。RK3568的I2C引腳通常跟其他功能復用你需要在pinctrl節(jié)點里確認I2C3的SDA和SCL引腳被正確配置為I2C功能。這部分一般在板級dtsi文件里已經(jīng)配好了但如果你用的是自定義板子可能需要自己改。提示設備樹改完之后編譯內(nèi)核的時候會自動把dtb文件更新。你可以用fdtdump工具反編譯dtb確認你的節(jié)點確實被包含進去了。3.3 設備樹配置中容易踩的坑我在這部分踩過兩個坑這里分享一下。第一個坑是I2C總線號搞錯了。RK3568的I2C控制器編號和實際物理接口的對應關系不同板子可能不一樣。我一開始以為絲印上寫的I2C3就是i2c3節(jié)點結果實際對應的是i2c5。后來用示波器量了波形才確認。所以建議你在配置之前先確認原理圖或者用工具掃描一下I2C總線。第二個坑是上拉電阻沒焊。有些開發(fā)板的I2C接口自帶上拉有些沒有。如果你接的傳感器模塊上沒有上拉電阻而開發(fā)板也沒有那I2C總線就是浮空的通信肯定失敗。我當時的現(xiàn)象是I2cTransfer一直返回超時錯誤查了半天才發(fā)現(xiàn)是硬件問題。第三個坑是地址沖突。如果你總線上還掛了其他I2C設備要確認它們的地址不沖突。MLX90614的地址可以通過EEPROM修改但出廠默認是0x5A。我遇到過一塊OLED屏也是0x5A地址的情況后來把OLED換到另一條總線上才解決。4. HDF驅(qū)動開發(fā)從驅(qū)動入口到數(shù)據(jù)讀取4.1 HDF驅(qū)動的基本結構和入口函數(shù)OpenHarmony的HDF驅(qū)動有一套固定的模板你需要實現(xiàn)幾個關鍵的回調(diào)函數(shù)。整個驅(qū)動代碼大概分成三部分驅(qū)動入口、設備初始化和業(yè)務邏輯。驅(qū)動入口用HDF_INIT宏來注冊代碼結構如下#include hdf_device_desc.h #include hdf_log.h #include i2c_if.h #define HDF_LOG_TAG mlx90614_driver static int32_t MlX90614Bind(struct HdfDeviceObject *device) { if (device NULL) { HDF_LOGE(device is null); return HDF_ERR_INVALID_PARAM; } static struct IDeviceIoService service { .object {0}, }; device-service service; return HDF_SUCCESS; } static int32_t MlX90614Init(struct HdfDeviceObject *device) { if (device NULL || device-property NULL) { HDF_LOGE(device or property is null); return HDF_ERR_INVALID_PARAM; } // 解析設備樹配置打開I2C控制器 // ... return HDF_SUCCESS; } static void MlX90614Release(struct HdfDeviceObject *device) { // 釋放資源 } struct HdfDriverEntry g_mlx90614DriverEntry { .moduleVersion 1, .moduleName mlx90614_driver, .Bind MlX90614Bind, .Init MlX90614Init, .Release MlX90614Release, }; HDF_INIT(g_mlx90614DriverEntry);這段代碼里Bind函數(shù)負責把驅(qū)動服務掛到HDF設備上Init函數(shù)做實際的初始化工作Release函數(shù)在驅(qū)動卸載時清理資源。moduleName要和驅(qū)動配置文件里的名字一致否則驅(qū)動加載不起來。4.2 解析設備樹配置并打開I2C控制器在Init函數(shù)里你需要從device-property中解析出設備樹里配的I2C總線號和從設備地址。HDF提供了一套配置解析API常用的有HdfDeviceGetNodeUint32()讀取整型配置HdfDeviceGetNodeString()讀取字符串配置假設你的驅(qū)動配置文件里這樣寫device_mlx90614 :: device { device0 :: deviceNode { policy 2; priority 100; preload 0; permission 0664; moduleName mlx90614_driver; serviceName mlx90614_service; deviceMatchAttr mlx90614_config; }; }然后在mlx90614_config對應的配置節(jié)點里你需要指定I2C總線號。不過更常見的做法是直接在設備樹里通過reg屬性拿到從設備地址通過父節(jié)點的bus-number拿到總線號。打開I2C控制器的代碼大概是這樣static int32_t MlX90614Init(struct HdfDeviceObject *device) { struct MlX90614DrvData *drvData NULL; drvData (struct MlX90614DrvData *)OsalMemCalloc(sizeof(*drvData)); if (drvData NULL) { HDF_LOGE(malloc drvData failed); return HDF_ERR_MALLOC_FAIL; } // 從設備樹解析I2C總線號 int32_t busNum 3; // 假設是i2c3 drvData-i2cHandle I2cOpen(busNum); if (drvData-i2cHandle NULL) { HDF_LOGE(open i2c%d failed, busNum); OsalMemFree(drvData); return HDF_FAILURE; } drvData-slaveAddr 0x5A; device-priv drvData; HDF_LOGI(mlx90614 init success); return HDF_SUCCESS; }這里I2cOpen返回一個句柄后續(xù)所有的I2C讀寫都通過這個句柄來操作。slaveAddr就是MLX90614的從設備地址。4.3 實現(xiàn)溫度讀取的核心業(yè)務邏輯讀溫度是整個驅(qū)動最核心的部分。前面說了MLX90614的目標溫度寄存器地址是0x07環(huán)境溫度是0x06。讀一次數(shù)據(jù)的流程是先寫寄存器地址再讀兩個字節(jié)。用HDF的I2C接口實現(xiàn)的話代碼大概是這樣static int32_t MlX90614ReadReg(struct MlX90614DrvData *drvData, uint8_t reg, uint8_t *buf, uint16_t len) { int32_t ret; struct I2cMsg msg[2] {0}; // 第一條消息寫寄存器地址 msg[0].addr drvData-slaveAddr; msg[0].flags 0; msg[0].len 1; msg[0].buf reg; // 第二條消息讀數(shù)據(jù) msg[1].addr drvData-slaveAddr; msg[1].flags I2C_FLAG_READ; msg[1].len len; msg[1].buf buf; ret I2cTransfer(drvData-i2cHandle, msg, 2); if (ret ! 2) { HDF_LOGE(i2c transfer failed, ret %d, ret); return HDF_FAILURE; } return HDF_SUCCESS; } static int32_t MlX90614ReadTemp(struct MlX90614DrvData *drvData, float *temp) { uint8_t buf[2] {0}; int32_t ret; ret MlX90614ReadReg(drvData, 0x07, buf, 2); if (ret ! HDF_SUCCESS) { return ret; } uint16_t raw (buf[1] 8) | buf[0]; *temp raw * 0.02f - 273.15f; return HDF_SUCCESS; }這里有個細節(jié)要注意MLX90614返回的數(shù)據(jù)是低字節(jié)在前、高字節(jié)在后所以拼接的時候是(buf[1] 8) | buf[0]不要搞反了。我一開始就是搞反了讀出來的溫度一直是負的幾百度查了半天才發(fā)現(xiàn)是字節(jié)序問題。另外I2cTransfer的返回值是實際傳輸?shù)南?shù)量如果返回2說明兩條消息都成功了。如果返回小于2說明某條消息失敗了需要檢查硬件連接和時序配置。4.4 驅(qū)動配置文件的編寫要點HDF驅(qū)動需要在hdf_devhost的配置文件里注冊這個文件通常在vendor/目錄下名字類似device_info.hcs。你需要在里面添加你的設備節(jié)點device_mlx90614 :: device { device0 :: deviceNode { policy 2; priority 100; preload 0; permission 0664; moduleName mlx90614_driver; serviceName mlx90614_service; deviceMatchAttr mlx90614_config; }; }policy字段決定驅(qū)動是內(nèi)核態(tài)還是用戶態(tài)加載2表示內(nèi)核態(tài)。moduleName要和驅(qū)動代碼里的moduleName一致。serviceName是上層應用訪問驅(qū)動時用的服務名。配置改完之后需要重新編譯HDF驅(qū)動框架和你的驅(qū)動模塊然后燒錄到板子上。編譯命令取決于你的項目構建系統(tǒng)OpenHarmony標準系統(tǒng)一般用./build.sh --product-name rk3568這樣的命令。5. 編譯、燒錄與調(diào)試把驅(qū)動跑起來5.1 編譯環(huán)境的搭建和驅(qū)動模塊的編譯OpenHarmony的編譯環(huán)境搭建是個體力活我這里不展開講整個環(huán)境的安裝只說你編譯驅(qū)動模塊需要關注的部分。首先你需要確保hb命令能用這是OpenHarmony的構建工具。然后進入你的項目根目錄執(zhí)行hb set # 選擇你的產(chǎn)品比如 rk3568 hb build -f如果你只想編譯驅(qū)動模塊可以用hb build -f --target //drivers/hdf_core/framework/model/sensor/mlx90614:mlx90614_driver編譯成功后會生成.ko文件這個就是你的驅(qū)動模塊。然后你需要把.ko文件推到板子上用insmod加載insmod mlx90614_driver.ko如果加載成功用lsmod能看到模塊信息。如果加載失敗用dmesg看內(nèi)核日志通常會告訴你失敗原因比如符號未定義、版本不匹配之類的。5.2 用HDF工具驗證驅(qū)動是否加載成功OpenHarmony提供了一個HDF調(diào)試工具可以查看當前加載的驅(qū)動列表。在串口終端里執(zhí)行hdf_devhost -l如果看到你的mlx90614_driver出現(xiàn)在列表里說明驅(qū)動加載成功了。然后你可以用hdf_devhost -i mlx90614_service查看服務的詳細信息。另一個驗證方法是直接讀/dev下面的設備節(jié)點。如果你的驅(qū)動創(chuàng)建了設備節(jié)點應該能在/dev下面看到對應的文件。不過HDF驅(qū)動不一定創(chuàng)建設備節(jié)點這取決于你的驅(qū)動實現(xiàn)方式。5.3 實際讀取溫度數(shù)據(jù)的完整測試流程驅(qū)動加載成功之后你需要寫一個簡單的測試程序來驗證數(shù)據(jù)讀取。最直接的方式是在驅(qū)動里加一個調(diào)試接口通過ioctl或者sysfs暴露給用戶態(tài)。但更簡單的做法是直接在驅(qū)動初始化的時候讀一次溫度打印到內(nèi)核日志里。我在調(diào)試階段就是在Init函數(shù)最后加了一段float temp 0; if (MlX90614ReadTemp(drvData, temp) HDF_SUCCESS) { HDF_LOGI(current temperature: %.2f C, temp); } else { HDF_LOGE(read temperature failed); }然后加載驅(qū)動之后用dmesg | grep mlx90614就能看到溫度值。如果讀出來是25度左右說明環(huán)境溫度正常如果讀出來是-273度說明數(shù)據(jù)沒讀對如果讀出來是幾百度的離譜值可能是字節(jié)序或者換算公式有問題。5.4 常見通信失敗原因和排查方法調(diào)試I2C設備最怕的就是通信失敗而且失敗的現(xiàn)象往往很模糊。我整理了一個排查清單按優(yōu)先級排序現(xiàn)象可能原因排查方法I2cTransfer返回超時上拉電阻缺失或阻值不對用萬用表量SDA/SCL對VCC的電阻返回NACK從設備地址錯誤用i2cdetect掃描總線數(shù)據(jù)全0或全FF寄存器地址錯誤確認寄存器地址和讀寫標志溫度值明顯偏差字節(jié)序或換算公式錯誤手動計算raw值驗證驅(qū)動加載失敗moduleName不匹配檢查hcs配置文件和驅(qū)動代碼還有一個容易被忽略的問題I2C總線的時鐘頻率。有些MLX90614模塊在400kHz下工作不穩(wěn)定尤其是走線比較長的時候。如果你在100kHz下能讀通換到400kHz就不行那大概率是信號完整性問題不是驅(qū)動代碼的問題。實操心得調(diào)試I2C設備的時候示波器是最有用的工具。沒有示波器的話至少準備一個邏輯分析儀幾十塊錢的那種就能用。能看到波形很多問題一眼就能定位。6. 進階優(yōu)化讓驅(qū)動更穩(wěn)定、更實用6.1 增加溫度讀取的濾波和校準邏輯MLX90614本身的精度已經(jīng)不錯了但在實際使用中讀出來的溫度會有小幅波動大概在正負0.2度左右。如果你的應用對穩(wěn)定性要求高可以在驅(qū)動層加一個簡單的滑動平均濾波。比如維護一個長度為8的環(huán)形緩沖區(qū)每次讀到的溫度放進去輸出的時候取平均值。代碼實現(xiàn)很簡單#define FILTER_LEN 8 static float MlX90614Filter(struct MlX90614DrvData *drvData, float newTemp) { drvData-filterBuf[drvData-filterIdx] newTemp; drvData-filterIdx (drvData-filterIdx 1) % FILTER_LEN; float sum 0; for (int i 0; i FILTER_LEN; i) { sum drvData-filterBuf[i]; } return sum / FILTER_LEN; }這個濾波邏輯會增加一點內(nèi)存開銷但換來的穩(wěn)定性提升是值得的。尤其是在測溫目標距離較遠或者環(huán)境溫度變化較快的時候濾波效果很明顯。另外MLX90614的EEPROM里可以校準發(fā)射率Emissivity。默認發(fā)射率是0.95適合大多數(shù)物體表面。如果你測的是高反射率金屬表面需要把發(fā)射率調(diào)低否則讀數(shù)會偏低。發(fā)射率寄存器的地址是0x24修改的時候要注意EEPROM寫入有次數(shù)限制不要頻繁寫。6.2 通過HDI接口向上層暴露溫度數(shù)據(jù)在OpenHarmony的架構里驅(qū)動層往上是通過HDIHardware Device Interface接口跟上層服務通信的。如果你想讓應用層能直接拿到溫度數(shù)據(jù)需要實現(xiàn)一個HDI接口。不過對于大多數(shù)場景更簡單的做法是通過sysfs或者ioctl暴露一個字符設備節(jié)點上層應用直接讀文件就行。用sysfs的方式你需要在驅(qū)動里創(chuàng)建一個屬性文件static ssize_t TempShow(struct device *dev, struct device_attribute *attr, char *buf) { struct MlX90614DrvData *drvData dev_get_drvdata(dev); float temp 0; MlX90614ReadTemp(drvData, temp); return sprintf(buf, %.2f\n, temp); } static DEVICE_ATTR_RO(Temp);然后應用層用cat /sys/class/mlx90614/temp就能讀到溫度值。這種方式簡單直接適合快速驗證和輕量級應用。6.3 低功耗場景下的驅(qū)動適配思路如果你的設備是電池供電的那MLX90614的功耗就需要考慮。芯片正常工作電流大概1.5mA待機電流只有幾微安。在OpenHarmony的電源管理框架下你可以讓驅(qū)動支持運行時掛起和恢復。具體做法是實現(xiàn)HdfDeviceObject的Suspend和Resume回調(diào)在系統(tǒng)進入低功耗模式的時候關閉I2C控制器喚醒的時候重新打開。不過這個功能需要跟系統(tǒng)的電源管理策略配合不是所有場景都需要。另一個省電的思路是降低采樣頻率。MLX90614支持單次測量模式你可以在需要讀溫度的時候才發(fā)起一次測量讀完就讓芯片進入睡眠。這樣平均功耗可以降到幾十微安級別。6.4 多傳感器組網(wǎng)時的地址管理和總線擴展一個I2C總線上理論上可以掛多個MLX90614但它們的默認地址都是0x5A會沖突。解決辦法有兩個一是通過EEPROM修改其中一個的地址二是用I2C多路復用器擴展總線。修改地址的方法是通過寫EEPROM的0x2E寄存器SMBus地址寄存器把地址改成其他值。但注意EEPROM寫入次數(shù)有限而且改完之后要重新上電才生效。我一般建議用I2C多路復用器比如TCA9548A一片可以擴展8條I2C總線每條總線上掛一個MLX90614地址都不用改。在OpenHarmony的設備樹里多路復用器的配置稍微復雜一點需要把復用器本身作為一個I2C設備然后在它下面再掛子設備。這部分內(nèi)容展開講篇幅會很長有機會單獨寫一篇。7. 我踩過的坑和最后分享幾個實用技巧整個項目做下來前前后后花了大概一周時間其中大部分時間不是在寫代碼而是在調(diào)試硬件和排查配置問題。這里把幾個印象最深的坑分享一下希望能幫你少走彎路。第一個坑是設備樹里I2C總線號寫錯了。我一開始看原理圖上標的是I2C3就在設備樹里配了i2c3結果怎么都讀不到數(shù)據(jù)。后來用邏輯分析儀抓波形發(fā)現(xiàn)SDA和SCL上根本沒有信號。查了RK3568的引腳復用表才發(fā)現(xiàn)原理圖上的I2C3對應的是i2c5節(jié)點。所以原理圖上的標號和設備樹里的節(jié)點號不一定一致一定要交叉驗證。第二個坑是驅(qū)動加載順序的問題。HDF驅(qū)動有preload屬性如果設成0表示不預加載需要手動加載。我一開始設成0然后忘了手動insmod結果一直找不到設備。后來改成1讓它隨系統(tǒng)啟動自動加載問題就解決了。第三個坑是溫度換算的浮點運算。OpenHarmony的內(nèi)核態(tài)默認可能不支持浮點運算如果你在驅(qū)動里直接用float做計算可能會觸發(fā)異常。解決辦法是用定點數(shù)運算把溫度值乘以100用整數(shù)傳輸上層再除以100?；蛘甙迅↑c運算放到用戶態(tài)去做驅(qū)動只負責傳原始數(shù)據(jù)。最后分享一個小技巧如果你手頭沒有邏輯分析儀可以用GPIO模擬I2C的方式來驗證傳感器是否正常工作。先把SDA和SCL配成普通GPIO手動翻轉電平模擬I2C時序如果能讀到正確的數(shù)據(jù)說明傳感器和硬件連接沒問題問題出在I2C控制器配置上。這個方法雖然原始但在沒有專業(yè)工具的時候非常管用。這個驅(qū)動后續(xù)還可以繼續(xù)擴展比如加上溫度閾值報警功能、支持多個傳感器同時采集、通過MQTT把數(shù)據(jù)上傳到云端等等。OpenHarmony的驅(qū)動框架擴展性很好只要把基礎通信調(diào)通后面的業(yè)務邏輯就是搭積木的事情了。