首页
  • GM-3568JHF
  • M4-R1
  • M5-R1
  • SC-3568HA
  • M-K1HSE
  • CF-NRS1
  • CF-CRA2
  • 1684XB-32T
  • 1684X-416T
  • C-3568BQ
  • C-3588LQ
  • GC-3568JBAF
  • C-K1BA
商城
  • English
  • 简体中文
首页
  • GM-3568JHF
  • M4-R1
  • M5-R1
  • SC-3568HA
  • M-K1HSE
  • CF-NRS1
  • CF-CRA2
  • 1684XB-32T
  • 1684X-416T
  • C-3568BQ
  • C-3588LQ
  • GC-3568JBAF
  • C-K1BA
商城
  • English
  • 简体中文
  • SC-3568HA

    • 简介

      • SC-3568HA简介
    • 快速上手

      • OpenHarmony概述
      • 镜像烧录
      • 开发环境准备
      • Hello World应用以及部署
    • 应用开发

      • ArkUI

        • 第一章 ArkTS语言简介
        • 第二章 UI组件介绍和实际应用(上)
        • 第三章 UI组件介绍和实际应用(中)
        • 第四章 UI组件介绍和实际应用(下)
      • 拓展

        • 第一章 入门指引
        • 第二章 三方库的引用和使用
        • 第三章 应用编译以及部署
        • 第四章 命令行恢复出厂设置
        • 第五章 系统调试--HDC调试
        • 第六章 APP 稳定性测试
        • 第七章 应用测试
    • 设备开发

      • 第一章 环境搭建
      • 第二章 下载源码
      • 第三章 编译源码
    • 外设与接口

      • 树莓派接口
      • GPIO 接口
      • I2C 接口
      • SPI通信
      • PWM控制
      • 串口通讯
      • TF Card
      • 屏幕
      • 触摸
      • 音频
      • RTC
      • Ethernet
      • M.2
      • MINI-PCIE
      • Camera
      • WIFI&BT
      • 树莓派拓展板
    • 常见问题

      • 资源下载
  • M-K1HSE

    • 简介

      • M-K1HSE 简介
    • 快速开始

      • 开发环境搭建
      • 源码获取
      • 编译说明
      • 烧录指南
    • 外设与接口

      • 01 Audio
      • 02 RS485
      • 03 Display
    • 系统定制开发

      • 系统移植
      • 系统定制
      • 驱动开发
      • 系统调试
      • OTA升级

驱动开发

Sensor 驱动开发

概述 Sensor 是较为常见的输入设备,用于感知环境状态,从而实现相应的响应。 相较于原始的 Linux 驱动模式,OH 在 HDF(Hardware Driver Foundation)层实现 Sensor 的驱动。 这种实现方式能够实现一次开发,支持在不同的内核环境部署,比如轻量级系统、小系统或者标准 Linux 系统。 此外,在 HDF 框架中,对于不同的驱动能够实现统一管理,每一个驱动都对外能够提供服务,对应用层来说,只需调用 HDI(Hardware Device Interface)接口即可获取驱动服务的能力。

Sensor 驱动模型

OpenHarmony 中基于 HDF 驱动框架的 Sensor 驱动模型如下:

FIRMWARE

Sensor 驱动模型屏蔽硬件器件差异,为上层 Sensor 服务系统提供稳定的 Sensor 基础能力接口, 包括 Sensor 列表查询、Sensor 启停、Sensor 订阅及取消订阅、Sensor 参数配置等功能。

Sensor 设备驱动的开发是在 HDF 驱动框架基础上,结合操作系统抽象层(OSAL, Operating System Abstraction Layer) 和平台驱动接口(比如 I2C/SPI/UART 总线等平台资源)能力,屏蔽不同操作系统和平台总线资源差异,实现 Sensor 驱动 “一次开发,多系统部署” 的目标。

OpenHarmony 中 Sensor 驱动模型分为以下层级:

Hardware:此层决定了 Sensor 设备与 CPU 是如何连接的,外设使用何种方式(比如 I2C、SPI、GPIO 等)进行通讯等等。 Driver:该层实现硬件外设驱动,包括 HdfDriverEntry 中的 bindInit、realese 函数,以及数据 OpsCall 里面的 ReadData。 HDI:接口定义与实现。接口主要包括所有 Sensor 信息查询、Sensor 启停、Sensor 订阅/取消订阅、Sensor 参数配置等稳定的接口,简化服务开发。 Framework:上层 Sensor 服务。

