前言
參考文章
HDF驅動開發
HDF驅動管理
概述
HDF驅動架構，為驅動開發者提供驅動架構能力，包括驅動加載、驅動服務管理和驅動消息機制。旨在建構統一的驅動架構系統，為驅動開發者提供更精準、更高效的開發環境，力求做到一次開發，多系統部署。
開發者可以通過DevEco Device Tool的HDF功能管理和添加裝置的驅動，添加驅動時，工具會自動生成相應的驅動目錄結構、初始化驅動模闆、代碼及頭檔案等資訊。
前提條件
- 開發闆：Hi3516DV300開發闆（目前隻支援該開發闆，并且支援LiteOS核心和Linux核心的HDF驅動模闆生成）
- 源碼：OpenHarmonyV3.1 Release及後續版本源碼。
- 工具：DevEco Device Tool
使用體驗
通過HDF架構自動生成确實對于小型系統和标準系統的開發帶來很大便利，編寫驅動代碼時可以減少對編譯建構的關注，而更加關注到驅動代碼編寫本身，提高代碼編寫效率，并且會生成代碼架構，命名格式什麼都比較規範，可以省去很多時間用于架構的編寫或複制修改。缺點就是目前支援的開發闆隻有一個，希望後續可以完善，支援更多的開發闆，這個功能是真的很好用。
建立HDF驅動子產品
點開Deveco Device Tool插件圖示，在工具控制區中點選HDF進入驅動添加頁面，選擇産品，目前隻有ipcamera_hispark_taurus與ipcamera_hispark_taurus_linux與hispark_taurus_standard三款産品支援使用，未支援的産品無法點選+号添加HDF子產品。
在添加驅動子產品對話框中，填寫子產品名稱，然後點選添加。
說明
隻有标準系統的産品，在添加驅動的時候，需要選擇“RunMode”：user和kernel；小型系統的産品隻需要填寫Module名稱即可。
添加後，可點選Action下的删除按鈕删除已添加的子產品。
添加後，可以在Driver Module下看到已添加的子產品，使用LiteOS核心與Linux核心生成的會有所不同。
生成後會自動幫我們配置好編譯鍊，自動生成MakeFile，BUILD.gn，Kconfig，C++驅動代碼模闆等。
驅動代碼實作
點選子產品檔案下的檔案圖示，可以打開檔案，進行驅動開發。點選c/c++即可進行驅動代碼的開發。生成的模闆如下。（找了官方的含有中文注釋的圖）
為了驗證HDF驅動是否成功編譯進核心，對驅動代碼進行些許修改，在Init函數中加入了紅外LED燈的點亮，通過查閱原理圖得到，紅外led的引腳号為41，代碼如下，需包含#include "gpio_if.h"頭檔案用于控制gpio，隻是驗證的話就不寫使用者态的函數了。
#include "hdf_device_desc.h" // Header file that describes the APIs provided by the HDF to the driver.
#include "hdf_log.h" // Header file that describes the log APIs provided by the HDF.
#include "gpio_if.h" //添加GPIO驅動頭檔案
#define HDF_LOG_TAG hello_linux_driver // Tag contained in logs. If no tag is not specified, the default HDF_TAG is used.
// The driver service struct definition
struct ITestDriverService {
struct IDeviceIoService ioService; // The first member of the service structure must be a member of type IDeviceIoService
};
// The driver service interface must be bound to the HDF for you to use the service capability.
static int32_t HdfHelloLinuxDriverBind(struct HdfDeviceObject *deviceObject) {
HDF_LOGI("hello_linux driver bind success");
return 0;
}
// Initialize the driver service.
static int32_t HdfHelloLinuxDriverInit(struct HdfDeviceObject *deviceObject) {
HDF_LOGI("Hello Linux");
GpioSetDir(41,GPIO_DIR_OUT);//引腳設定為輸出
GpioWrite(41,GPIO_VAL_HIGH);//輸出高電平，紅外燈亮
return 0;
}
// Release the driver resources.
static void HdfHelloLinuxDriverRelease(struct HdfDeviceObject *deviceObject) {
HDF_LOGI("hello_linux driver Release success");
return;
}
// Define the object of the driver entry. The object must be a global variable of the HdfDriverEntry type (defined in hdf_device_desc.h).
struct HdfDriverEntry g_hello_linuxDriverEntry = {
.moduleVersion = 1,
.moduleName = "hello_linux_driver",
.Bind = HdfHelloLinuxDriverBind,
.Init = HdfHelloLinuxDriverInit,
.Release = HdfHelloLinuxDriverRelease,
};
// Call HDF_INIT to register the driver entry with the HDF framework. When loading the driver, call the Bind function and then the Init function. If the Init function fails to be called, the HDF will call Release to release the driver resource and exit.
HDF_INIT(g_hello_linuxDriverEntry);
燒錄驗證
接着進行編譯燒錄啟動，不清楚的可以看下面這篇文章：
Hi3516DV300 OpenHarmony3.1環境配置及燒錄
點選monitor開啟序列槽監視，可以看到列印出了Hello Linux的LOG，說明驅動成功初始化，同時可以看到紅外燈成功點亮。
後記
雖然通過工具自動生成代碼很友善，但還是建議初學者要搞清楚HDF架構的具體實作流程，手動實作一遍，了解編譯的整個流程，這對了解OpenHarmony代碼及架構還是非常有幫助的，工具最好當成你能熟練掌握後提高效率的助手。而且工具也不一定支援所有情況，了解整個HDF後即使遇到一些特殊情況也能有辦法解決，後面的一篇文章我将會深入HDF的驅動開發流程，并且比較LiteOS核心與Linux核心HDF驅動開發的差別。
【本文正在參加物聯網有獎征文活動】，活動連結：https://ost.51cto.com/posts/14758