??想了解更多關(guān)于開源的內(nèi)容，請訪問：??

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

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

前言

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

參考

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

前述知識

ADC

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

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

Linux IIO子系統(tǒng)

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

可以動手做一個小嘗試，電腦連接開發(fā)板進(jìn)入開發(fā)板終端，進(jìn)入/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ā)板外設(shè)對于的通道為2和3。

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

Linux內(nèi)核部署OpenHarmony驅(qū)動框架

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

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

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

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

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

驅(qū)動適配過程

一、開啟HDF_PLATFORM_ADC模塊控制宏

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

在這里我們將CONFIG_DRIVERS_HDF_PLATFORM_ADC的值配置為y，開啟對應(yīng)驅(qū)動能力，追述到編譯的源頭,其實是使能了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

正好可以對應(yīng)上ADC模塊各分層：

• 接口層（adc_if）：提供打開設(shè)備，寫入讀取數(shù)據(jù)，關(guān)閉設(shè)備的能力。
• 核心層(adc_core)：主要負(fù)責(zé)服務(wù)綁定、初始化以及釋放管理器，并提供添加、刪除以及獲取控制器的能力。
• 適配層(adc_iio_adapter)：由驅(qū)動適配者實現(xiàn)與硬件相關(guān)的具體功能，如控制器的初始化等。

二、接口說明及屬性配置

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

1. 實例化驅(qū)動入口

• 實例化HdfDriverEntry結(jié)構(gòu)體成員。
• 調(diào)用HDF_INIT將HdfDriverEntry實例化對象注冊到HDF框架中。

2. 配置屬性文件

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

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

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

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

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

1、添加deviceNode描述

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

從第二個節(jié)點開始配置具體ADC控制器信息，第一個節(jié)點并不表示某一路ADC控制器，而是代表一個資源性質(zhì)設(shè)備，用于描述一類ADC控制器的信息。這里一個ADC設(shè)備，如有多個設(shè)備，則需要在device_info.hcs文件增加deviceNode信息，以及在adc_config文件中增加對應(yīng)的器件屬性。

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;  //設(shè)備號標(biāo)識
                scanMode =  0;  //掃描模式（必要，但實際使用參數(shù)無意義）
                rate = 1000;    //轉(zhuǎn)換速率（必要，但實際使用參數(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ù)的配置，可以對照適配層代碼進(jìn)行理解。

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

需要注意的點：

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

適配過程遇到的問題

配置文件中match_attr的位置

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

編譯問題

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

后記

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

??想了解更多關(guān)于開源的內(nèi)容，請訪問：??

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

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