HCS 配置

对于不同的平台,需要在对应的平台目录修改对应的 hcs 文件,下面示例为 smt001 平台下新增 sensor 模块的修改方法。 配置 device_info.hcs 文件路径:vendor/spacemit/smt001/hdf_config/khdf/device_info/device_info.hcs 配置说明:在 device_info.hcs 中添加以下信息。

主要字段说明:

policy:服务策略。取值“0”表示不发布服务,取值“1”表示向内核态发布服务,取值“2”表示向用户态发布服务。 moduleName:与驱动实现的 HdfDriverEntry 结构体中的 moduleName 相同。 deviceMatchAttr:驱动的私有配置信息。 serviceName:服务名称,最终会在/dev/节点下生成 serviceName 的节点(生成节点的前提条件是 policy 配置为大于等于 1)。

配置 sensor_config.hcs

文件路径:vendor/spacemit/smt001/hdf_config/khdf/sensor/sensor_config.hcs 配置说明:在 sensor_config.hcs 中添加如下内容: #include "accel/accel_qm8658_config.hcs"

配置 accel_qm8658_config.hcs 文件路径:vendor/spacemit/smt001/hdf_config/khdf/sensor/accel/accel_qm8658_config.hcs

配置说明: 新增文件夹 accel,并新建文件 accel_qm8658_config.hcs,文件内容如下:

#include"../sensor_common.hcs"
root{
    accel_qm8658_chip_config:sensorConfig{
        match_attr="hdf_sensor_accel_qm8658_driver";
        sensorInfo::sensorDeviceInfo{
            sensorName="accelerometer";
            vendorName="qmi8658";//maxstringlengthis16bytes
            sensorTypeId=1; //enum SensorTypeTag
            sensorId=1;//userdefinesensorid
            power=230;
        }
        sensorBusConfig::sensorBusInfo{
            busType=0; //0:i2c1:spi
            busNum=3;
            busAddr=0x6a;
            regWidth=1;//1btye
        }
        sensorIdAttr::sensorIdInfo{
            chipName="qm8658";
            chipIdRegister=0x00;
            chipIdValue=0x05;
        }
        sensorRegConfig{
            /*regAddr:registeraddress
            value:configregistervalue
            len:sizeofvalue
            mask:maskofvalue
            delay:configregisterdelaytime(ms)
            opsType:enumSensorOpsType0-none1-read2-write3-read_check4-update_bit
            calType:enumSensorBitCalType0-none1-set2-revert3-xor4-leftshift5-rightshift
            shiftNum:shiftbits
            debug:0-nodebug1-debug
            save:0-nosave1-save
            */
            /*regAddr,value,mask,len,delay,opsType,calType,shiftNum,debug,save*/
            initSeqConfig=[
                0x02,0x78, 0xff,1,5, 2,0,0,0,0,
                0x03,0x26, 0xff,1,5, 2,0,0,0,0,
                0x08,0x00,0x03,1,5, 2,0,0,0,0
            ];
            enableSeqConfig=[
                0x08,0x01,0x03,1,5, 2,0,0,0,0
            ];
            disableSeqConfig=[
                0x08,0x00,0x03,1,5, 2,0,0,0,0
            ];
        }
    }
}

编译选项修改

在 drivers/hdf_core/adapter/khdf/linux/model/sensor/Kconfig 中添加以下内容:

config DRIVERS_HDF_SENSOR_ACCEL_QM8658
    bool "Enable HDF accel qm8658 sensor driver"
    default n
    depends on DRIVERS_HDF_SENSOR_ACCEL
    help
        Answer Y to enable HDF accel qm8658 sensor driver.

在 drivers/hdf_core/adapter/khdf/linux/model/sensor/Makefile 中添加以下内容: obj-$(CONFIG_DRIVERS_HDF_SENSOR_ACCEL_QM8658)+=$(SENSOR_ROOT_DIR)/chipset/accel/accel_qm8658.o 修改 Makefile 对应的驱动实现文件如下:

