【本文正在参加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

1. 简介
   ADC（Analog to Digital Converter），即模拟-数字转换器，是一种将模拟信号转换成对应数字信号的设备。
2. 基本概念

• 分辨率：即每个采样数据精度，用多少位数字来表示采集到一个模拟量，分辨率越高就能采集越精确的数据。常用分辨率：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模块适配必选的三个环节是实例化驱动入口，配置属性文件，以及实例化核心层接口函数。

1. 实例化驱动入口

• 实例化HdfDriverEntry结构体成员。
• 调用HDF_INIT将HdfDriverEntry实例化对象注册到HDF框架中。

2. 配置属性文件

• 在device_info.hcs文件中添加deviceNode描述。
• 【可选】添加adc_config.hcs器件属性文件。

3. 实例化核心层接口函数

• 初始化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方法获取参数，二者区别访问配置文件节点的深度问题。
  
  二者配置文件的差异，也在下面给大家放出来。
  
  

编译问题

1. 在修改.hcs配置文件时，经常遇到配置之后没效果，那可能时hcs文件没进行重新编译，因为我修改完后生成的.hcb文件以及.o文件修改日期没改变，所以每次修改hcs文件建议把生成的文件先删除在删除out进行全部重新编译。
   
2. 调试过程中有时候debug需要修改到核心层，适配层的代码，而再次编译后修改的代码并没有生效，这也是需要把原来生成的一些.o文件等删除，再重新进行全量编译。
   

后记

篇幅有限，为避免内容太乱，将适配完后对HDF平台接口的使用放在了下一篇，下一篇将使用HDF提供的统一驱动接口驱动LM35温度传感器来验证ADC驱动的适配结果。