鸿蒙OpenHarmony【HDF驱动开发流程】 子系统

HDF驱动开发流程

概述

HDF(Hardware Driver Foundation)驱动框架,为驱动开发者提供驱动框架能力,包括驱动加载、驱动服务管理、驱动消息机制和配置管理。并以组件化驱动模型作为核心设计思路,让驱动开发和部署更加规范,旨在构建统一的驱动架构平台,为驱动开发者提供更精准、更高效的驱动管理的开发环境,力求做到一次开发,多系统部署。

驱动加载

HDF驱动框架提供把和配置的设备列表匹配成功的驱动程序加载起来的功能。

驱动服务管理

HDF框架可以集中管理驱动服务,开发者可直接通过HDF框架对外提供的能力接口获取驱动相关的服务。

驱动消息机制

HDF框架提供统一的驱动消息机制,支持用户态应用向内核态驱动发送消息,也支持内核态驱动向用户态应用发送消息。

配置管理

HCS(HDF Configuration Source)是HDF驱动框架的配置描述源码,内容以Key-Value为主要形式。它实现了配置代码与驱动代码解耦,便于开发者进行配置管理。

驱动模型

HDF框架将一类设备驱动放在同一个Host(设备容器)里面,用于管理一组设备的启动加载等过程。在划分Host时,驱动程序是部署在一个Host还是部署在不同的Host,主要考虑驱动程序之间是否存在耦合性,如果两个驱动程序之间存在依赖,可以考虑将这部分驱动程序部署在一个Host里面,否则部署到独立的Host中是更好的选择。Device对应一个真实的物理设备。DeviceNode是设备的一个部件,Device至少有一个DeviceNode。每个DeviceNode可以发布一个设备服务。驱动即驱动程序,每个DevicdNode唯一对应一个驱动,实现和硬件的功能交互。HDF驱动模型如下图所示:

图1 HDF驱动模型

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

功能描述

驱动加载

HDF驱动框架提供把和配置的设备列表匹配成功的驱动程序加载起来的功能,支持按需加载和按序加载两种策略,具体设备的加载策略由配置文件中的preload字段来控制,配置值参考如下:

typedef enum {
    DEVICE_PRELOAD_ENABLE = 0,
    DEVICE_PRELOAD_ENABLE_STEP2 = 1,
    DEVICE_PRELOAD_DISABLE = 2,
    DEVICE_PRELOAD_INVALID
} DevicePreload;
c
按需加载
  • preload字段配置为0(DEVICE_PRELOAD_ENABLE),则系统启动过程中默认加载。
  • preload字段配置为1(DEVICE_PRELOAD_ENABLE_STEP2),当系统支持快速启动的时候,则在系统完成之后再加载这一类驱动,否则和DEVICE_PRELOAD_ENABLE含义相同。
  • preload字段配置为2(DEVICE_PRELOAD_DISABLE),则系统启动过程中默认不加载,支持后续动态加载,当用户态获取驱动服务[消息机制]时,如果驱动服务不存在,HDF框架会尝试动态加载该驱动。
按序加载(默认加载策略)

配置文件中的priority(取值范围为整数0到200)是用来表示host(驱动容器)和驱动的优先级的。不同的host内的驱动,host的priority值越小,驱动加载优先级越高;同一个host内驱动的priority值越小,加载优先级越高。

异常恢复(用户态驱动)

当驱动服务异常退出时,恢复策略如下:

  • preload字段配置为0(DEVICE_PRELOAD_ENABLE)或1(DEVICE_PRELOAD_ENABLE_STEP2)的驱动服务,由启动模块拉起host并重新加载服务。
  • preload字段配置为2(DEVICE_PRELOAD_DISABLE)的驱动服务,需业务模块注册HDF的服务状态监听器,当收到服务退出消息时,业务模块调用LoadDevice重新加载服务。

驱动服务管理

驱动服务是HDF驱动设备对外提供能力的对象,由HDF框架统一管理。驱动服务管理主要包含驱动服务的发布和获取。HDF框架定义了驱动对外发布服务的策略,由配置文件中的policy字段来控制,policy字段的取值范围以及含义如下:

typedef enum {
    /* 驱动不提供服务 */
    SERVICE_POLICY_NONE = 0,
    /* 驱动对内核态发布服务 */
    SERVICE_POLICY_PUBLIC = 1,
    /* 驱动对内核态和用户态都发布服务 */
    SERVICE_POLICY_CAPACITY = 2,
    /* 驱动服务不对外发布服务,但可以被订阅 */
    SERVICE_POLICY_FRIENDLY = 3,
    /* 驱动私有服务不对外发布服务,也不能被订阅 */
    SERVICE_POLICY_PRIVATE = 4,
    /* 错误的服务策略 */
    SERVICE_POLICY_INVALID
} ServicePolicy;
c
使用场景

