做OpenHarmony驅(qū)動開發(fā)、系統(tǒng)移植的朋友應(yīng)該都見過倉庫里密密麻麻的.hcs文件也一定見過驅(qū)動代碼里的HdfDriverEntry結(jié)構(gòu)。這兩樣?xùn)|西——HDF和HCS——幾乎是OpenHarmony驅(qū)動體系里最核心、也最容易勸退新手的兩個(gè)縮寫。HDF是驅(qū)動框架像一個(gè)統(tǒng)一的大管家把內(nèi)核態(tài)、用戶態(tài)的驅(qū)動全部收編起來管理HCS是配置源描述語言負(fù)責(zé)告訴這個(gè)管家硬件有哪些設(shè)備、驅(qū)動該怎么匹配、用哪組參數(shù)初始化。這篇文章適合正在折騰RK3568開發(fā)板、打算用OpenHarmony做產(chǎn)品原型或者剛接觸HDF想搞懂配置和代碼之間關(guān)系的開發(fā)者。我會用實(shí)際工程里的思路講清楚這兩個(gè)東西分別干什么、怎么配合以及適配過程中最容易翻車的幾個(gè)細(xì)節(jié)。1. HDFOpenHarmony驅(qū)動的“統(tǒng)一大管家”1.1 沒有HDF的時(shí)候驅(qū)動世界是什么樣傳統(tǒng)驅(qū)動開發(fā)里代碼形態(tài)五花八門有字符設(shè)備、塊設(shè)備、平臺驅(qū)動有i2c、spi、gpio驅(qū)動匹配方式也各管各的有的靠設(shè)備樹compatible有的靠PCI IDs有的干脆自己注冊一個(gè)總線。這對一個(gè)嵌入式工程師來說早就習(xí)慣了但放在OpenHarmony這個(gè)場景下就很麻煩。OpenHarmony面對的是從智能家居傳感器到中控大屏的一大堆設(shè)備形態(tài)如果每個(gè)驅(qū)動還是各寫各的、各自維護(hù)一套生命周期和配置讀取方式那系統(tǒng)根本沒法統(tǒng)一管理誰先加載、誰依賴誰、服務(wù)掛在哪、用戶態(tài)怎么找到驅(qū)動全亂套。HDF就是為了解決這個(gè)散亂問題出來的。它不是把你的驅(qū)動代碼推倒重寫而是在驅(qū)動外面套一層統(tǒng)一框架把設(shè)備管理、服務(wù)注冊、配置解析、生命周期控制全部收口。打個(gè)比方HDF是寫字樓的物業(yè)中心每家公司內(nèi)部怎么裝修驅(qū)動實(shí)現(xiàn)細(xì)節(jié)沒人管但是門牌號設(shè)備節(jié)點(diǎn)、入駐登記Bind、水電開通Init、退租手續(xù)Release全部走物業(yè)統(tǒng)一流程。你只要把驅(qū)動裝進(jìn)這個(gè)框架整個(gè)系統(tǒng)就知道怎么去找它、怎么調(diào)用它。1.2 HDF的架構(gòu)組成誰在干什么HDF框架從邏輯上可以拆成幾塊你調(diào)試的時(shí)候看到的日志標(biāo)簽基本就對應(yīng)這幾塊設(shè)備管理器DeviceManager負(fù)責(zé)解析HCS配置枚舉設(shè)備節(jié)點(diǎn)決定驅(qū)動加載順序和依賴關(guān)系。日志里?？吹紿DF_DM。設(shè)備服務(wù)管理器DeviceServiceManager管理驅(qū)動暴露出來的服務(wù)用戶態(tài)程序通過服務(wù)名綁定驅(qū)動日志里?？吹紿DF_DEV_SVC。配置管理器ConfigManager讀取HCB二進(jìn)制配置提供按節(jié)點(diǎn)、按屬性查詢的接口驅(qū)動在Init里拿配置全靠它。宿主進(jìn)程DevHost這是用戶態(tài)驅(qū)動的容器。用戶態(tài)驅(qū)動不是每個(gè)驅(qū)動一個(gè)進(jìn)程而是多個(gè)驅(qū)動模塊掛在同一個(gè)宿主進(jìn)程下統(tǒng)一調(diào)度。驅(qū)動實(shí)現(xiàn)層你真正寫的Bind/Init/Release回調(diào)就是在這一層。這些組件之間是這么配合的系統(tǒng)啟動后設(shè)備管理器先讀HCS編譯出的HCB把設(shè)備節(jié)點(diǎn)信息拿到手然后根據(jù)節(jié)點(diǎn)里寫的moduleName、priority、preload字段決定加載哪個(gè)驅(qū)動模塊、什么順序加載驅(qū)動模塊加載時(shí)進(jìn)入DriverEntry先調(diào)Bind做設(shè)備與驅(qū)動之間的綁定關(guān)系校驗(yàn)再調(diào)Init做初始化、讀取配置參數(shù)最后把服務(wù)注冊到服務(wù)管理器供上層調(diào)用。整個(gè)流程里配置信息是源頭框架是靠配置驅(qū)動起來的。1.3 內(nèi)核態(tài)驅(qū)動和用戶態(tài)驅(qū)動怎么選HDF支持兩種驅(qū)動形態(tài)內(nèi)核態(tài)驅(qū)動和用戶態(tài)驅(qū)動。這個(gè)選擇直接影響你寫HCS配置時(shí)的節(jié)點(diǎn)策略所以提前說清楚。維度內(nèi)核態(tài)HDF驅(qū)動用戶態(tài)HDF驅(qū)動性能高直接訪問寄存器略低但大部分外設(shè)場景夠用調(diào)試方式串口日志、斷電分析麻煩可以gdb、hilog方便很多穩(wěn)定性崩了直接panic影響整機(jī)異常只影響宿主進(jìn)程可重啟恢復(fù)適用場景中斷頻繁、DMA批量、寄存器密集的外設(shè)I2C/SPI/UART傳感器、GNSS、協(xié)議棧類開發(fā)成本高要考慮內(nèi)核并發(fā)、鎖、內(nèi)存訪問低邏輯都寫在用戶態(tài)出問題好定位我自己的經(jīng)驗(yàn)是能放用戶態(tài)就放用戶態(tài)。OpenHarmony的HDIHardware Device Interface設(shè)計(jì)很成熟用戶態(tài)驅(qū)動通過HDF框架和內(nèi)核交互性能損耗在大部分傳感器、屏幕、音頻場景下完全可以接受。只有像GPU、顯示控制器、DMA吞吐要求很高的場景才需要往內(nèi)核態(tài)寫。而且用戶態(tài)驅(qū)動的崩潰隔離能力在量產(chǎn)產(chǎn)品上特別有用驅(qū)動掛了進(jìn)程重啟就行不至于讓整機(jī)黑屏重啟。2. HCS配置源驅(qū)動與硬件的“翻譯詞典”2.1 HCS到底長什么樣HCS全稱是HDF Configuration Source后綴就是.hcs。它本質(zhì)上是一種可讀的層級配置描述語言跟JSON有點(diǎn)像最外層是root根節(jié)點(diǎn)下面掛子節(jié)點(diǎn)節(jié)點(diǎn)里放屬性。但和JSON不同的是HCS屬性可以帶類型、宏、表達(dá)式還支持模板繼承和節(jié)點(diǎn)引用表達(dá)能力比JSON強(qiáng)不少。給你看一段最簡單的傳感器配置root { sensor_config { accel_magnetic { match_attr hdf_accel_magnetic; sensorName accel_magnetic; vendorName hisi; sensorType 1; chipId 0x92; regs [0x01, 0x02, 0x03]; } } }這里sensor_config是子節(jié)點(diǎn)accel_magnetic是更下一層的設(shè)備節(jié)點(diǎn)。match_attr是HDF設(shè)備匹配的關(guān)鍵字段驅(qū)動側(cè)靠它來對應(yīng)這組配置sensorName、vendorName這些是自定義屬性驅(qū)動Init里可以按名字讀出來regs是數(shù)組類型用來放一組寄存器地址。語法上注意幾點(diǎn)每個(gè)屬性賦值末尾必須有分號字符串用雙引號十六進(jìn)制帶0x前綴數(shù)組元素用逗號分隔、整體放在方括號里。2.2 為什么有了設(shè)備樹還要搞HCS這個(gè)問題我經(jīng)常被問到。設(shè)備樹DTS描述的是板級硬件拓?fù)淠硞€(gè)外設(shè)掛在哪個(gè)總線、寄存器地址是多少、中斷號是哪個(gè)它是給內(nèi)核看的讓內(nèi)核知道這塊板子是怎么連接的。但HCS解決的是另一層問題一個(gè)設(shè)備對應(yīng)哪個(gè)驅(qū)動模塊、服務(wù)名叫什么、初始化參數(shù)是多少、加載優(yōu)先級多高。它管的是驅(qū)動框架層面的邏輯配置。兩者分工很明顯。舉個(gè)例子一顆I2C觸摸屏芯片設(shè)備樹里寫的是“我在i2c2總線上設(shè)備地址0x38”這是一份地圖HCS里寫的是“用touch_it7250這個(gè)驅(qū)動模塊處理它上報(bào)速率設(shè)成240Hz上報(bào)方向是橫屏”這是一份操作手冊。內(nèi)核看到地圖知道怎么訪問硬件HDF看到操作手冊知道怎么配置驅(qū)動。如果你把驅(qū)動參數(shù)寫進(jìn)設(shè)備樹HDF框架不會主動讀反過來你把寄存器地址寫進(jìn)HCS內(nèi)核設(shè)備模型也用不上。所以最佳實(shí)踐是設(shè)備樹放硬件資源HCS放驅(qū)動邏輯參數(shù)兩邊各管各的不要互相越界。2.3 從HCS到HCB編譯和加載過程.hcs源文件不能在運(yùn)行時(shí)直接被驅(qū)動讀取需要先用hc-gen工具編譯成二進(jìn)制格式HCBHDF Configuration Binary。整個(gè)環(huán)節(jié)是構(gòu)建系統(tǒng)自動完成的但你要理解這個(gè)產(chǎn)物是怎么進(jìn)入鏡像的。hc-gen -o out/gpio_config.hcb -i gpio_config.hcs手動執(zhí)行時(shí)就是上面這行。實(shí)際OpenHarmony構(gòu)建中BUILD.gn里的hdf配置項(xiàng)會指定.hcs文件路徑編譯系統(tǒng)會把這些文件統(tǒng)一收集起來用hc-gen生成HCB然后打包進(jìn)系統(tǒng)鏡像或者內(nèi)核ramfs。運(yùn)行的時(shí)候設(shè)備管理器去固定路徑一般是/etc/hdfconfig/加載HCB并通過配置管理接口向外提供查詢服務(wù)比如按節(jié)點(diǎn)名查子節(jié)點(diǎn)、按match_attr查設(shè)備配置塊。這里有個(gè)很常見的坑.hcs文件改了但改了之后沒有觸發(fā)hc-gen重新編譯或者h(yuǎn)cb包沒重新打進(jìn)鏡像導(dǎo)致你覺得改了配置結(jié)果跑起來還是老行為。排查的時(shí)候不要只盯代碼先確認(rèn)你改的.hcs文件確實(shí)被納入了編譯、生成的.hcb確實(shí)被刷進(jìn)了設(shè)備。3. HDF與HCS協(xié)同實(shí)戰(zhàn)跑通一個(gè)最小GPIO驅(qū)動3.1 驅(qū)動入口三件套HDF驅(qū)動注冊格式是固定的不管內(nèi)核態(tài)還是用戶態(tài)核心都是HdfDriverEntry結(jié)構(gòu)體加三個(gè)回調(diào)函數(shù)。先看代碼#include hdf_base.h #include hdf_device_desc.h static int32_t GpioDriverBind(struct HdfDeviceObject *device) { // 綁定階段做設(shè)備與驅(qū)動的匹配校驗(yàn)保存必要上下文 return HDF_SUCCESS; } static int32_t GpioDriverInit(struct HdfDeviceObject *device) { // 初始化階段從這里可以訪問device-property讀取HCS節(jié)點(diǎn)內(nèi)容 // 也可以調(diào)用平臺接口申請GPIO資源 return HDF_SUCCESS; } static void GpioDriverRelease(struct HdfDeviceObject *device) { // 釋放階段卸載驅(qū)動時(shí)反初始化、釋放資源 } struct HdfDriverEntry g_gpioDriverEntry { .moduleVersion 1, .moduleName gpio_demo_driver, .Bind GpioDriverBind, .Init GpioDriverInit, .Release GpioDriverRelease, }; HDF_INIT(g_gpioDriverEntry);三個(gè)回調(diào)的職責(zé)要分清楚。Bind是驅(qū)動和設(shè)備綁定時(shí)最先調(diào)的這里是校驗(yàn)設(shè)備對象、保存指針的好地方Init是真正初始化硬件、讀取配置的地方HDF框架保證設(shè)備已經(jīng)ready你可以通過device-property拿到配置節(jié)點(diǎn)Release是在驅(qū)動卸載或者設(shè)備移除時(shí)調(diào)的所有申請過的資源都要在這兒還回去。moduleName這個(gè)字段非常關(guān)鍵它就是HCS設(shè)備節(jié)點(diǎn)里用來指定驅(qū)動的那個(gè)名字必須完全一致少一個(gè)字符都匹配不上。3.2 配置側(cè)兩步走驅(qū)動代碼寫完后要讓HDF框架知道“這個(gè)驅(qū)動應(yīng)該被加載”需要改兩個(gè)層面的HCS配置。第一層是設(shè)備節(jié)點(diǎn)聲明一般在device_info.hcs里root { device_info { gpioHost { device0 :: deviceNode { policy 2; priority 10; preload 0; permission 0664; moduleName gpio_demo_driver; serviceName gpio_demo_service; deviceMatchAttr gpio_demo_config; } } } }這一段的意思是在gpioHost這個(gè)設(shè)備宿主下面聲明一個(gè)名為device0的設(shè)備節(jié)點(diǎn)。moduleName對應(yīng)驅(qū)動入口里的名字deviceMatchAttr是對應(yīng)業(yè)務(wù)配置節(jié)點(diǎn)的匹配關(guān)鍵字serviceName是驅(qū)動對外暴露的服務(wù)名用戶態(tài)程序綁定服務(wù)時(shí)要用它policy表示服務(wù)發(fā)布策略2代表對用戶態(tài)可見priority是加載優(yōu)先級數(shù)字越小越先加載。第二層是業(yè)務(wù)配置寫在你自己新建的hcs文件里root { gpio_demo_config { match_attr gpio_demo_config; pin 12; direction 1; initValue 0; } }注意看這個(gè)節(jié)點(diǎn)的match_attr值和device_info.hcs里的deviceMatchAttr必須一致。這一步就是HDF框架把“設(shè)備節(jié)點(diǎn)”和“具體配置塊”關(guān)聯(lián)起來的關(guān)鍵。如果不匹配驅(qū)動還是會被加載但I(xiàn)nit里通過match_attr去查配置時(shí)會查不到返回空指針啟動日志里就會報(bào)類似load hcs node failed的錯(cuò)誤。3.3 用戶態(tài)調(diào)用鏈路配置對、驅(qū)動跑起來之后用戶態(tài)應(yīng)用怎么調(diào)用這個(gè)驅(qū)動簡單說一下鏈路應(yīng)用通過HDF提供的IO服務(wù)接口按服務(wù)名綁定驅(qū)動然后把命令字和參數(shù)打包進(jìn)HdfSBuf通過dispatcher分發(fā)下去。#include hdf_io_service_if.h struct HdfIoService *serv HdfIoServiceBind(gpio_demo_service, 0); if (serv NULL) { return -1; } struct HdfSBuf *data HdfSbufObtainDefaultSize(); struct HdfSBuf *reply HdfSbufObtainDefaultSize(); // 寫入一個(gè)命令字比如設(shè)置GPIO電平 int32_t ret HdfSbufWriteInt32(data, 1); ret serv-dispatcher-Dispatch(serv-object, 0, data, reply); HdfSbufRecycle(data); HdfSbufRecycle(reply); HdfIoServiceRecycle(serv);這段代碼在用戶態(tài)應(yīng)用進(jìn)程或服務(wù)進(jìn)程運(yùn)行它通過HdfIoServiceBind從服務(wù)管理器那拿到驅(qū)動服務(wù)Dispatch填充命令字驅(qū)動側(cè)在自己的Dispatch回調(diào)里處理。中間真正干活的是HDF框架的消息通道這個(gè)過程不需要你手動開設(shè)備節(jié)點(diǎn)也不用自建socket通信框架全包了。4. RK3568多設(shè)備樹與HCS選型別再瞎猜了4.1 RK3568為什么有那么多dts芯片廠商給RK3568做內(nèi)核適配會按不同開發(fā)板、不同內(nèi)存規(guī)格、不同顯示方案生成一堆dts文件。OpenHarmony的vendor目錄里還會再加一層自己的適配比如dayu200開發(fā)板用的是一套彌合派用的又是一套同一塊板子內(nèi)存規(guī)格不同還要再分。所以你在源碼樹下看到幾十個(gè)rk3568相關(guān)dts太正常了這不是版本混亂是產(chǎn)品形態(tài)本身的多樣性決定的。選錯(cuò)dts的后果很直接內(nèi)核起來后部分外設(shè)不工作串口可能沒輸出屏幕不亮或者WiFi模塊找不到。因?yàn)閐ts里的內(nèi)存參數(shù)、引腳復(fù)用、總線掛載不對內(nèi)核就沒法正確初始化這些硬件。4.2 判斷選沒選對的三個(gè)實(shí)操方法第一看啟動日志。串口啟動日志里會明確打印加載的dtb文件名或者在Kernel command line里看到dtbxxx.dtb之類的參數(shù)。這個(gè)最直接也能幫你確認(rèn)編譯打包階段選的是不是你預(yù)期的那份。第二看product層配置。OpenHarmony的product定義文件中kernel/devicetree相關(guān)配置項(xiàng)會指定編譯哪份dtsdefconfig也會對應(yīng)改。比如有些產(chǎn)品目錄下會寫rk3568_dayu200_defconfig你跟著這個(gè)文件去查dtb列表就知道開發(fā)板默認(rèn)用哪份。第三跑起來后對照實(shí)際外設(shè)。系統(tǒng)起來后查看/proc/device-tree下的節(jié)點(diǎn)確認(rèn)你要用的i2c、spi、gpio節(jié)點(diǎn)都在不在地址對不對。這個(gè)方法在設(shè)備已經(jīng)刷了系統(tǒng)、不方便看編譯配置時(shí)特別有用。4.3 什么情況改設(shè)備樹什么情況改HCS我在實(shí)際項(xiàng)目里總結(jié)了一套選擇邏輯按這個(gè)來基本不會出錯(cuò)場景改哪個(gè)原因換了內(nèi)存顆粒或容量DTS內(nèi)存控制器初始化參數(shù)在dts里換了一顆同接口類型的傳感器HCS驅(qū)動不用重編譯改參數(shù)即可修改引腳復(fù)用功能DTS pinctrl HCS硬件連接變了兩處都要核對新加一個(gè)同型號外設(shè)實(shí)例HCS增加deviceNode和業(yè)務(wù)配置塊調(diào)整中斷、DMA資源DTS資源必須讓內(nèi)核感知到修改驅(qū)動加載順序HCS改deviceNode的priority字段核心認(rèn)知是設(shè)備樹負(fù)責(zé)讓內(nèi)核“看得到”硬件資源HCS負(fù)責(zé)讓HDF驅(qū)動“知道該怎么配置自己”。如果你改了個(gè)驅(qū)動參數(shù)卻改在dts里HDF驅(qū)動不會認(rèn)如果你把寄存器地址設(shè)在HCS里內(nèi)核平臺驅(qū)動也讀不到。兩者聯(lián)動修改時(shí)要先定硬件側(cè)再改邏輯側(cè)。4.4 x86平臺調(diào)試OpenHarmony的HDF/HCS很多人在x86電腦上跑OpenHarmony虛擬機(jī)想調(diào)試驅(qū)動這個(gè)路線可行但要注意平臺的差異。OpenHarmony的HDF框架在x86_64上是正常編譯運(yùn)行的HCS從解析到加載的流程也沒有區(qū)別。區(qū)別在于硬件設(shè)備你沒法在虛擬機(jī)上掛一顆真實(shí)的RK3568外設(shè)所以要么用QEMU模擬的設(shè)備要么干脆寫一個(gè)虛擬驅(qū)動和虛擬HCS節(jié)點(diǎn)專門驗(yàn)證“配置-加載-服務(wù)調(diào)用”這個(gè)框架鏈路。我自己的做法是在x86模擬器上放一個(gè)虛擬傳感器驅(qū)動HCS里配幾組模擬的寄存器地址和上報(bào)頻率驅(qū)動Init里不真正訪問硬件只把配置值打印出來。這樣既能測試HCS是否解析對了、設(shè)備節(jié)點(diǎn)是否匹配上了、服務(wù)能否被用戶態(tài)綁定又不依賴真實(shí)硬件環(huán)境。把這條鏈路跑通了再移植到RK3568真實(shí)板子上剩下的問題就只剩硬件本身的調(diào)參了。5. 高頻報(bào)錯(cuò)與排查速查表5.1 編譯期問題HCS編譯報(bào)錯(cuò)我整理了一張速查表報(bào)錯(cuò)特征常見原因處理方式hcs parse error at line xx缺分號、括號不匹配、數(shù)組元素類型不一致打開文件到對應(yīng)行檢查屬性結(jié)尾分號和括號閉合file not found for hcs: xxxBUILD.gn里的hcs輸入路徑寫錯(cuò)核對相對路徑確認(rèn)文件確實(shí)存在hc-gen: command not found構(gòu)建環(huán)境沒找到hc-gen工具檢查prebuilts目錄下的工具鏈?zhǔn)欠窦尤隤ATH生成的hcb大小為0或異常hcs文件里沒有任何有效節(jié)點(diǎn)確認(rèn)root節(jié)點(diǎn)下是否定義了實(shí)際內(nèi)容編譯期問題多半是低級語法錯(cuò)誤但坑就坑在報(bào)錯(cuò)信息不是總能一眼看出。我的習(xí)慣是拿到一個(gè)hcs文件先看兩樣?xùn)|西整個(gè)文件最后有沒有多一個(gè)分號所有節(jié)點(diǎn)括號是否配對。這兩個(gè)占了解析錯(cuò)誤的一半以上。5.2 運(yùn)行期問題驅(qū)動跑起來后的報(bào)錯(cuò)才是大頭。常見幾類[HDF_DM] Fail to load device node說明設(shè)備管理器根據(jù)moduleName找不到對應(yīng)的驅(qū)動入口。檢查HdfDriverEntry.moduleName和deviceNode里的moduleName是不是完全一致。[HDF_DM] match attr not found業(yè)務(wù)配置節(jié)點(diǎn)沒找到。重點(diǎn)核對match_attr和deviceMatchAttr是否一致hcb文件有沒有重新打進(jìn)鏡像。service not registered用戶態(tài)綁定時(shí)服務(wù)還沒注冊。通常是驅(qū)動Init沒執(zhí)行成功或者serviceName寫錯(cuò)先看Init階段的報(bào)錯(cuò)日志。這里特別提醒一句網(wǎng)上搜“missing hcs services: hns、vmcompute、vfpext”這類報(bào)錯(cuò)時(shí)看到的多半是Windows系統(tǒng)里Hyper-V相關(guān)服務(wù)的提示跟OpenHarmony的HCS沒有半毛錢關(guān)系別被帶偏了。OpenHarmony里HCS配置有問題報(bào)錯(cuò)關(guān)鍵字一般是HDF_DM、hdf devhost、load hcs node這些才是你要找的方向。5.3 設(shè)備樹和HCS沖突的處理HDF驅(qū)動和設(shè)備樹直接搶同一個(gè)硬件資源的情況調(diào)試時(shí)很常見。典型現(xiàn)象HDF驅(qū)動在Init里訪問某組寄存器返回busy或者日志顯示內(nèi)核平臺驅(qū)動已經(jīng)占用了這個(gè)設(shè)備。這種沖突的標(biāo)準(zhǔn)解法是在設(shè)備樹里把對應(yīng)節(jié)點(diǎn)的status okay改成status disabled或者把該外設(shè)從內(nèi)核平臺驅(qū)動的支持列表里去掉讓寄存器資源空出來交給HDF側(cè)接管。改完之后要注意不能用設(shè)備樹禁用了某個(gè)總線節(jié)點(diǎn)導(dǎo)致HDF驅(qū)動里面通過系統(tǒng)接口訪問這個(gè)總線也失敗那就變成砍斷了路又要求人走路。正確的順序是先確認(rèn)這個(gè)外設(shè)不需要內(nèi)核平臺驅(qū)動管再禁用設(shè)備樹節(jié)點(diǎn)然后在HCS里把完整的驅(qū)動參數(shù)補(bǔ)上。5.4 調(diào)試HDF的常用日志和工具調(diào)試HDF驅(qū)動日志是最重要的工具。OpenHarmony的hilog日志系統(tǒng)默認(rèn)會帶組件標(biāo)簽HDF相關(guān)的標(biāo)簽很集中hilog | grep HDF_DM hilog | grep HDF_DEV_SVC hilog | grep HDF_PLATFORM在驅(qū)動代碼里使用HDF_LOGE、HDF_LOGI輸出業(yè)務(wù)日志比直接用printf規(guī)范得多關(guān)鍵的是HDF_LOGE會自動帶上文件和行號信息出問題回看日志能省很多功夫。還有一個(gè)笨但有效的驗(yàn)證方法寫一個(gè)最小的測試驅(qū)動Init里只做一件事把從HCS讀到的配置項(xiàng)原樣打印出來用來確認(rèn)配置有沒有被正確解析。這個(gè)驅(qū)動平時(shí)不干活但它能幫你把問題快速切成兩半是配置沒進(jìn)來還是驅(qū)動邏輯出錯(cuò)。6. 寫在驅(qū)動調(diào)試之后的一點(diǎn)經(jīng)驗(yàn)真說起來HDF和HCS這對搭檔最考驗(yàn)人的不是它們各自多復(fù)雜而是改一邊的時(shí)候必須同時(shí)想到另一邊。我調(diào)過一塊RK3568板子串口日志一直報(bào)load hcs node failed檢查了drivername、serviceName、match_attr全都沒問題最后發(fā)現(xiàn)是device_info文件里多寫了一個(gè)分號導(dǎo)致整個(gè)節(jié)點(diǎn)解析錯(cuò)位看著像沒匹配上其實(shí)是解析器已經(jīng)提前退場了。建議所有剛接觸OpenHarmony驅(qū)動開發(fā)的朋友不要一上來就寫全量配置。第一次跑通一個(gè)小外設(shè)就放一組最小HCS配置Init里只打印日志先確認(rèn)配置能讀進(jìn)來、服務(wù)能綁上再逐步加參數(shù)、加邏輯。用V1重新編譯抓完整命令用hc-gen單獨(dú)編hcs再對比生成的hcb文件這些老辦法往往比端到端盲猜快得多。把配置和代碼當(dāng)成一對永遠(yuǎn)要同步修改的搭檔能少走非常多彎路。