#物联网征文#【FFH】HDF驱动开发流程解析 原创 精华
前言
上一节我们通过DevEco Device Tool生成标准HDF框架,下面我们就以生成的模板,来深入研究HDF驱动开发。本次使用的是Hi3516DV300开发板,分别设置了LiteOS内核以及Linux内核两个版本为例,来了解深入HDF驱动开发流程以及比较Linux内核与LiteOS内核HDF驱动开发异同。
参考文章
HDF的开发流程可以参考下面这篇文章。
驱动开发
实例代码通过DevEco Device Tool生成,代码以及结构比较规范,可以参考下面这篇。
DevEco Device Tool:HDF框架一键生成!
前提准备
本次测试例子使用的是OpenHarmony3.1 release全量代码下配置的两个工程,一个是LiteOS内核的小型系统,另一个是Linux内核的小型系统,并且参考上一篇文章生成HDF框架。
生成的文件包括BUILD.gn, Kconfig, MakeFile, hcs, c/c++的编译,驱动代码等,点击即可跳转到对应的文件。Linux内核和LiteOS内核生成的会有点区别,主要体现在驱动编译方面。
HDF驱动开发步骤
基于HDF框架的驱动开发主要分为三个部分:驱动实现、驱动编译和驱动配置。
一, 驱动实现
驱动实现包含驱动业务代码实现和驱动入口注册,具体写法如下:
驱动入口注册到HDF框架
通过工具生成的驱动代码的位置位于drivers/framework/model里,我们通过Deveco Device Tool生成新增了LiteOS的测试驱动(hello_liteos)以及Linux内核的测试驱动(hello_linux)。
自动生成驱动业务代码以及将驱动入口注册到HDF框架的模板,为区别后续两种内核的驱动实现结果,我修改了一下驱动的初始化化Init函数,Liteos内核驱动实现打印"Hello LiteOS"的日志,而Linux内核的驱动实现打印“Hello Linux”的日志,不过实际测试结果Liteos内核的Hilog打印出了点问题,显示缓冲区满了,尝试增大缓冲区解决无果,所以加了Liteos内核驱动实现让绿色LED等常亮,Linux内核的驱动实现让红外灯常亮来区别。
通过查询原理图可以得:
绿色LED为GPIO2_3引脚,换算成管脚号为2×8+3=19。(Hi3516一组GPIO含有8个引脚),输出高电平点亮。
红外LED为GPIO为GPIO5_1引脚,换算成管脚号为5×8+1=41,输出高电平点亮。
这样就可以修改我们的驱动代码,注意需要包含#include "gpio_if.h"头文件用于控制GPIO,修改代码如下。
二,驱动编译
在创建完成驱动代码后,还要把它加入OpenHarmony的构建系统,LiteOS内核与Linux内核的编译配置流程会有所不同。
LiteOS内核驱动编译
涉及Makefile和BUILD.gn修改:
可以看到在drivers/adapter/khdf/liteos/model新增hello_liteos目录,用于存放驱动编译规则代码,目录下新建了BUILD.gn以及Makefile文件,Kconfig文件文件不参与到驱动编译目前暂不考虑。
MakeFile部分
- 驱动代码的编译必须要使用HDF框架提供的Makefile模板进行编译,在新建的MakeFile文件新建如下代码,生成编译结构文件,也就是生成对应MODULE_NAME的静态库。
- 在drivers/adapter/khdf/liteos/hdf_lite.mk将编译结果文件链接到内核镜像。
编译流程关系如下图:
BUILD.gn部分:
- 新增模块BUILD.gn代码如下:
- 把新增模块的BUILD.gn所在的目录添加到/drivers/adapter/khdf/liteos/BUILD.gn里面:
由于生成的代码是在model模块下的,model已经添加编译到了/drivers/adapter/khdf/liteos/BUILD.gn下,故我们只需在model层下的BUILD.gn下添加模块,也就是在drivers/adapter/khdf/liteos/model/BUILD.gn添加hello_liteos模块到modules中。
用下面这张图来表示他们的编译依赖关系可能会比较清晰一点。
Linux内核驱动编译
在drivers/adapter/khdf/linux/model目录下可以发现新增了新建hello_linux文件夹,用于存放驱动编译规则代码,目录下新建了MakeFile文件用于编译驱动配置。
Makefile部分
- 新增模块Makefile文件里面模块代码编译规则代码如下:
- 添加模块目录到drivers/adapter/khdf/linux/Makefile:
编译流程关系如下:
Kconfig(可选)
如果需要定义模块控制宏,也可以对Kconfig进行配置,在通过工具生成的文件中可以发现还包含Kconfig可视化配置文件,该功能基于Kconfiglib与Kconfig实现,方便用户个性化配置OpenHarmony产品子系统部件。
基于Kconfig实现的可视化配置功能具有以下优点:
- 能直观且全面地展示软件的部件选项。
- 可靠性强,如Linux-kernel、buildroot等知名软件都采用Kconfig进行可视化配置。
目前这个功能对我来说还没什么用,还未深入研究,对于HDF驱动编译配置中没什么影响,可以不进行配置。感兴趣的话可以看看下面这个指导进行学习。
编译构建Kconfig可视化配置指导
三,驱动配置
驱动设备描述
HDF框架加载驱动所需要的信息来源于HDF框架定义的驱动设备描述,因此在vendor/hisilicon/hispark_taurus(_linux)/hdf_config/device_info/device_info.hcs下添加分别驱动设备描述,模板如下
DevEco Device Tool为我们生成的配置如下,可根据需要进行修改:
驱动私有配置信息(可选)
由上图可以看到其中deviceMatchAttr为空,并没有为我们生成私有配置信息,如果驱动有私有配置,则可以添加一个驱动的配置文件,用来填写一些驱动的默认配置信息。HDF框架在加载驱动的时候,会将对应的配置信息获取并保存在HdfDeviceObject中的property里面,通过Bind和Init传递给驱动。驱动的配置信息示例如下:
配置信息定义之后,需要将该配置文件添加到板级配置入口文件hdf.hcs(目录位于vendor/hisilicon/hispark_taurus(_linux)/hdf_config/hdf.hcs),这里就不进行配置了,等下次尝试加入用户态业务代码再演示,示例如下,
结果
对两个内核的工程分别进行编译烧录运行
结果如下
Linux内核:
LiteOS内核:
【本文正在参加物联网有奖征文活动】,活动链接:https://ost.51cto.com/posts/14758
可以参考master分支上的:
rk3568/demo/led_rgb · OpenHarmony/vendor_hihope - 码云 - 开源中国 (gitee.com)
这个示例代码来理解HDF驱动开发的流程。
这个示例程序适配了Hi3516开发板上运行的3个系统和dayu200开发板上运行的标准系统,如果你有其他开发板,只要在 led_rgb/config/led/ 目录下增加一个对应的LED GPIO配置文件,即可适配。
通过私有配置来适配不同的开发板,学到了,这就去搞一个
赞👍
在Linux内核中是不是要开启 Kconfig 的编译选项?