|
在應用代碼中我們實現如下功能： 當應用程序啟動后會獲取命令行參數。如果命令行沒有參數，LED 燈將循環閃爍；如果命令行帶有參數，則根據傳輸的參數控制 LED 燈的開啟或關閉。通過 HdfIoServiceBind 綁定 LED燈的 HDF 服務，獲取 HDF 空間緩存區，并向該緩沖區寫入控制數據。然后，通過 LED_WRITE 命令將數據發送到 HDF 驅動，從而控制 LED 燈的亮滅。在程序結束時，會回收 HDF 空間緩沖區和 HDF 服務。 接下來編寫應用測試文件 led_test.c，完整代碼如下所示。 
接下來編寫應用 APP 的 GN 文件 BUILD.gn，代碼內容如下所示：
上面的代碼用于構建一個“led_test”的可執行文件的構建腳本，它使用了 GN（Generate Ninja）構建系統，這是一種元構建系統，用于生成 Ninja 構建文件。 1-2 行定義了兩個變量 HDF_FRAMEWORKS 和 HDF_ADAPTER，它們分別指向 HDF（HardwareDriver Foundation，硬件驅動框架）核心框架和適配器的路徑。這些路徑是相對于項目根目錄的。 4-5 行 使用 import 語句導入兩個 GNI（GN Include）文件。GNI 文件是 GN 構建系統用來包含變量定義、函數和模板的文件。這里導入的文件可能包含了一些預定義的變量、函數或構建規則，用于支持構建過程。//build/ohos.gni 可能包含了 OpenHarmony 特有的構建配置，而$HDF_ADAPTER/uhdf2/uhdf.gni 可能包含了與 uHDF（Unified Hardware Driver Framework，統一硬件驅動框架）相關的配置。 7 行 打印一條消息到控制臺，表明正在編譯 led_test 示例。 9-40 行 定義一個名為 led_test 的 ohos_executable 目標，這是一個構建規則，用于生成一 個可執行文件。下面是該目標的具體配置： sources：指定源文件列表，這里只有一個文件 led_test.c。 include_dirs：指定頭文件搜索路徑列表。這些路徑用于在編譯時查找包含的文件（#include指令引用的文件）。這些路徑包括了 HDF 框架、適配器的多個子目錄，以及一些第三方庫和內部工具庫的頭文件路徑。 external_deps：指定外部依賴項列表。這些依賴項是在構建過程中需要鏈接的庫。這里列出了幾個庫，如 c_utils:utils、hdf_core:libhdf_platform 等，這些庫提供了構建 led_test 所需的功能。 cflags：指定傳遞給 C 編譯器的標志列表。這里包括了一些常見的編譯選項，如-Wall（打開所有警告）、-Wextra（打開額外警告）、-Werror（將所有警告視為錯誤）、以及兩個用于關閉特定警告的選項。 part_name：指定構建產物所屬的部件名稱，這里是 demos。 install_enable：設置為 true，表示構建產物應該被安裝。這可能意味著在構建成功后，led_test可執行文件會被復制到某個特定的目錄，以便于執行或分發。 |
