#创作者激励# [FFH]标准系统HDF平台驱动(一)——ADC驱动适配 原创 精华
【本文正在参加2023年第一期优质创作者激励计划】
标准系统HDF平台驱动(一)——ADC驱动适配
个人简介:
深圳技术大学FSR实验室
大三学生,正于九联科技
实习,共同学习研究南向开发
知识。
博客主页:https://ost.51cto.com/person/posts/15624680
@[toc]
前言
之前在研究HDF驱动过程中,发现对于标准系统,HDF已经提供了统一的一套Linux驱动适配,例如使用开发板外设gpio,pwm等,都可以直接使用HDF提供的平台设备接口适配linux内核代码。然后在使用九联UnionPi-Tiger开发板HDF平台接口时,发现开发板并没有对ADC的HDF进行适配,然后发现其他标准系统开发板也没有将ADC的HDF驱动适配到开发板上,但是又能在OpenHarmony源码中找到HDF适配linux内核的ADC驱动代码,所以尝试自己进行一波驱动适配,适配完后也是成功能正常调用HDF平台提供的统一ADC驱动接口。
参考
drivers_adapter_khdf_linux
平台驱动开发——ADC
驱动子系统
前述知识
ADC
- 简介
ADC(Analog to Digital Converter),即模拟-数字转换器,是一种将模拟信号转换成对应数字信号的设备。 - 基本概念
- 分辨率:即每个采样数据精度,用多少位数字来表示采集到一个模拟量,分辨率越高就能采集越精确的数据。常用分辨率:8bit、10bit、12bit。
- 精度:即模拟量转换成数字量的精确程度
- 采样速率:即每秒对ADC采样的次数
Linux IIO子系统
- IIO(Industrial I/O) 子系统旨在为某种意义上是模数或数模转换器 (ADC,DAC) 的设备提供支持,Linux内核通过IIO框架把模数转换的功能集合在一起,包括加速度计,磁力计,陀螺仪,压力传感器, 湿度传感器,温度传感器等都属于IIO系列器件。
- IIO作为字符设备暴露给用户空间,用户可直接在设备树中使能该功能,与IIO驱动程序交互获取采样值。
可以动手做一个小尝试,电脑连接开发板进入开发板终端,进入/sys/bus/iio/iio:device
,表示传感器及通道,对于UnionPi_Tiger开发板,可以看到开发板提供in_voltage0_raw-in_voltage7_raw 8个ADC采样通道。
读取ADC采样值,使用软件写入start的方式,每次触发一次采样:
执行cat /sys/bus/iio/devices/iio:device0/xxx_raw即可获取对于通道的采值。
例如,查看数据手册,可以知道开发板外设对于的通道为2和3。
所以我们读取开发板的ADC外设可以通过如下命令:
Linux内核部署OpenHarmony驱动框架
OpenHarmony平台驱动(Platform Driver),即平台设备(Platform Device)驱动,为系统及外设驱动提供访问接口。这里的平台设备,泛指I2C/UART等总线、以及GPIO/RTC等特定硬件资源。平台驱动框架是OpenHarmony驱动框架的重要组成部分,它基于HDF驱动框架、操作系统适配层以及驱动配置管理机制,为各类平台设备驱动的实现提供标准模型。平台驱动框架为外设提供了标准的平台设备访问接口,使其不必关注具体硬件;同时为平台设备驱动提供统一的适配接口,使其只关注自身硬件的控制。
对于OpenHarmony标准系统来说,内核使用的是统一的Linux系统内核,这也就是说对于大部分的一些驱动模型,驱动接口,都可以使用统一的一套框架进行适配,也就是在Linux内核部署OpenHarmony的HDF驱动子系统,这样可以提供归一化的驱动平台底座,做到一次开发,多系统部署。在OpenHarmony源码中存放对于驱动子系统适配linux内核的代码和编译脚本,具体路径为drivers/hdf_core/adapter/khdf/linux
,提供了各种驱动模型的适配例如音频驱动模型,显示驱动模型,以及平台设备接口适配linux内核代码,例如gpio接口,adc接口,仓库链接:https://gitee.com/openharmony/drivers_adapter_khdf_linux。
ADC模块运作机制:统一服务模式
在HDF框架中,同类型设备对象较多时(可能同时存在十几个同类型配置器),若采用独立服务模式,则需要配置更多的设备节点,且相关服务会占据更多的内存资源。相反,采用统一服务模式可以使用一个设备服务作为管理器,统一处理所有同类型对象的外部访问(这会在配置文件中有所体现),实现便捷管理和节约资源的目的。ADC模块即采用统一服务模式。
在统一模式下,所有的控制器都被核心层统一管理,并由核心层统一发布一个服务供接口层,因此这种模式下驱动无需再为每个控制器发布服务。
驱动适配过程
一. 开启HDF_PLATFORM_ADC模块控制宏
HDF的驱动一般都由对应的模块控制宏进行控制编译,默认是不使能编译的(可以在对于的Kconfig文件查看),产品需要手动开启模块控制宏使之参与到产品编译,这样做的好处就是构建弹性化的框架能力。对于unionpi_tiger开发板,对于的配置文件位于device/board/unionman/unionpi_tiger/kernel/build/unionpi_tiger_standard_defconfig
,可以看到默认情况下,对于该开发板是不提供ADC的HDF驱动能力的,因为还没有做好对应功能的适配,也就是不能直接使用平台提供的统一驱动接口。
在这里我们将CONFIG_DRIVERS_HDF_PLATFORM_ADC
的值配置为y,开启对应驱动能力,追述到编译的源头,其实是使能了drivers/hdf_core/adapter/khdf/linux/platform/adc
目录下的makefile文件参与编译。
include drivers/hdf/khdf/platform/platform.mk
obj-y += $(HDF_PLATFORM_FRAMEWORKS_ROOT)/src/adc/adc_core.o \
$(HDF_PLATFORM_FRAMEWORKS_ROOT)/src/adc/adc_if.o \
./adc_iio_adapter.o
正好可以对应上ADC模块各分层:
- 接口层(adc_if):提供打开设备,写入读取数据,关闭设备的能力。
- 核心层(adc_core):主要负责服务绑定、初始化以及释放管理器,并提供添加、删除以及获取控制器的能力。
- 适配层(adc_iio_adapter):由驱动适配者实现与硬件相关的具体功能,如控制器的初始化等。
二. 接口说明及属性配置
根据官方文档,ADC模块适配必选的三个环节是实例化驱动入口,配置属性文件,以及实例化核心层接口函数。
- 实例化驱动入口
- 实例化HdfDriverEntry结构体成员。
- 调用HDF_INIT将HdfDriverEntry实例化对象注册到HDF框架中。
- 配置属性文件
- 在device_info.hcs文件中添加deviceNode描述。
- 【可选】添加adc_config.hcs器件属性文件。
- 实例化核心层接口函数
- 初始化AdcDevice成员。
- 实例化AdcDevice成员AdcMethod。
实例化驱动入口以及实例化核心层接口函数已经实现,对于其中的一些具体实现原理,可以到drivers/hdf_core/adapter/khdf/linux/platform/adc/adc_iio_adapter.c
的驱动适配层代码进行查看,本质上也是对Linux IIO子系统
的一些应用进行操作,对于他的实现过程,我也画了一张图进行总结,可能需要花点心思才能搞懂其中的逻辑,我在画这种图的时候就感受到了,可能也有不完整或不对的地方,欢迎指正。
核心层和适配层的代码已经实现,我们需要做的是对属性文件进行配置。
1. 添加deviceNode描述
路径vendor/unionman/unionpi_tiger/hdf_config/khdf/device_info/device_info.hcs
,统一服务模式的特点是device_info.hcs文件中第一个设备节点必须为ADC管理器,其各项参数如下设置:
成员名 | 值 |
---|---|
moduleName | 固定为HDF_PLATFORM_ADC_MANAGER |
serviceName | 固定为HDF_PLATFORM_ADC_MANAGER |
policy | 配置为2,对外发布服务 |
deviceMatchAttr | 没有使用,可忽略 |
从第二个节点开始配置具体ADC控制器信息,第一个节点并不表示某一路ADC控制器,而是代表一个资源性质设备,用于描述一类ADC控制器的信息。这里一个ADC设备,如有多个设备,则需要在device_info.hcs文件增加deviceNode信息,以及在adc_config文件中增加对应的器件属性。
device_adc :: device {
device0 :: deviceNode {
policy = 2;
priority = 60;
permission = 0644;
moduleName = "HDF_PLATFORM_ADC_MANAGER";
serviceName = "HDF_PLATFORM_ADC_MANAGER";
}
device1 :: deviceNode {
policy = 0;
priority = 65;
permission = 0644;
moduleName = "linux_adc_adapter";
deviceMatchAttr = "linux_adc_adapter";
}
}
2. 配置器件适配器属性
新增a311d_adc_config.hcs配置文件,在vendor/unionman/unionpi_tiger/hdf_config/khdf/platform
路径下。
root {
platform {
adc_config {
match_attr = "linux_adc_adapter";//与deviceMatchAttr的值一致
template adc_device {
channelNum = 2; //ADC通道数量
driver_channel0_name = ""; //通道0在linux文件系统路径
driver_channel1_name = ""; //通道1在linux文件系统路径
deviceNum = 0; //设备号标识
scanMode = 0; //扫描模式(必要,但实际使用参数无意义)
rate = 1000; //转换速率(必要,但实际使用参数无意义)
}
device_adc_0x0000 :: adc_device {
channelNum = 2;
deviceNum = 0;
driver_channel0_name = "/sys/bus/iio/devices/iio:device0/in_voltage2_raw";
driver_channel1_name = "/sys/bus/iio/devices/iio:device0/in_voltage3_raw";
}
}
}
}
对于参数的配置,可以对照适配层代码进行理解。
配置完后必须在hdf.hcs文件中将其包含,否则配置文件无法生效。
需要注意的点:
- 因为为统一服务模式,match_attr = "linux_adc_adapter"必须配置在驱动适配器配置外部,否则会找不到设备,这个在后面会解释。并且这里的channelNum为通道总数,不是设备通道号。
- driver_channelX_name需要根据通道号数量配置好每一个通道对于Linux的iio子系统对应通道路径,上述有提到Tiger开发板有8个ADC通道,但实际上能用到的通道只有2,3,所以直接配置通道数为二即可,并将通道2,3分别映射到driver_channel0_name及driver_channel1_name上。
- deviceNum为自定义的设备号,在调用开启对应ADC设备时需要对应设备标识号。
- scanMode和rate虽然在驱动没有用到,但需要获取到,都需要进行配置,值并无意义。
适配过程遇到的问题
配置文件中match_attr的位置
- 统一服务模式与独立服务模式的驱动配置模式是不一样的,例如uart属于独立服务模式,每一个设备对象会独立发布一个设备服务来处理外部访问,需要为每一个设备单独配置器件属性,每个器件节点都需要一个match_attr进行匹配,代码中体现为直接使用
DeviceResourceGetIfaceInstance
获取drsOps方法获取设备参数。 - 而统一服务模式则使用一个设备服务作为管理器,统一处理所有同类型对象的外部访问,驱动无需再为每个控制器发布服务,在代码中的体现为统一服务模式需要宏
DEV_RES_NODE_FOR_EACH_CHILD_NODE(node, childNode)
遍历、解析.hcs文件中的所有配置节点,而这也是通过外部的match_attr进行匹配,如果写在器件内部,则无法匹配上,使用时会提示找不到设备,在遍历时对每个节点再使用DeviceResourceGetIfaceInstance
获取drsOps方法获取参数,二者区别访问配置文件节点的深度问题。
二者配置文件的差异,也在下面给大家放出来。
编译问题
- 在修改.hcs配置文件时,经常遇到配置之后没效果,那可能时hcs文件没进行重新编译,因为我修改完后生成的.hcb文件以及.o文件修改日期没改变,所以每次修改hcs文件建议把生成的文件先删除在删除out进行全部重新编译。
- 调试过程中有时候debug需要修改到核心层,适配层的代码,而再次编译后修改的代码并没有生效,这也是需要把原来生成的一些.o文件等删除,再重新进行全量编译。
后记
篇幅有限,为避免内容太乱,将适配完后对HDF平台接口的使用放在了下一篇,下一篇将使用HDF提供的统一驱动接口驱动LM35温度传感器来验证ADC驱动的适配结果。
前排支持大佬新坑
自己适配驱动牛啊