??想了解更多關于開源的內容，請訪問：??

??51CTO 開源基礎軟件社區(qū)??

??https://ost.51cto.com??

前言

之前在研究HDF驅動過程中，發(fā)現(xiàn)對于標準系統(tǒng)，HDF已經提供了統(tǒng)一的一套Linux驅動適配，例如使用開發(fā)板外設gpio，pwm等，都可以直接使用HDF提供的平臺設備接口適配linux內核代碼。然后在使用九聯(lián)UnionPi-Tiger開發(fā)板HDF平臺接口時，發(fā)現(xiàn)開發(fā)板并沒有對ADC的HDF進行適配，然后發(fā)現(xiàn)其他標準系統(tǒng)開發(fā)板也沒有將ADC的HDF驅動適配到開發(fā)板上，但是又能在OpenHarmony源碼中找到HDF適配linux內核的ADC驅動代碼，所以嘗試自己進行一波驅動適配，適配完后也是成功能正常調用HDF平臺提供的統(tǒng)一ADC驅動接口。

參考

??drivers_adapter_khdf_linux??平臺驅動開發(fā)——ADC
驅動子系統(tǒng)

前述知識

ADC

1. 簡介:
   ADC（Analog to Digital Converter），即模擬-數(shù)字轉換器，是一種將模擬信號轉換成對應數(shù)字信號的設備。
2. 基本概念:

• 分辨率：即每個采樣數(shù)據(jù)精度，用多少位數(shù)字來表示采集到一個模擬量，分辨率越高就能采集越精確的數(shù)據(jù)。常用分辨率：8bit、10bit、12bit。
• 精度：即模擬量轉換成數(shù)字量的精確程度。
• 采樣速率：即每秒對ADC采樣的次數(shù)。

Linux IIO子系統(tǒng)

• IIO（Industrial I/O） 子系統(tǒng)旨在為某種意義上是模數(shù)或數(shù)模轉換器 (ADC，DAC) 的設備提供支持，Linux內核通過IIO框架把模數(shù)轉換的功能集合在一起，包括加速度計，磁力計，陀螺儀，壓力傳感器， 濕度傳感器，溫度傳感器等都屬于IIO系列器件。
• IIO作為字符設備暴露給用戶空間，用戶可直接在設備樹中使能該功能，與IIO驅動程序交互獲取采樣值。

可以動手做一個小嘗試，電腦連接開發(fā)板進入開發(fā)板終端，進入/sys/bus/iio/iio:device，表示傳感器及通道，對于UnionPi_Tiger開發(fā)板，可以看到開發(fā)板提供in_voltage0_raw-in_voltage7_raw 8個ADC采樣通道。

讀取ADC采樣值，使用軟件寫入start的方式，每次觸發(fā)一次采樣:
執(zhí)行cat /sys/bus/iio/devices/iio:device0/xxx_raw即可獲取對于通道的采值。

例如，查看數(shù)據(jù)手冊，可以知道開發(fā)板外設對于的通道為2和3。

所以我們讀取開發(fā)板的ADC外設可以通過如下命令：

Linux內核部署OpenHarmony驅動框架

OpenHarmony平臺驅動（Platform Driver），即平臺設備（Platform Device）驅動，為系統(tǒng)及外設驅動提供訪問接口。這里的平臺設備，泛指I2C/UART等總線、以及GPIO/RTC等特定硬件資源。平臺驅動框架是OpenHarmony驅動框架的重要組成部分，它基于HDF驅動框架、操作系統(tǒng)適配層以及驅動配置管理機制，為各類平臺設備驅動的實現(xiàn)提供標準模型。平臺驅動框架為外設提供了標準的平臺設備訪問接口，使其不必關注具體硬件；同時為平臺設備驅動提供統(tǒng)一的適配接口，使其只關注自身硬件的控制。