drivers/peripheral/sensor/chipset/accel/accel_qm8658.c
drivers/peripheral/sensor/chipset/accel/accel_qm8658.h

内核 defconfig 配置

在 kernel/linux/spacemit_kernel-6.6/arch/riscv/configs/k1_defconfig 文件中添加以下内容:

CONFIG_DRIVERS_HDF_SENSOR=y
CONFIG_DRIVERS_HDF_SENSOR_ACCEL=y
CONFIG_DRIVERS_HDF_SENSOR_ACCEL_QM8658=y

应用代码目录说明

Sensor 驱动对外服务的接口实现均在 drivers/peripheral/sensor 路径下,该目录对应的功能说明如下:

/drivers/peripheral/sensor
├── hal
    └── include
    └── src
├── interfaces
    └── include
├── test
    └── unit
hal:sensor 模块 hal 层代码
include:sensor 模块 hal 层内部头文件
src:sensor 模块 hal 层代码的实现
interfaces:sensor 模块对上层服务提供的驱动能力接口
include:sensor 模块对外提供的接口定义
test:sensor 模块测试代码
unit:sensor 模块单元测试代码

常见问题处理

确认 HCS 配置的准确性,包括 I2C 总线、Sensor 寄存器初始化、Sensor 使能等信息。 确认是否修改了编译选项,使其正常编译进去。 若应用使能不上,确认模块是否要配置权限,以及是否要 touch hdf.hcs 更改时间戳。

TouchScreen 驱动开发

概述

TouchScreen 是较为常见的输入设备,用于感知用户对屏幕的触摸,从而实现相应的响应。 相较于原始的 Linux 驱动模式,OpenHarmony 在 HDF 层实现 TouchScreen 的驱动,这种实现方式能够实现一次开发,支持在不同的内核环境部署,比如轻量级系统、小系统或者标准 Linux 系统。此外, 在 HDF 框架中,对于不同的驱动能够实现统一管理,每一个驱动都对外能够提供服务,对应用层来说,只需调用 HDI 接口即可获取驱动服务的能力。

TouchScreen 驱动模型

OpenHarmony 中基于 HDF 驱动框架的 TouchScreen 驱动模型如下:

FIRMWARE

OpenHarmony 中的 TouchScreen 驱动模型分为以下层级: Hardware:此层决定了 TouchScreen 设备与 CPU 是如何连接的,外设通过哪些 IO 口进行配置,使用何种方式(比如 I2C、SPI、UART 等)进行通讯等等。 Kernel:该层主要是根据项目的需求,选择合适的内核(Linux/LiteOS/RTOS);其中 Kernel 层中的 OSAL APIs 主要是将不同内核的做归一化处理, 为 HDF Drivers 层提供标准化的操作接口,最大限度的屏蔽了不同内核之间的差异导致上层的修改。

HDF Drivers:该层实现硬件外设驱动,完成不同外设的初始化,比如 TouchScreen 需要实现 struct TouchChipOps ops 中的 Init、Detect、Resume、Suspend、 DataHandle、UpdateFirmware 函数。 Input HDI:该层实现了 TouchScreen 设备管理、业务控制、数据上报等驱动接口能力,为上层提供了硬件驱动能力。 Framework:上层 TouchScreen 服务。

HCS 配置

对于不同的平台,需要在对应的平台目录修改对应的 hcs 文件,下面示例为 smt001 平台下新增 GT9271 触摸屏的修改方法。

配置 device_info.hcs 文件路径:vendor/spacemit/smt001/hdf_config/khdf/device_info/device_info.hcs 配置说明:在 device_info.hcs 中添加以下内容。

主要字段说明:

policy:服务策略。取值“0”表示不发布服务,取值“1”表示向内核态发布服务,取值“2”表示向内核用户态发布服务。 moduleName:与驱动实现的 HdfDriverEntry 结构体中的 moduleName 相同。 deviceMatchAttr:驱动的私有配置信息。 serviceName:服务名称,最终会在/dev/节点下生成 serviceName 的节点(生成节点的前提条件是 policy 配置为大于等于 1)。

配置 input_config.hcs

文件路径:vendor/spacemit/smt001/hdf_config/khdf/input/input_config.hcs 配置说明:在 input_config.hcs 中修改如下配置。

