在应用代码中我们实现如下功能：
当应用程序启动后会获取命令行参数。如果命令行没有参数，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可执行文件会被复制到某个特定的目录，以便于执行或分发。