【鸿蒙南向开发】OpenHarmony驱动框架解读和开发实践

前言

在 IoT 时代下，终端设备差异较大、形态各异、尺寸各异、交互方式各异，解决设备适配问题无疑是实现万物互联的一个关键。但是，在驱动框架的开发和部署过程中，由于终端设备对硬件的计算和存储能力的需求不同、设备厂商提供的设备软硬件操作接口不同、内核提供的操作接口不同，这就使得 OEM 厂商部署系统的时候需要投入大量的精力来适配和维护驱动代码。能否提供了一个跨芯片平台、跨内核的驱动框架，使得设备驱动软件可以在不同的设备上运行？OpenHarmony 作为一个自主研发、全新技术生态的全领域下一代开源操作系统，提供了一套驱动框架来满足此诉求。下面我们将带着大家解读 OpenHarmony 驱动框架。

一、OpenHarmony驱动框架解读

1. 设计目标为解决在开发和部署过程中遇到的困难，OpenHarmony 驱动框架设计目标如下：

• 支持百 K 级~G 级容量的设备部署，如手机、手环等

• 提供统一硬件 IO 抽象，屏蔽 SoC 芯片差异，兼容不同内核，如 Linux、LiteOS 等。

• 屏蔽驱动和系统组件间交互。可动态拆解，满足不同容量设备的部署。

• 面向不同容量的设备，提供统一的配置界面。

2. 设计思路

OpenHarmony 驱动框架（下面简称为 HDF）通过提供驱动与芯片平台、内核解耦的底座，规范硬件驱动接口，实现驱动软件在不同设备中部署。

HDF 驱动框架架构如下图所示。

为了达成设计目标，OpenHarmony 驱动框架采用如下核心设计思路：

（1）弹性化架构

• **框架可动态伸缩：**通过对象管理器，多态加载不同容量设备实现方式，实现弹性伸缩部署。
• **驱动可动态伸缩：**支持统一的设备驱动插件管理，实现设备驱动任意分层，积木式组合拼接

（2）组件化设备模型

• 提供设备功能模型抽象，屏蔽设备驱动与系统交互的实现，为开发者提供统一的驱动开发接口
• 提供主流 IC 的公版驱动能力，支持配置化部署

（3）归一化平台底座

提供规范化的内核、SoC 硬件 IO 适配接口，兼容不同内核、SoC 芯片，对外开发规范化的平台驱动接口

（4）统一配置界面

构建全新的配置语言，面向不同容量的设备，提供统一配置界面，支持硬件资源配置和设备信息配置

3. 构建策略

面向 Liteos 的轻量级设备，主要基于 HDF 构建主流 IC 驱动，形成公版驱动和通用设备功能模型，支撑不同硬件芯片、不同内核(LiteOS-M/LiteOS-A)部署。

面向标准设备，除了支持内核态驱动，还支持用户态驱动。用户态驱动的重点在于构建设备抽象模型，为系统提供统一的设备接口，兼容 Linux 原生驱动和 HDF 驱动。内核态则使用 Linux 驱动与 HDF 驱动并存的策略，提供端到端的解决方案。[图片上传失败…(image-a3f9f-1722404881371)]

4. 现状与演进

目前 HDF 驱动框架已经支持 Liteos-m、Liteos-a、Linux 内核，以及 OpenHarmony 轻量级、标准级上部署，并且在标准系统上同时支持内核态与用户态部署。

经过开发者的不断努力，OpenHarmony 驱动框架正在不断完善和增强，在 OpenHarmony LTS3.0 中，基础框架新增了对热插拔设备的管理以及 HDI 编译工具 hdi-gen，驱动模型部分新增了 Audio、Camera、Senso、USB DDK 等多个模块的支持。

二、OpenHarmony驱动开发

OpenHarmony 驱动为了避免与具体内核产生依赖，实现可迁移目标，开发时需要遵循以下约定：

• 系统相关接口使用 HDF OSAL 接口；
• 总线和硬件资源相关接口使用平台驱动提供的相关接口。

基于 HDF 框架，驱动开发的通常流程包含驱动代码的实现、编译脚本、配置文件添加、以及用户态程序和驱动交互的流程。下面将详细介绍 HDF 驱动开发一般步骤。

1. 实现驱动代码

在 HDF 驱动框架中，HdfDriverEntry 对象被用来描述一个驱动实现。

struct HdfDriverEntry {
    int32_t moduleVersion;
    const char *moduleName;
    int32_t (*Bind)(struct HdfDeviceObject *deviceObject);
    int32_t (*Init)(struct HdfDeviceObject *deviceObject);
    void (*Release)(struct HdfDevic