当驱动需要以接口的形式对外提供能力时,可以使用HDF框架的驱动服务管理能力。

接口说明

针对驱动服务管理功能,HDF框架开放了以下接口供开发者调用,如下表所示:

表1 服务管理接口

方法 描述
int32_t (*Bind)(struct HdfDeviceObject *deviceObject) 需要驱动开发者实现Bind函数,将自己的服务接口绑定到HDF框架中。
const struct HdfObject *DevSvcManagerClntGetService(const char *svcName) 获取驱动的服务。
int HdfDeviceSubscribeService( struct HdfDeviceObject *deviceObject, const char *serviceName, struct SubscriberCallback callback) 订阅驱动的服务。

驱动消息机制管理

使用场景

当用户态应用和内核态驱动需要交互时,可以使用HDF框架的消息机制来实现。

接口说明

消息机制的功能主要有以下两种:

  • 用户态应用发送消息到驱动。
  • 用户态应用接收驱动主动上报事件。

表2 消息机制接口

方法 描述
struct HdfIoService *HdfIoServiceBind(const char *serviceName); 用户态获取驱动的服务,获取该服务之后通过服务中的Dispatch方法向驱动发送消息。
void HdfIoServiceRecycle(struct HdfIoService *service); 释放驱动服务。
int HdfDeviceRegisterEventListener(struct HdfIoService *target, struct HdfDevEventlistener *listener); 用户态程序注册接收驱动上报事件的操作方法。
int32_t HdfDeviceSendEvent(const struct HdfDeviceObject *deviceObject, uint32_t id, const struct HdfSBuf *data) 驱动主动上报事件接口。

配置管理

配置概述

HCS(HDF Configuration Source)是HDF驱动框架的配置描述源码,内容以Key-Value为主要形式。它实现了配置代码与驱动代码解耦,便于开发者进行配置管理。HC-GEN(HDF Configuration Generator)是HCS配置转换工具,可以将HDF配置文件转换为软件可读取的文件格式:

  • 在弱性能环境中,转换为配置树源码或配置树宏定义,驱动可直接调用C代码或宏式APIs获取配置。
  • 在高性能环境中,转换为HCB(HDF Configuration Binary)二进制文件,驱动可使用HDF框架提供的配置解析接口获取配置。

以下是使用HCB模式的典型应用场景:

图2 配置使用流程图

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

HCS经过HC-GEN编译生成HCB文件,HDF驱动框架中的HCS Parser模块会从HCB文件中重建配置树,HDF驱动模块使用HCS Parser提供的配置读取接口获取配置内容。

配置语法

HCS的语法介绍如下:

关键字

HCS配置语法保留了以下关键字。

表3 HCS配置语法保留关键字

关键字 用途 说明
root 配置根节点 -
include 引用其他HCS配置文件 -
delete 删除节点或属性 只能用于操作include导入的配置树
template 定义模板节点 -
match_attr 用于标记节点的匹配查找属性 解析配置时可以使用该属性的值查找到对应节点
基本结构

HCS主要分为属性(Attribute)和节点(Node)两种结构。

属性

属性即最小的配置单元,是一个独立的配置项。语法如下:

  attribute_name = value;
  • attribute_name是字母、数字、下划线的组合且必须以字母或下划线开头,字母区分大小写。

  • value的可用格式如下:

    • 数字常量,支持二进制、八进制、十进制、十六进制数,具体[数据类型]章节。
    • 字符串,内容使用双引号(“”)引用。
    • 节点引用。
  • attribute必须以分号(;)结束且必须属于一个node。

节点

节点是一组属性的集合,语法如下:

  node_name {
      module = "sample";
      ...
  }
  • node_name是字母、数字、下划线