對于OpenHarmony標準系統(tǒng)來說，內核使用的是統(tǒng)一的Linux系統(tǒng)內核，這也就是說對于大部分的一些驅動模型，驅動接口，都可以使用統(tǒng)一的一套框架進行適配，也就是在Linux內核部署OpenHarmony的HDF驅動子系統(tǒng)，這樣可以提供歸一化的驅動平臺底座，做到一次開發(fā)，多系統(tǒng)部署。在OpenHarmony源碼中存放對于驅動子系統(tǒng)適配linux內核的代碼和編譯腳本，具體路徑為drivers/hdf_core/adapter/khdf/linux，提供了各種驅動模型的適配例如音頻驅動模型，顯示驅動模型，以及平臺設備接口適配linux內核代碼，例如gpio接口，adc接口，倉庫鏈接：https://gitee.com/openharmony/drivers_adapter_khdf_linux。

ADC模塊運作機制：統(tǒng)一服務模式

在HDF框架中，同類型設備對象較多時（可能同時存在十幾個同類型配置器），若采用獨立服務模式，則需要配置更多的設備節(jié)點，且相關服務會占據(jù)更多的內存資源。相反，采用統(tǒng)一服務模式可以使用一個設備服務作為管理器，統(tǒng)一處理所有同類型對象的外部訪問（這會在配置文件中有所體現(xiàn)），實現(xiàn)便捷管理和節(jié)約資源的目的。ADC模塊即采用統(tǒng)一服務模式。

在統(tǒng)一模式下，所有的控制器都被核心層統(tǒng)一管理，并由核心層統(tǒng)一發(fā)布一個服務供接口層，因此這種模式下驅動無需再為每個控制器發(fā)布服務。

驅動適配過程

一、開啟HDF_PLATFORM_ADC模塊控制宏

HDF的驅動一般都由對應的模塊控制宏進行控制編譯，默認是不使能編譯的（可以在對于的Kconfig文件查看），產品需要手動開啟模塊控制宏使之參與到產品編譯，這樣做的好處就是構建彈性化的框架能力。對于unionpi_tiger開發(fā)板，對于的配置文件位于device/board/unionman/unionpi_tiger/kernel/build/unionpi_tiger_standard_defconfig，可以看到默認情況下，對于該開發(fā)板是不提供ADC的HDF驅動能力的，因為還沒有做好對應功能的適配，也就是不能直接使用平臺提供的統(tǒng)一驅動接口。

在這里我們將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）：提供打開設備，寫入讀取數(shù)據(jù)，關閉設備的能力。
• 核心層(adc_core)：主要負責服務綁定、初始化以及釋放管理器，并提供添加、刪除以及獲取控制器的能力。
• 適配層(adc_iio_adapter)：由驅動適配者實現(xiàn)與硬件相關的具體功能，如控制器的初始化等。

二、接口說明及屬性配置

根據(jù)官方文檔，ADC模塊適配必選的三個環(huán)節(jié)是實例化驅動入口，配置屬性文件，以及實例化核心層接口函數(shù)。

1. 實例化驅動入口

• 實例化HdfDriverEntry結構體成員。
• 調用HDF_INIT將HdfDriverEntry實例化對象注冊到HDF框架中。

2. 配置屬性文件

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

3. 實例化核心層接口函數(shù)

• 初始化AdcDevice成員。
• 實例化AdcDevice成員AdcMethod。

實例化驅動入口以及實例化核心層接口函數(shù)已經實現(xiàn)，對于其中的一些具體實現(xiàn)原理，可以到drivers/hdf_core/adapter/khdf/linux/platform/adc/adc_iio_adapter.c的驅動適配層代碼進行查看，本質上也是對Linux IIO子系統(tǒng)的一些應用進行操作，對于他的實現(xiàn)過程，我也畫了一張圖進行總結，可能需要花點心思才能搞懂其中的邏輯，我在畫這種圖的時候就感受到了，可能也有不完整或不對的地方，歡迎指正。

核心層和適配層的代碼已經實現(xiàn)，我們需要做的是對屬性文件進行配置。

1、添加deviceNode描述

