# OhosLedCtrl **Repository Path**: nan-shuaibo/led_ctrl ## Basic Information - **Project Name**: OhosLedCtrl - **Description**: 这是《沉浸式剖析OpenHarmony源代码(梁开祝 著)》一书第9章的驱动示例程序。 请参考代码根目录下的README.md文件配置编译本工程,参考commit_log.md文档的说明,从简单到复杂一步步验证HDF的相关技术要点。 - **Primary Language**: C - **License**: Apache-2.0 - **Default Branch**: master - **Homepage**: https://ost.51cto.com/column/46 - **GVP Project**: No ## Statistics - **Stars**: 0 - **Forks**: 2 - **Created**: 2023-05-21 - **Last Updated**: 2023-05-21 ## Categories & Tags **Categories**: Uncategorized **Tags**: None ## README # 示例程序:led_ctrl ## 1. 概述 - 硬件平台:**润和AI_Camera_Hi3516DV300开发板 + 润和DAYU200开发板** - 软件分支:**OpenHarmony master【2022.10.01】** - 部署路径: **//drivers/hdf_core/framework/sample/** - 注意:*本仓库LTS3.0分支,对应适配OHOS LTS3.0分支代码;OHOS的master分支或者3.1 Release版本代码,因代码结构的大调整,本示例程序的部署和编译配置也要跟着调整,对应为本仓库master分支或Rel3.1分支。* ​ 这是梁开祝著的《沉浸式剖析OpenHarmony源代码》一书,"第9章 驱动子系统"的"9.2 通用的驱动示例程序"的相关资源。书籍主仓库为[**OhosStudyNote**](https://gitee.com/liangkzgitee/ohos_study_note),本示例程序单独仓库为[**OhosLedCtrl**](https://gitee.com/liangkzgitee/led_ctrl)。 示例程序通过控制GPIO接口,点亮Hi3516开发板上的绿色指示灯、红色指示灯,在小型系统(适配LiteOS_A内核和Linux内核)、标准系统上都适用,只需要针对性地修改编译配置脚本即可。在DAYU200开发板上适配该驱动示例程序,实际上只需要修改hcs配置文件中的GPIO管脚号即可。 开发者可将本示例程序部署到OpenHarmony任意路径下,只要将本文中对应的路径替换正确即可。 同目录下的commit_log.md文档,记录了本项目的几次提交信息,从最简单的基础功能开始,逐渐添加和修改一些复杂的功能实现,以演示和逐步加深对OpenHarmony驱动框架的理解。 ## 2. 目录结构 dir ## 3. 编译配置 ### 3.1. apps/ #### 3.1.1 小型系统(LiteOS_A内核和Linux内核) 在编译应用程序时,两个内核的小型系统的编译配置是一样的。**两种方法**: **方法一**:led_green 部署到 applications 直接利用小型系统已经在applications子系统中包含的**camera_sample_app**组件即可。 打开 //applications/sample/camera/bundle.json 文件,在“build”->"sub_component"添加需要编译的组件的信息即可: "build": { "sub_component": [ "//drivers/hdf_core/framework/sample/led_ctrl/apps/led_green_ctrl:led_green", "//applications/sample/camera/launcher:launcher_hap", ...... "//applications/sample/camera/media:media_sample" ], "inner_kits": [], "test": [] } **方法二**:led_red 部署到到 uhdf 直接利用小型系统已经在hdf子系统中包含的**hdf_core**组件即可。 打开 //drivers/hdf_core/adapter/BUILD.gn 文件,在ohos_lite的group("uhdf_entry")中的deps关系中,添加下面一句语句即可: deps = [ "//drivers/hdf_core/framework/sample/led_ctrl/apps/led_red_ctrl:led_red", ...... ], 上面两种方法所添加的target的路径,指向需要编译的app的BUILD.gn所在的路径和编译目标,确保格式和依赖关系没错即可。它们生成的可执行程序会部署到系统的./bin/目录下。 #### 3.1.2 标准系统(Linux内核) 在标准系统上配置两个应用的编译,与3.1.1的类似。 **方法一**:led_green 应用部署在 app/std/hap 打开 //applications/standard/hap/ohos.build 文件,在其module_list上增加下面一句语句即可: `"//drivers/hdf_core/framework/sample/led_ctrl/apps/led_green_ctrl:led_green",` **方法二**:led_red 应用部署在 uhdf2 打开 //drivers/adapter/bundle.json文件,找到device_driver_framework组件的sub_component信息,可见"//drivers/adapter:uhdf_entry",打开//drivers/adapter/BUILD.gn,在它的**标准系统**的"uhdf_entry"的deps关系中,添加下面一句语句即可: deps = [ "//drivers/hdf_core/framework/sample/led_ctrl/apps/led_red_ctrl:led_red", ...... ], > **注意**:最新的master分支代码上,“//drivers/framework/sample”路径已经修改为“//drivers/hdf_core/framework/sample”;同时“ //drivers/adapter/”目录下已经不存在“bundle.json”文件,可以去修改“//drivers/hdf_core/adapter/BUILD.gn”文件,在标准系统的group("uhdf_entry")中添加依赖的编译目标即可。 上面两种方法所添加的target的路径,指向需要编译的app的BUILD.gn所在的路径和编译目标,确保格式和依赖关系没错即可。它们生成的可执行程序会部署到系统的./bin/目录下。 **注意**:在应用程序的部署和编译配置上,部署在uhdf部分的led_red程序,与LTS3.0分支上有点不一样。对标准系统的应用程序的编译配置上(见对应的BUILD.gn),因为代码结构的变化,导致依赖的库、include的头文件、以及部分API,均有变化,请注意区分。 ### 3.2. config/ 这是led设备的hcs配置文件,按如下三部分进行配置,可分别将led设备的hcs配置文件加入到对应系统的设备配置树中,一起编译进内核并被使用。 #### 3.2.1 小型系统(Hi3516开发板+LiteOS_A内核) 在//vendor/hisilicon/hispark_taurus/hdf_config/hdf.hcs文件的 include 部分增加两行代码即可: #include "../../../../drivers/hdf_core/framework/sample/led_ctrl/config/led/led_config_hi3516.hcs" #include "../../../../drivers/hdf_core/framework/sample/led_ctrl/config/device_info/device_info.hcs" #### 3.2.2 小型系统(Hi3516开发板+Linux内核) 在//vendor/hisilicon/hispark_taurus_linux/hdf_config/hdf.hcs文件的 include 部分增加两行代码即可: #include "../../../../drivers/hdf_core/framework/sample/led_ctrl/config/led/led_config_hi3516.hcs" #include "../../../../drivers/hdf_core/framework/sample/led_ctrl/config/device_info/device_info.hcs" #### 3.2.3 标准系统(Hi3516开发板+Linux内核) 在//vendor/hisilicon/Hi3516DV300/hdf_config/khdf/hdf.hcs文件的 include 部分增加两行代码即可: #include "../../../../../drivers/hdf_core/framework/sample/led_ctrl/config/led/led_config_hi3516.hcs" #include "../../../../../drivers/hdf_core/framework/sample/led_ctrl/config/device_info/device_info.hcs" #### 3.2.4 标准系统(RK3568开发板+Linux内核) 在//vendor/hihope/rk3568/hdf_config/khdf/hdf.hcs文件的 include 部分增加两行代码即可: #include "../../../../../drivers/hdf_core/framework/sample/led_ctrl/config/led/led_config_rk3568.hcs" #include "../../../../../drivers/hdf_core/framework/sample/led_ctrl/config/device_info/device_info.hcs" ### 3.3. drv/ 这里存放着驱动程序的实现代码,以及编译配置脚本。 驱动开发工程师根据项目的实际情况来修改这里的实现和编译配置。 #### 3.3.1 drv/include/ + drv/src/ 这是驱动程序的头文件和实现代码存放路径,与内核无关。 我们可以修改这里的代码以适配不同的项目、开发板、产品。 #### 3.3.2 drv/build_liteos_a/ 这是驱动程序适配LiteOS_A内核的小型系统的编译配置文件。 **BUILD.gn**:将编译出来的驱动入口“g_ledDriverEntryHdfEntry”链接到OHOS_Image.bin中,有模板的。 这个是BUILD.gn脚本所在路径。BUILD.gn中module_switch用不到就要注释掉,否则会导致驱动入口 “g_ledDriverEntryHdfEntry”无法链接到OHOS_Image.bin中。 在//device/soc/hisilicon/common/platform/BUILD.gn文件的deps关系中,添加如下一句语句: `"//drivers/hdf_core/framework/sample/led_ctrl/drv/build_liteos"` #### 3.3.3 drv/build_linux/ 这是驱动程序适配Linux内核的小型系统和标准系统的编译配置文件。**两处修改**: **修改一**: **Makefile**:编译drv/src/目录下源代码的脚本,有模板的。 在//drivers/hdf_core/adapter/khdf/linux/Makefile文件的末尾,添加如下一句语句即可: `obj-$(CONFIG_DRIVERS_HDF) += ../../../framework/sample/led_ctrl/drv/build_linux/` 把这个Makefile纳入khdf/linux的编译体系中。 **修改二**: **platform.mk**:drv/src/目录下源代码include的头文件路径。 在//drivers/hdf_core/adapter/khdf/linux/platform/platform.mk文件的末尾,添加如下一句语句即可: `ccflags-$(CONFIG_DRIVERS_HDF) +=-I$(srctree)/drivers/hdf/framework/sample/led_ctrl/drv/include` 把这个include头文件路径纳入khdf/linux的编译体系中。 ## 4. 扩展适配别的开发板、产品 本示例程序,可以扩展适配别的开发板和软件产品,需要按上面步骤做针对性的编译配置的修改,以及在驱动程序实现源代码中去针对性地修改对应的GPIO管脚和输出电平控制即可。 ## 5.《沉浸式剖析OpenHarmony源代码》简介 详情见本书主仓库[**OhosStudyNote**](https://gitee.com/liangkzgitee/ohos_study_note)上的资料和开放的部分章节。 本书分为9章,各章介绍的主要内容如下。 - 第1章,“系统简介”:简单介绍OpenHarmony的发展历史、技术特性和发展前景。 - 第2章,“搭建开发环境”:由于OpenHarmony设备开发环境的搭建步骤相当繁琐,很多开发者在入门OpenHarmony驱动开发时都对此颇感头痛,因此本章提供了一个清晰的开发环境搭建步骤,帮助开发者扫清入门的障碍。 - 第3章,“系统架构”:简单介绍OpenHarmony的系统架构和一二级目录结构,旨在让开发者对OpenHarmony有一个整体上的初步认识。 - 第4章,“构建子系统”:OpenHarmony的编译构建体系非常复杂,而且在编译构建时常常会交叉使用多种工具,非常容易让人产生困扰。本章对OpenHarmony的构建体系进行了详细介绍,可以帮助开发者理清头绪,了解OpenHarmony的系统构建基础知识。 - 第5章,“启动流程”:本章详细分析了OpenHarmony的系统服务层中各大功能组件的详细启动流程。 - 第6章,“子系统”:本章分析了在开发OpenHarmony设备驱动时需要关注的部分子系统(特别是DFX子系统和IoT硬件子系统)的具体实现机制。 - 第7章,“分布式任务调度子系统”:本章详细分析了OpenHarmony系统服务框架的基础理念和实现机制,即所有功能和特性,都抽象为服务进行管理和使用。本章内容,在2021年下半年举行的第四届中国软件开源创新大赛代码评注组的评比中荣获二等奖。 - 第8章,“分布式通信子系统”:初步分析了分布式通信子系统的部分组件,其中的软总线组件是OpenHarmony实现万物互联/万物智联的基石。 - 第9章,“驱动子系统”:本章采用自下而上的方式深入分析了OpenHarmony驱动子系统的大量实现细节,为驱动开发者深入理解OpenHarmony的驱动框架提供了一个详细的参考。 受限于时间以及精力,本书暂未涉及与OpenHarmony系统移植相关的内容。但在本书交稿之后,我就开始尝试将OpenHarmony LTS 3.0系统移植到Raspberry Pi 4B开发板上,并将移植过程写成博文发布在个人的技术专栏上,请对系统移植感兴趣的读者到我的技术专栏去进一步学习参考。 另外,我其实也是OpenHarmony的初学者,因此本书中难免会有疏漏和错误之处,恳请各位读者在阅读本书时,如果产生疑问或发现错误,能积极与我联系,大家一起讨论,共同进步。