<think>嗯,用户需要鸿蒙系统下LCD驱动开发的具体信息和学习资料。从用户补充的引用来看,核心信息集中在引用[1]关于Display驱动模型的三层结构和引用[3]的驱动移植指南。用户明显是开发者,需要实操性内容而非概念科普。 注意到引用[1]将驱动架构拆解得非常清晰:平台驱动层对接HAL,芯片适配层屏蔽硬件差异,LCD器件层负责具体控制。这应该是回答的主框架。引用[3]提到的"移植指南"和引用[2]的"器件驱动移植"关键词也值得纳入教程资源推荐。 用户上次要求"教程及相关资料",但引用里大多是企业宣传话术(如引用[4]的"核心知识要点"),需要过滤无效信息。真正的干货在: - 驱动模型技术细节(引用[1]) - 具体移植案例(引用[3]) - 器件层开发要点(引用[2]) 考虑设计三层递进结构:先讲清架构(对应平台驱动层),再说明跨平台适配方法(芯片适配层),最后落地到LCD器件驱动开发实操。这样既符合技术逻辑,也覆盖用户需求。 资源推荐要规避"限时领取"类营销链接(如引用[1]尾部),重点推官方文档和移植指南(引用[3])。用户可能是嵌入式开发鸿蒙,所以补充了Linux驱动经验衔接的建议——毕竟鸿蒙驱动框架确实类似Linux的platform device/driver模型。 最后加个学习路径建议,因为引用[4]的零散知识点列表对新手不友好。把HDF框架放在首位,毕竟所有引用都强调它是基础。 </think>以下是鸿蒙系统OpenHarmony)LCD驱动开发的完整指南,结合官方架构和开发实践整理而成: ### 一、LCD驱动开发核心架构 鸿蒙Display驱动采用**三级分层模型**(基于HDF驱动框架): ``` 1. 平台驱动层 (Platform Layer) │ ├── 对接Display公共HAL层 ├── 实现HDI硬件接口 └── 提供标准化API给图形服务$$ \text{API接口示例:} \texttt{DisplayGrallocInterface} $$ ``` ``` 2. 芯片平台适配层 (SoC Adaptation Layer) │ ├── 通过OSAL层接口屏蔽内核差异 ├── 实现芯片级初始化(如MIPI DSI配置) └── 提供时钟/电源管理$$ \text{关键配置:} \texttt{struct PanelData *panel} $$ ``` ``` 3. LCD器件驱动层 (Device Driver Layer) │ ├── 具体LCD模组驱动(如ILI9881C) ├── 实现时序控制(Porch/Sync信号) └── 背光/色彩配置$$ \text{时序公式:} t_{pw} > t_{pw\_min} + t_{skew} $$ ``` ### 二、开发流程详解 1. **硬件对接准备** - 获取LCD规格书(重点关注时序参数) - 确认接口类型:MIPI DSI/RGB/SPI - 引脚映射检查(如复位脚/背光使能脚) 2. **驱动移植关键步骤**: ```c /* 示例:在hdf驱动框架中注册面板 */ static struct PanelInfo g_ili9881c = { .width = 720, // 水平分辨率 .height = 1280, // 垂直分辨率 .hbp = 40, // Horizontal Back Porch .hpw = 10, // HSYNC pulse width .hfp = 40, // Horizontal Front Porch .frameRate = 60, // 刷新率 }; static int32_t HdfLcdEntry(struct HdfDeviceObject *obj) { if (RegisterPanel(&g_ili9881c) != HDF_SUCCESS) { // 注册面板参数 HDF_LOGE("Register panel failed!"); return HDF_FAILURE; } return HDF_SUCCESS; } ``` 3. **HDF配置树关键节点**(`device_info.hcs`): ```hcs display :: host { hostName = "display_host"; device_hdf_disp :: device { device0 :: deviceNode { policy = 0; // 内核模式驱动 priority = 100; moduleName = "LCD_DRV_ILI9881C"; // 驱动模块名 } } } ``` ### 三、学习资源推荐 1. **官方文档** - [OpenHarmony显示子系统](https://gitee.com/openharmony/docs/blob/master/zh-cn/device-dev/subsystems/subsys-display.md) - HDF驱动开发指南:[HDF框架详解](https://gitee.com/openharmony/drivers_peripheral) 2. **实战教程** - LCD时序调试:[鸿蒙MIPI-DSI信号分析](https://ost.51cto.com/posts/13943) - 移植案例:[RK3566适配ILI9488驱动](https://harmonyos.51cto.com/posts/7892) 3. **开发工具链** - 调试工具:HDF_TRACE 日志系统 - 烧录工具:HiTool(海思平台) - 信号测量:示波器校验HSYNC/VSYNC时序 ### 四、常见问题解决 | 问题现象 | 排查方向 | |-------------------------|------------------------------| | 屏幕无显示 | 1. 检查复位信号时序<br>2. 确认背光电路使能 | | 显示花屏/错位 | 1. 校验Porch参数<br>2. 内存对齐设置 | | 刷新率不足 | 1. DSI时钟频率配置<br>2. FIFO深度调整 | > **经验提示**:鸿蒙驱动开发需重点掌握 **HDF的设备树解析机制** 和 **OSAL层操作接口**,这两者是屏蔽不同芯片平台差异的关键[^1][^3]。 --- ###
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值