路徑vendor/unionman/unionpi_tiger/hdf_config/khdf/device_info/device_info.hcs，統(tǒng)一服務模式的特點是device_info.hcs文件中第一個設備節(jié)點必須為ADC管理器，其各項參數(shù)如下設置：

從第二個節(jié)點開始配置具體ADC控制器信息，第一個節(jié)點并不表示某一路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通道數(shù)量
                driver_channel0_name = "";  //通道0在linux文件系統(tǒng)路徑
                driver_channel1_name = ""; //通道1在linux文件系統(tǒng)路徑
                deviceNum = 0;  //設備號標識
                scanMode =  0;  //掃描模式（必要，但實際使用參數(shù)無意義）
                rate = 1000;    //轉換速率（必要，但實際使用參數(shù)無意義）
            }

            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";
            }
        }
    }
}

對于參數(shù)的配置，可以對照適配層代碼進行理解。

配置完后必須在hdf.hcs文件中將其包含，否則配置文件無法生效。

需要注意的點：

• 因為為統(tǒng)一服務模式，match_attr = "linux_adc_adapter"必須配置在驅動適配器配置外部，否則會找不到設備，這個在后面會解釋。并且這里的channelNum為通道總數(shù)，不是設備通道號。
• driver_channelX_name需要根據(jù)通道號數(shù)量配置好每一個通道對于Linux的iio子系統(tǒng)對應通道路徑，上述有提到Tiger開發(fā)板有8個ADC通道，但實際上能用到的通道只有2，3，所以直接配置通道數(shù)為二即可，并將通道2，3分別映射到driver_channel0_name及driver_channel1_name上。
• deviceNum為自定義的設備號，在調用開啟對應ADC設備時需要對應設備標識號。
• scanMode和rate雖然在驅動沒有用到，但需要獲取到，都需要進行配置，值并無意義。

適配過程遇到的問題

配置文件中match_attr的位置

• 統(tǒng)一服務模式與獨立服務模式的驅動配置模式是不一樣的，例如uart屬于獨立服務模式，每一個設備對象會獨立發(fā)布一個設備服務來處理外部訪問，需要為每一個設備單獨配置器件屬性，每個器件節(jié)點都需要一個match_attr進行匹配，代碼中體現(xiàn)為直接使用DeviceResourceGetIfaceInstance獲取drsOps方法獲取設備參數(shù)。
• 而統(tǒng)一服務模式則使用一個設備服務作為管理器，統(tǒng)一處理所有同類型對象的外部訪問，驅動無需再為每個控制器發(fā)布服務，在代碼中的體現(xiàn)為統(tǒng)一服務模式需要宏??DEV_RES_NODE_FOR_EACH_CHILD_NODE(node, childNode)??? 遍歷、解析.hcs文件中的所有配置節(jié)點，而這也是通過外部的match_attr進行匹配，如果寫在器件內部，則無法匹配上，使用時會提示找不到設備，在遍歷時對每個節(jié)點再使用??DeviceResourceGetIfaceInstance??獲取drsOps方法獲取參數(shù)，二者區(qū)別訪問配置文件節(jié)點的深度問題。
  二者配置文件的差異，也在下面給大家放出來。

編譯問題

1. 在修改.hcs配置文件時，經常遇到配置之后沒效果，那可能時hcs文件沒進行重新編譯，因為我修改完后生成的.hcb文件以及.o文件修改日期沒改變，所以每次修改hcs文件建議把生成的文件先刪除在刪除out進行全部重新編譯。
2. 調試過程中有時候debug需要修改到核心層，適配層的代碼，而再次編譯后修改的代碼并沒有生效，這也是需要把原來生成的一些.o文件等刪除，再重新進行全量編譯。

后記

篇幅有限，為避免內容太亂，將適配完后對HDF平臺接口的使用放在了下一篇，下一篇將使用HDF提供的統(tǒng)一驅動接口驅動LM35溫度傳感器來驗證ADC驅動的適配結果。

??想了解更多關于開源的內容，請訪問：??

??51CTO 開源基礎軟件社區(qū)??

??https://ost.51cto.com??