修改配置 在 chipConfig 字段中新增 chip4,表示新增的一个触摸屏驱动。

编译选项修改

下面以新增触摸屏 GT9271 的驱动为例介绍相关的编译选项修改。

在 drivers/hdf_core/adapter/khdf/linux/model/input/Kconfig 中新增如下内容:

config DRIVERS_HDF_TP_10P10_GT9271
    bool "Enable HDF tp10P10 GT9271

UART 驱动开发

概述

UART 指通用异步收发传输器(Universal Asynchronous Receiver/Transmitter)。在 HDF 框架中,UART 的接口适配模式采用独立服务模式。 在这种模式下,每一个设备对象会独立发布一个设备服务来处理外部访问。设备管理器收到 API 的访问请求之后,通过提取该请求的参数,达到调用实际设备对象的相应内部方法的目的。 独立服务模式的优势在于可以直接借助 HDFDeviceManager 的服务管理能力,但也存在一定的不足,即需要为每个设备单独配置设备节点,这会增加内存占用。 UART 独立服务模式结构图如下图所示。

FIRMWARE

DTS 配置

配置说明

配置相应的串口设备节点,例如配置串口 2:

&uart2 {
    pinctrl-names = "default";
    pinctrl-0 = <&pinctrl_uart2>;
    status = "okay";
};

HCS 配置

对于不同的平台,需要在对应的平台目录修改对应的 hcs 文件。

配置 device_info.hcs

文件路径

vendor/spacemit/xxx/hdf_config/khdf/device_info/device_info.hcs

配置说明

在 device_info.hcs 中添加以下内容:

在配置过程中需要注意如下几点:

Policy:设置节点隐藏或显示。取值“1”表示隐藏,即在 dev 目录下不显示 HDF 节点;取值“2”表示显示,即在 dev 目录下显示 HDF 节点。 Permission:文件权限。 Priority:启动顺序,数值越大启动越晚。 serviceName 中“HDF_PLATFORM_UART_2”的后缀 “2”:对应应用 open 函数的 port 参数。

deviceMatchAttr:与 rk3568_uart_config.hcs 中的 match_attr 取值必须一致。

配置 rk3568_uart_config.hcs

文件路径

vendor/spacemit/xxx/hdf_config/khdf/platform/rk3568_uart_config.hcs

配置说明

在 rk3568_uart_config.hcs 修改如下:

在配置过程中需要注意如下几点:

device_uart_0x0002 中的后缀“0x0002”:为串口编号,从 0x0000 开始排序。 Num:与 driver_name 值“ttyS”组成驱动设备名,例如 ttyS9。

如果驱动设备名不以 ttyS 开头,例如 RK3568A 板的串口 A ~ D 的驱动设备名以 ttyXRUSB 开头,此时需要额外增加对 driver_name 的修改。例如:

device_uart_0x0002 :: uart_device {
    num = 9;
    driver_name = "ttyXRUSB"
    match_attr = "rockchip_rk3568_uart_9";
}

如果不增加对 driver_name 的修改,则默认使用 template 中的 driver_name 值,即“ttyS”。

应用使用流程

UART 的 API 接口使用,详见 OHOS 的 API 文档。

常用的 UART API 说明如下: uartOpen(port: number):其中,port 为“配置 device_info.hcs”章节中 serviceName 的后缀数字。 uartSetBaud:设置指定串口的波特率。 uartSetAttribute:设置指定串口的基本属性。

常见问题处理

确认 /dev/ 下面是否有 tty 的设备生成。如果没有生成,请参考“DTS 配置”章节检查配置。 确认 /dev/ 下面是否有 HDF_PLATFORM_UART_x 生成(x 为配置的 service_name)。如果没有生成,请参考“HCS 配置”章节检查配置。

数据读写不生效: 将 RX 和 TX 短接,通过两个 hdc 终端去测试,一个 cat tty 节点,一个 echo tty 节点。如果 cat 端收不到数据: 请确认“DTS 配置”章节中的 pinctrl - 0 选择了正确的串口 pin 脚。 检查并确保硬件电路正常。

发送正常,读数据丢失: 请检查是否有其他应用在抢数据。

检查是否存在硬件干扰。

在 GitHub 上编辑此页
上次更新:
贡献者: yhs
Prev
系统定制
Next
系统调试