Loading [MathJax]/jax/output/CommonHTML/config.js
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >OpenHarmony(鸿蒙南向开发)——小型系统芯片移植指南(三)驱动移植

OpenHarmony(鸿蒙南向开发)——小型系统芯片移植指南(三)驱动移植

原创
作者头像
小帅聊鸿蒙
发布于 2025-06-24 08:50:50
发布于 2025-06-24 08:50:50
10800
代码可运行
举报
文章被收录于专栏:鸿蒙开发笔记鸿蒙开发笔记
运行总次数:0
代码可运行

移植概述

驱动主要包含两部分,平台驱动和器件驱动。平台驱动主要包括通常在SOC内的GPIO、I2C、SPI等;器件驱动则主要包含通常在SOC外的器件,如 LCD、TP、WLAN等

图1 OpenHarmony 驱动分类

HDF驱动被设计为可以跨OS使用的驱动程序,HDF驱动框架会为驱动达成这个目标提供有力的支撑。开发HDF驱动中,请尽可能只使用HDF驱动框架提供的接口,否则会导致驱动丧失跨OS使用的特性。在开始驱动开发前,建议先了解HDF驱动框架。

平台驱动移植

在这一步,我们会在源码目录//device/vendor_name/soc_name/drivers目录下创建平台驱动,如果你要移植的SOC的厂商还没有创建仓库的话,请联系 sig_devboard 创建。

建议的目录结构:

代码语言:shell
AI代码解释
复制
device
├── vendor_name
│   ├── drivers
│   │   │   ├── common
│   │   │   ├── Kconfig # 厂商驱动内核菜单入口
│   │   │   └── lite.mk # 构建的入口
│   ├── soc_name
│   │   ├── drivers
│   │   │   ├── dmac
│   │   │   ├── gpio
│   │   │   ├── i2c
│   │   │   ├── LICENSE
│   │   │   ├── mipi_dsi
│   │   │   ├── mmc
│   │   │   ├── pwm
│   │   │   ├── README.md # docs 如果需要的话
│   │   │   ├── README_zh.md
│   │   │   ├── rtc
│   │   │   ├── spi
│   │   │   ├── uart
│   │   │   └── watchdog
│   ├── board_name

HDF为所有的平台驱动都创建了驱动模型,移植平台驱动的主要工作是向模型注入实例。 这些模型你可以在源码目录//drivers/hdf_core/framework/support/platform/include中找到定义。

本节我们会以GPIO为例,讲解如何移植平台驱动,移植过程包含以下步骤:

  1. 创建GPIO驱动

在源码目录//device/vendor_name/soc_name/drivers/gpio中创建文件soc_name_gpio.c。内容模板如下:

代码语言:c
代码运行次数:0
运行
AI代码解释
复制
    #include "gpio_core.h"

    // 定义GPIO结构体,如果需要的话
    struct SocNameGpioCntlr {
        struct GpioCntlr cntlr;  // 这是HDF GPIO驱动框架需要的结构体
        int myData; // 以下是当前驱动自身需要的
    };

    // Bind 方法在HDF驱动中主要用户对外发布服务,这里我们不需要,直接返回成功即可
    static int32_t GpioBind(struct HdfDeviceObject *device)
    {
        (void)device;
        return HDF_SUCCESS;
    }

    // Init方法时驱动初始化的入口,我们需要在Init方法中完成模型实例的注册
    static int32_t GpioInit(struct HdfDeviceObject *device)
    {
        SocNameGpioCntlr *impl = CreateGpio(); // 你的创建代码
        ret = GpioCntlrAdd(&impl->cntlr);  // 注册GPIO模型实例
        if (ret != HDF_SUCCESS) {
            HDF_LOGE("%s: err add controller:%d", __func__, ret);
            return ret;
        }
        return HDF_SUCCESS;
    }

    // Release方法会在驱动卸载时被调用,这里主要完成资源回收
    static void GpioRelease(struct HdfDeviceObject *device)
    {
        // GpioCntlrFromDevice 方法能从抽象的设备对象中获得init方法注册进去的模型实例。
        struct GpioCntlr *cntlr = GpioCntlrFromDevice(device);
        //资源释放...
    }

    struct HdfDriverEntry g_gpioDriverEntry = {
        .moduleVersion = 1,
        .Bind = GpioBind,
        .Init = GpioInit,
        .Release = GpioRelease,
        .moduleName = "SOC_NAME_gpio_driver", // 这个名字我们稍后会在配置文件中用到,用来加载驱动。
    };
    HDF_INIT(g_gpioDriverEntry); // 注册一个GPIO的驱动入口
  1. 创建厂商驱动构建入口

如前所述device/vendor_name/drivers/lite.mk是厂商驱动的构建的入口。我们需要从这个入口开始,进行构建。

代码语言:c
代码运行次数:0
运行
AI代码解释
复制
    #文件device/vendor_name/drivers/lite.mk

    SOC_VENDOR_NAME := $(subst $/",,$(LOSCFG_DEVICE_COMPANY))
    SOC_NAME := $(subst $/",,$(LOSCFG_PLATFORM))
    BOARD_NAME := $(subst $/",,$(LOSCFG_PRODUCT_NAME))

    # 指定SOC进行构建
    LIB_SUBDIRS += $(LITEOSTOPDIR)/../../device/$(SOC_VENDOR_NAME)/$(SOC_NAME)/drivers/
  1. 创建SOC驱动构建入口
代码语言:c
代码运行次数:0
运行
AI代码解释
复制
    #文件device/vendor_name/soc_name/drivers/lite.mk

    SOC_DRIVER_ROOT := $(LITEOSTOPDIR)/../../device/$(SOC_VENDOR_NAME)/$(SOC_NAME)/drivers/

    # 判断如果打开了GPIO的内核编译开关
    ifeq ($(LOSCFG_DRIVERS_HDF_PLATFORM_GPIO), y)
        # 构建完成要链接一个叫hdf_gpio的对象
        LITEOS_BASELIB += -lhdf_gpio
        # 增加构建目录gpio
        LIB_SUBDIRS    += $(SOC_DRIVER_ROOT)/gpio 
    endif

    # 后续其他驱动在此基础上追加
  1. 创建GPIO构建入口
代码语言:c
代码运行次数:0
运行
AI代码解释
复制
    include $(LITEOSTOPDIR)/config.mk
    include $(LITEOSTOPDIR)/../../drivers/adapter/khdf/liteos/lite.mk

    # 指定输出对象的名称,注意要与SOC驱动构建入口里的LITEOS_BASELIB 保持一致
    MODULE_NAME := hdf_gpio

    # 增加HDF框架的INCLUDE
    LOCAL_CFLAGS += $(HDF_INCLUDE)

    # 要编译的文件
    LOCAL_SRCS += soc_name_gpio.c

    # 编译参数
    LOCAL_CFLAGS += -fstack-protector-strong -Wextra -Wall -Werror -fsigned-char -fno-strict-aliasing -fno-common

    include $(HDF_DRIVER)
DD一下:欢迎大家关注工粽号<程序猿百晓生>,可以了解到以下知识点。
代码语言:erlang
AI代码解释
复制
欢迎大家关注工粽号<程序猿百晓生>0取以下学习清单:
1.OpenHarmony开发基础
2.OpenHarmony北向开发环境搭建
3.鸿蒙南向开发环境的搭建
4.鸿蒙生态应用开发白皮书V2.0 & V3.0
5.鸿蒙开发面试真题(含参考答案) 
6.TypeScript入门学习手册
7.OpenHarmony 经典面试题(含参考答案)
8.OpenHarmony设备开发入门【最新版】
9.沉浸式剖析OpenHarmony源代码
10.系统定制指南
11.OpenHarmonyUboot 驱动加载流程
12.OpenHarmony构建系统--GN与子系统、部件、模块详解
13.ohos开机init启动流程
14.鸿蒙版性能优化指南
.......
  1. 配置产品加载驱动

产品的所有设备信息被定义在源码文件//vendor/vendor_name/product_name/config/device_info/device_info.hcs中。

平台驱动请添加到platform的host中。

 说明: moduleName要与驱动定义中的相同。

代码语言:shell
AI代码解释
复制
    root {
        ...
        platform :: host {
            device_gpio :: device {
                    device0 :: deviceNode {
                        policy = 0;
                        priority = 10;
                        permission = 0644;
                        moduleName = "SOC_NAME_gpio_driver"; 
                    }
            }
        }
    }

平台驱动移植

在这一步,我们会在源码目录//device/vendor_name/soc_name/drivers目录下创建平台驱动,如果你要移植的SOC的厂商还没有创建仓库的话,请联系 sig_devboard 创建。

建议的目录结构:

代码语言:shell
AI代码解释
复制
device
├── vendor_name
│   ├── drivers
│   │   │   ├── common
│   │   │   ├── Kconfig # 厂商驱动内核菜单入口
│   │   │   └── lite.mk # 构建的入口
│   ├── soc_name
│   │   ├── drivers
│   │   │   ├── dmac
│   │   │   ├── gpio
│   │   │   ├── i2c
│   │   │   ├── LICENSE
│   │   │   ├── mipi_dsi
│   │   │   ├── mmc
│   │   │   ├── pwm
│   │   │   ├── README.md # docs 如果需要的话
│   │   │   ├── README_zh.md
│   │   │   ├── rtc
│   │   │   ├── spi
│   │   │   ├── uart
│   │   │   └── watchdog
│   ├── board_name

HDF为所有的平台驱动都创建了驱动模型,移植平台驱动的主要工作是向模型注入实例。 这些模型你可以在源码目录//drivers/hdf_core/framework/support/platform/include中找到定义。

本节我们会以GPIO为例,讲解如何移植平台驱动,移植过程包含以下步骤:

  1. 创建GPIO驱动

在源码目录//device/vendor_name/soc_name/drivers/gpio中创建文件soc_name_gpio.c。内容模板如下:

代码语言:c
代码运行次数:0
运行
AI代码解释
复制
    #include "gpio_core.h"

    // 定义GPIO结构体,如果需要的话
    struct SocNameGpioCntlr {
        struct GpioCntlr cntlr;  // 这是HDF GPIO驱动框架需要的结构体
        int myData; // 以下是当前驱动自身需要的
    };

    // Bind 方法在HDF驱动中主要用户对外发布服务,这里我们不需要,直接返回成功即可
    static int32_t GpioBind(struct HdfDeviceObject *device)
    {
        (void)device;
        return HDF_SUCCESS;
    }

    // Init方法时驱动初始化的入口,我们需要在Init方法中完成模型实例的注册
    static int32_t GpioInit(struct HdfDeviceObject *device)
    {
        SocNameGpioCntlr *impl = CreateGpio(); // 你的创建代码
        ret = GpioCntlrAdd(&impl->cntlr);  // 注册GPIO模型实例
        if (ret != HDF_SUCCESS) {
            HDF_LOGE("%s: err add controller:%d", __func__, ret);
            return ret;
        }
        return HDF_SUCCESS;
    }

    // Release方法会在驱动卸载时被调用,这里主要完成资源回收
    static void GpioRelease(struct HdfDeviceObject *device)
    {
        // GpioCntlrFromDevice 方法能从抽象的设备对象中获得init方法注册进去的模型实例。
        struct GpioCntlr *cntlr = GpioCntlrFromDevice(device);
        //资源释放...
    }

    struct HdfDriverEntry g_gpioDriverEntry = {
        .moduleVersion = 1,
        .Bind = GpioBind,
        .Init = GpioInit,
        .Release = GpioRelease,
        .moduleName = "SOC_NAME_gpio_driver", // 这个名字我们稍后会在配置文件中用到,用来加载驱动。
    };
    HDF_INIT(g_gpioDriverEntry); // 注册一个GPIO的驱动入口
  1. 创建厂商驱动构建入口

如前所述device/vendor_name/drivers/lite.mk是厂商驱动的构建的入口。我们需要从这个入口开始,进行构建。

代码语言:c
代码运行次数:0
运行
AI代码解释
复制
    #文件device/vendor_name/drivers/lite.mk

    SOC_VENDOR_NAME := $(subst $/",,$(LOSCFG_DEVICE_COMPANY))
    SOC_NAME := $(subst $/",,$(LOSCFG_PLATFORM))
    BOARD_NAME := $(subst $/",,$(LOSCFG_PRODUCT_NAME))

    # 指定SOC进行构建
    LIB_SUBDIRS += $(LITEOSTOPDIR)/../../device/$(SOC_VENDOR_NAME)/$(SOC_NAME)/drivers/
  1. 创建SOC驱动构建入口
代码语言:c
代码运行次数:0
运行
AI代码解释
复制
    #文件device/vendor_name/soc_name/drivers/lite.mk

    SOC_DRIVER_ROOT := $(LITEOSTOPDIR)/../../device/$(SOC_VENDOR_NAME)/$(SOC_NAME)/drivers/

    # 判断如果打开了GPIO的内核编译开关
    ifeq ($(LOSCFG_DRIVERS_HDF_PLATFORM_GPIO), y)
        # 构建完成要链接一个叫hdf_gpio的对象
        LITEOS_BASELIB += -lhdf_gpio
        # 增加构建目录gpio
        LIB_SUBDIRS    += $(SOC_DRIVER_ROOT)/gpio 
    endif

    # 后续其他驱动在此基础上追加
  1. 创建GPIO构建入口
代码语言:c
代码运行次数:0
运行
AI代码解释
复制
    include $(LITEOSTOPDIR)/config.mk
    include $(LITEOSTOPDIR)/../../drivers/adapter/khdf/liteos/lite.mk

    # 指定输出对象的名称,注意要与SOC驱动构建入口里的LITEOS_BASELIB 保持一致
    MODULE_NAME := hdf_gpio

    # 增加HDF框架的INCLUDE
    LOCAL_CFLAGS += $(HDF_INCLUDE)

    # 要编译的文件
    LOCAL_SRCS += soc_name_gpio.c

    # 编译参数
    LOCAL_CFLAGS += -fstack-protector-strong -Wextra -Wall -Werror -fsigned-char -fno-strict-aliasing -fno-common

    include $(HDF_DRIVER)
DD一下:欢迎大家关注工粽号<程序猿百晓生>,可以了解到以下知识点。
代码语言:erlang
AI代码解释
复制
欢迎大家关注工粽号<程序猿百晓生>0取以下学习清单:
1.OpenHarmony开发基础
2.OpenHarmony北向开发环境搭建
3.鸿蒙南向开发环境的搭建
4.鸿蒙生态应用开发白皮书V2.0 & V3.0
5.鸿蒙开发面试真题(含参考答案) 
6.TypeScript入门学习手册
7.OpenHarmony 经典面试题(含参考答案)
8.OpenHarmony设备开发入门【最新版】
9.沉浸式剖析OpenHarmony源代码
10.系统定制指南
11.OpenHarmonyUboot 驱动加载流程
12.OpenHarmony构建系统--GN与子系统、部件、模块详解
13.ohos开机init启动流程
14.鸿蒙版性能优化指南
.......
  1. 配置产品加载驱动

产品的所有设备信息被定义在源码文件//vendor/vendor_name/product_name/config/device_info/device_info.hcs中。

平台驱动请添加到platform的host中。

 说明: moduleName要与驱动定义中的相同。

代码语言:shell
AI代码解释
复制
    root {
        ...
        platform :: host {
            device_gpio :: device {
                    device0 :: deviceNode {
                        policy = 0;
                        priority = 10;
                        permission = 0644;
                        moduleName = "SOC_NAME_gpio_driver"; 
                    }
            }
        }
    }

器件驱动移植

LCD驱动移植

移植LCD驱动的主要工作是编写一个驱动,在驱动中生成模型的实例,并完成注册。

这些LCD的驱动被放置在源码目录//drivers/hdf_core/framework/model/display/driver/panel中。

  1. 创建Panel驱动

创建HDF驱动,在驱动初始化中调用RegisterPanel接口注册模型实例。如:

代码语言:c
代码运行次数:0
运行
AI代码解释
复制
    int32_t LCDxxEntryInit(struct HdfDeviceObject *object)
    {
        struct PanelData *panel = CreateYourPanel();
        // 注册模型实例
        if (RegisterPanel(panel) != HDF_SUCCESS) {
            HDF_LOGE("%s: RegisterPanel failed", __func__);
            return HDF_FAILURE;
        }
        return HDF_SUCCESS;
    }

    struct HdfDriverEntry g_xxxxDevEntry = {
        .moduleVersion = 1,
        .moduleName = "LCD_XXXX",
        .Init = LCDxxEntryInit,
    };

    HDF_INIT(g_xxxxDevEntry);
  1. 配置加载panel驱动

产品的所有设备信息被定义在源码文件//vendor/vendor_name/product_name/config/device_info/device_info.hcs中。修改该文件,在display的host中,名为device_lcd的device中增加配置。

 注意: moduleName 要与panel驱动中的moduleName相同。

代码语言:shell
AI代码解释
复制
    root {
        ...
        display :: host {
            device_lcd :: device {
                    deviceN :: deviceNode {
                        policy = 0;
                        priority = 100;
                        preload = 2;
                        moduleName = "LCD_XXXX";
                    }
            }
        }
    }

TP驱动移植

本节描述如何移植触摸屏驱动。触摸屏的器件驱动被放置在源码目录//drivers/hdf_core/framework/model/input/driver/touchscreen中。 移植触摸屏驱动主要工作是向系统注册ChipDevice模型实例。

详细的驱动开发指导,请参考 TOUCHSCREEN开发指导。

  1. 创建触摸屏器件驱动

在上述touchscreen目录中创建名为touch_ic_name.c的文件。编写如下内容

代码语言:c
代码运行次数:0
运行
AI代码解释
复制
    #include "hdf_touch.h"

    static int32_t HdfXXXXChipInit(struct HdfDeviceObject *device)
    {
        ChipDevice *tpImpl = CreateXXXXTpImpl();
        if(RegisterChipDevice(tpImpl) != HDF_SUCCESS) { // 注册ChipDevice模型
            ReleaseXXXXTpImpl(tpImpl);
            return HDF_FAILURE;
        }
        return HDF_SUCCESS;
    }

    struct HdfDriverEntry g_touchXXXXChipEntry = {
        .moduleVersion = 1,
        .moduleName = "HDF_TOUCH_XXXX", // 注意这里的moduleName要与后续的配置完全一致
        .Init = HdfXXXXChipInit,
    };

    HDF_INIT(g_touchXXXXChipEntry);

其中ChipDevice中要实现如下方法:

方法

实现说明

int32_t (Init)(ChipDevice device)

实现器件初始化

int32_t (Detect)(ChipDevice device)

实现器件探测

int32_t (Suspend)(ChipDevice device)

实现器件休眠

int32_t (Resume)(ChipDevice device)

实现器件唤醒

int32_t (DataHandle)(ChipDevice device)

需要实现从器件读取数据,将触摸点数据填写入device->driver->frameData中

int32_t (UpdateFirmware)(ChipDevice device)

实现固件升级

  1. 配置产品,加载器件驱动

产品的所有设备信息被定义在源码文件//vendor/vendor_name/product_name/config/device_info/device_info.hcs中。修改该文件,在名为input的host中,名为device_touch_chip的device中增加配置。

 说明: moduleName 要与触摸屏驱动中的moduleName相同。

代码语言:c
代码运行次数:0
运行
AI代码解释
复制
    deviceN :: deviceNode {
        policy = 0;
        priority = 130;
        preload = 0;
        permission = 0660;
        moduleName = "HDF_TOUCH_XXXX";
        deviceMatchAttr = "touch_XXXX_configs";
    }

WLAN驱动移植

WLAN驱动分为两部分,一部分负责管理WLAN设备,另一个部分负责处理WLAN流量。

图1 OpenHarmony WLAN结构示意图

如图1,左半部分负责管理WLAN设备,右半部分负责WLAN流量。HDF WLAN分别为这两部分做了抽象,驱动的移植过程可以看做分别实现这两部分所需接口。这些接口有:

接口

定义头文件

接口说明

HdfChipDriverFactory

drivers\hdf_core\framework\include\wifi\hdf_wlan_chipdriver_manager.h

ChipDriver的Factory,用于支持一个芯片多个WLAN端口

HdfChipDriver

drivers\hdf_core\framework\include\wifi\wifi_module.h

每个WLAN端口对应一个HdfChipDriver,用来管理一个特定端口

NetDeviceInterFace

drivers\hdf_core\framework\include\wifi\net_device.h

与协议栈之间的接口,如发送数据、设置网络接口状态等

 说明: 详细的接口开发指导,请参考WLAN开发。

具体的移植步骤如下:

  1. 创建HDF WLAN芯片驱动

在目录/device/vendor_name/peripheral/wifi/chip_name/创建文件hdf_wlan_chip_name.c。内容模板如下:

代码语言:c
代码运行次数:0
运行
AI代码解释
复制
    static int32_t HdfWlanXXXChipDriverInit(struct HdfDeviceObject *device) {
        static struct HdfChipDriverFactory factory = CreateChipDriverFactory(); // 需要移植者实现的方法
        struct HdfChipDriverManager *driverMgr = HdfWlanGetChipDriverMgr();
        if (driverMgr->RegChipDriver(&factory) != HDF_SUCCESS) { // 注册驱动工厂
            HDF_LOGE("%s fail: driverMgr is NULL!", __func__);
            return HDF_FAILURE;
        }
        return HDF_SUCCESS;
    }

    struct HdfDriverEntry g_hdfXXXChipEntry = {
        .moduleVersion = 1,
        .Init = HdfWlanXXXChipDriverInit,
        .Release = HdfWlanXXXChipRelease,
        .moduleName = "HDF_WIFI_CHIP_XXX" // 注意:这个名字要与配置一致
    };

    HDF_INIT(g_hdfXXXChipEntry);

在上述代码的CreateChipDriverFactory方法中,需要创建一个HdfChipDriverFactory类型的对象。该对象提供如下方法:

接口

说明

const char *driverName

当前driverName

int32_t (InitChip)(struct HdfWlanDevice device)

初始化芯片

int32_t (DeinitChip)(struct HdfWlanDevice device)

去初始化芯片

void (ReleaseFactory)(struct HdfChipDriverFactory factory)

释放HdfChipDriverFactory对象

struct HdfChipDriver (Build)(struct HdfWlanDevice *device, uint8_t ifIndex)

创建一个HdfChipDriver;输入参数中,device是设备信息,ifIndex是当前创建的接口在这个芯片中的序号

void (Release)(struct HdfChipDriver chipDriver)

释放chipDriver

uint8_t (GetMaxIFCount)(struct HdfChipDriverFactory factory)

获取当前芯片支持的最大接口数

其中Build方法负责创建一个管理指定网络接口的对象HdfChipDriver。该对象需要提供方法:

接口

说明

int32_t (init)(struct HdfChipDriver chipDriver, NetDevice *netDev)

初始化当前网络接口,这里需要向netDev提供接口NetDeviceInterFace

int32_t (deinit)(struct HdfChipDriver chipDriver, NetDevice *netDev)

去初始化当前网络接口

struct HdfMac80211BaseOps *ops

WLAN基础能力接口集

struct HdfMac80211STAOps *staOps

支持STA模式所需的接口集

struct HdfMac80211APOps *apOps

支持AP模式所需要的接口集

DD一下:欢迎大家关注工粽号<程序猿百晓生>,可以了解到以下知识点。
代码语言:erlang
AI代码解释
复制
欢迎大家关注工粽号<程序猿百晓生>0取以下学习清单:
1.OpenHarmony开发基础
2.OpenHarmony北向开发环境搭建
3.鸿蒙南向开发环境的搭建
4.鸿蒙生态应用开发白皮书V2.0 & V3.0
5.鸿蒙开发面试真题(含参考答案) 
6.TypeScript入门学习手册
7.OpenHarmony 经典面试题(含参考答案)
8.OpenHarmony设备开发入门【最新版】
9.沉浸式剖析OpenHarmony源代码
10.系统定制指南
11.OpenHarmonyUboot 驱动加载流程
12.OpenHarmony构建系统--GN与子系统、部件、模块详解
13.ohos开机init启动流程
14.鸿蒙版性能优化指南
.......
  1. 编写配置文件描述驱动支持的芯片

在产品配置目录下创建芯片的配置文件,保存至源码路径//vendor/vendor_name/product_name/config/wifi/wlan_chip_chip_name.hcs

该文件模板如下:

代码语言:shell
AI代码解释
复制
    root {
        wlan_config {
            chip_name :& chipList {
                chip_name :: chipInst {
                    match_attr = "hdf_wlan_chips_chip_name"; /* 这是配置匹配属性,用于提供驱动的配置根 */
                    driverName = "driverName"; /* 需要与HdfChipDriverFactory中的driverName相同*/
                    sdio {
                        vendorId = 0xXXXX; /* your vendor id */
                        deviceId = [0xXXXX]; /*your supported devices */
                    }
                }
            }
        }
    }

 说明:路径和文件中的vendor_name、product_name、chip_name请替换成实际名称。vendorId 和 deviceId需要根据实际芯片的识别码进行填写。

  1. 编写配置文件,加载驱动

产品的所有设备信息被定义在源码文件//vendor/vendor_name/product_name/config/device_info/device_info.hcs中。修改该文件,在名为network的host中,名为device_wlan_chips的device中增加配置。模板如下:

代码语言:c
代码运行次数:0
运行
AI代码解释
复制
    deviceN :: deviceNode {
        policy = 0;
        preload = 2;
        moduleName = "HDF_WLAN_CHIPS";
        deviceMatchAttr = "hdf_wlan_chips_chip_name";
        serviceName = "driverName";
    }

 说明: moduleName 要与HDF WLAN 芯片驱动中的moduleName相同。

  1. 修改Kconfig文件,让移植的WLAN模组出现再内核配置中

device/vendor_name/drivers/Kconfig中增加配置菜单,模板如下

代码语言:c
代码运行次数:0
运行
AI代码解释
复制
    config DRIVERS_HDF_WIFI_chip_name
        bool "Enable chip_name Host driver"
        default n
        depends on DRIVERS_HDF_WLAN   help
          Answer Y to enable chip_name Host driver.

 说明: 请替换模板中的chip_name为实际的芯片名称。

  1. 修改构建脚本,让驱动参与内核构建

在源码文件//device/vendor_name/drivers/lite.mk末尾追加如下内容。

代码语言:c
代码运行次数:0
运行
AI代码解释
复制
    ifeq ($(LOSCFG_DRIVERS_HDF_WIFI_chip_name), y)
        # 构建完成要链接一个叫hdf_wlan_chipdriver_chip_name的对象,建议按这个命名,防止冲突
        LITEOS_BASELIB += -lhdf_wlan_chipdriver_chip_name
        # 增加构建目录gpio
        LIB_SUBDIRS    += ../peripheral/wifi/chip_name
    endif

 说明: 请替换模板中的chip_name为实际的芯片名称。

写在最后

如果你觉得这篇内容对你还蛮有帮助,我想邀请你帮我三个小忙:

  • 点赞,转发,有你们的 『点赞和评论』,才是我创造的动力;
  • 关注小编,同时可以期待后续文章ing🚀,不定期分享原创知识;
  • 想要获取更多完整鸿蒙最新学习知识点,可关注B站:码牛课堂;

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
OpenHarmony(鸿蒙南向开发)——小型系统STM32MP1芯片移植案例
本文章基于意法半导体STM32MP157芯片的小熊派BearPi-HM Micro开发板,进行小型带屏开发板的移植,实现了ace_engine_lite、arkui_ui_lite、aafwk_lite、appexecfwk_lite、HDF等部件基于OpenHarmony LiteOS-A内核的适配。移植架构上采用Board与SoC分离的方案。
小帅聊鸿蒙
2025/06/27
1030
OpenHarmony(鸿蒙南向开发)——小型系统STM32MP1芯片移植案例
OpenHarmony(鸿蒙南向开发)——轻量系统芯片移植指南(二)
安全子系统提供网络设备连接、认证鉴权等功能,依赖mbedtls实现硬件随机数以及联网功能。
小帅聊鸿蒙
2025/06/22
790
OpenHarmony(鸿蒙南向开发)——小型系统芯片移植指南(一)
本文详细介绍如何将OpenHarmony小型系统的linux和LiteOS-A内核移植到新的开发板上,要求读者具有一定的嵌入式系统开发经验。建议先查看 入门指导 ,以了解OpenHarmony软件架构、目录结构、内核子系统和驱动子系统相关知识。当前小型系统已适配的开发板如下表所示:
小帅聊鸿蒙
2025/06/23
1650
OpenHarmony开发——平台驱动移植
驱动主要包含两部分,平台驱动和器件驱动。平台驱动主要包括通常在SOC内的GPIO、I2C、SPI等;器件驱动则主要包含通常在SOC外的器件,如 LCD、TP、WLAN等
小帅聊鸿蒙
2024/08/05
1930
OpenHarmony开发——平台驱动移植
OpenHarmony 移植案例与原理 - HDF驱动框架-驱动配置(1)
HCS(HDF Configuration Source)是HDF驱动框架的配置描述源码,内容以Key-Value为主要形式。它实现了配置代码与驱动代码解耦,便于开发者进行配置管理。应该,类似Linux DTS(Device Tree Source)设备树。
小帅聊鸿蒙
2025/06/17
1350
OpenHarmony 移植案例与原理 - HDF驱动框架-驱动配置(1)
OpenHarmony开发——器件驱动移植
这些LCD的驱动被放置在源码目录//drivers/hdf_core/framework/model/display/driver/panel中。
小帅聊鸿蒙
2024/08/06
1850
OpenHarmony开发——器件驱动移植
OpenHarmony(鸿蒙南向开发)——轻量系统芯片移植案例(三)
本文介绍基于芯海cst85芯片的cst85_wblink开发板移植OpenHarmony LiteOS-M轻量系统的移植案例。开发了Wi-Fi连接样例和XTS测试样例,同时实现了wifi_lite, lwip, startup, utils, xts, hdf等部件基于OpenHarmony LiteOS-M内核的适配。移植架构上采用Board和Soc分离的方案,工具链采用NewLib C库,LiteOS-M内核编译采用gn结合Kconfig图形化配置的方式。
小帅聊鸿蒙
2025/06/26
1060
OpenHarmony(鸿蒙南向开发)——轻量系统芯片移植案例(三)
OpenHarmony(鸿蒙南向开发)——标准系统移植指南(一)
本文描述了移植一块开发板的通用步骤,和具体芯片相关的详细移植过程无法在此一一列举。后续社区还会陆续发布开发板移植的实例供开发者参考。
小帅聊鸿蒙
2025/06/24
1280
OpenHarmony(鸿蒙南向开发)——标准系统移植指南(一)
OpenHarmony(鸿蒙南向开发)——Combo解决方案之W800芯片移植案例
本方案基于OpenHarmony LiteOS-M内核,使用联盛德W800芯片的润和软件海王星系列 Neptune100开发板 ,进行开发移植。移植架构采用Board与SoC分离方案,支持通过Kconfig图形化配置编译选项,增加玄铁ck804ef架构移植,实现了HDF、XTS等子系统及组件的适配。
小帅聊鸿蒙
2025/06/27
900
OpenHarmony(鸿蒙南向开发)——轻量系统芯片移植指南(一)
OpenHarmony系统功能按照“系统 > 子系统 > 部件”逐级展开,支持根据实际需求裁剪某些非必要的部件,本文以部分子系统、部件为例进行介绍。若想使用OpenHarmony系统的能力,需要对相应子系统进行适配。
小帅聊鸿蒙
2025/06/22
1660
OpenHarmony-HDF驱动框架介绍及加载过程分析
HarmonyOS面向万物互联时代,而万物互联涉及到了大量的硬件设备,这些硬件的离散度很高,它们的性能差异与配置差异都很大,所以这要求使用一个更灵活、功能更强大、能耗更低的驱动框架。OpenHarmony系统HDF驱动框架采用C语言面向对象编程模型构建,通过平台解耦、内核解耦,来达到兼容不同内核,统一平台底座的目的,从而帮助开发者实现驱动一次开发,多系统部署的效果。
小帅聊鸿蒙
2025/06/20
1540
OpenHarmony-HDF驱动框架介绍及加载过程分析
OpenHarmony 移植案例与原理 - HDF驱动框架-驱动配置(2)
节点复制可以实现在节点定义时从另一个节点先复制内容,用于定义内容相似的节点。语法如下,表示在定义"node"节点时将另一个节点"source_node"的属性复制过来。
小帅聊鸿蒙
2025/06/18
820
【鸿蒙南向开发】基于hispark_taurus开发板示例学习OpenHarmony编译(1)
OpenHarmony开源站点提供了一个基于gn和ninja的支持OpenHarmony组件化开发的编译框架。
小帅聊鸿蒙
2025/06/09
1450
OpenHarmony 内核源码分析(gn应用篇) | gn语法及在鸿蒙的使用
gn 存在的意义是为了生成 ninja,如果熟悉前端开发,二者关系很像 Sass和CSS的关系.
小帅聊鸿蒙
2025/03/26
2300
基于hispark_taurus开发板示例学习OpenHarmony编译构建系统(2)
产品解决方案为基于开发板的完整产品,主要包含产品对OS的适配、组件拼装配置、启动配置和文件系统配置等。产品解决方案的源码路径规则为:vendor/{产品解决方案厂商}/{产品名称}。产品解决方案也是一个特殊的组件。
小帅聊鸿蒙
2025/06/10
860
基于hispark_taurus开发板示例学习OpenHarmony编译构建系统(2)
OpenHarmony 移植案例与原理 - XTS子系统之应用兼容性测试套件(1)
本文主要通过实例分析下ACTS应用兼容性测试套件移植案例,以及移植过程中特定的操作的原理。主要讲述的是轻量系统兼容性测试。轻量系统因系统能力限制,兼容性测试在系统初始化阶段进行;并且各设备烧录工具存在差异,导致自动化工具(xDevice工具)无法实现真正的自动适配,因此认证执行方式不对合作伙伴进行限制。流程如下:
小帅聊鸿蒙
2025/06/16
890
OpenHarmony(鸿蒙南向开发)——轻量系统芯片移植指南(三)
OpenHarmony芯片移植完成后,需要开展OpenHarmony兼容性测试以及芯片SDK功能性测试。除可获得测试认证之外,还可以在开发阶段提前发现缺陷,大幅提高代码质量。
小帅聊鸿蒙
2025/06/23
790
OpenHarmony(鸿蒙南向开发)——轻量系统芯片移植案例(二)
本方案基于OpenHarmony LiteOS-M内核,使用ASR582X芯片的 DEV.WIFI.A开发板 进行开发移植。作为典型的IOT Combo(Wi-Fi+BLE)解决方案,本文章介绍ASR582X的适配过程。
小帅聊鸿蒙
2025/06/26
820
OpenHarmony(鸿蒙南向开发)——轻量系统STM32F407芯片移植案例
介绍基于STM32F407IGT6芯片在拓维信息 Niobe407 开发板上移植OpenHarmony LiteOS-M轻量系统,提供交通、工业领域开发板解决方案。移植架构采用Board与SoC分离方案,使用arm gcc工具链Newlib C库,实现了lwip、littlefs、hdf等子系统及组件的适配,开发了配套应用示例代码,支持通过Kconfig图形化配置编译选项。
小帅聊鸿蒙
2025/06/27
1020
OpenHarmony(鸿蒙南向开发)——轻量系统STM32F407芯片移植案例
OpenHarmony开发——移植外设驱动子系统
外设驱动子系统提供OpenHarmony专有的外部设备操作接口。本模块提供设备操作接口有:FLASH, GPIO, I2C, PWM, UART, WATCHDOG等。
小帅聊鸿蒙
2024/08/04
3240
OpenHarmony开发——移植外设驱动子系统
推荐阅读
OpenHarmony(鸿蒙南向开发)——小型系统STM32MP1芯片移植案例
1030
OpenHarmony(鸿蒙南向开发)——轻量系统芯片移植指南(二)
790
OpenHarmony(鸿蒙南向开发)——小型系统芯片移植指南(一)
1650
OpenHarmony开发——平台驱动移植
1930
OpenHarmony 移植案例与原理 - HDF驱动框架-驱动配置(1)
1350
OpenHarmony开发——器件驱动移植
1850
OpenHarmony(鸿蒙南向开发)——轻量系统芯片移植案例(三)
1060
OpenHarmony(鸿蒙南向开发)——标准系统移植指南(一)
1280
OpenHarmony(鸿蒙南向开发)——Combo解决方案之W800芯片移植案例
900
OpenHarmony(鸿蒙南向开发)——轻量系统芯片移植指南(一)
1660
OpenHarmony-HDF驱动框架介绍及加载过程分析
1540
OpenHarmony 移植案例与原理 - HDF驱动框架-驱动配置(2)
820
【鸿蒙南向开发】基于hispark_taurus开发板示例学习OpenHarmony编译(1)
1450
OpenHarmony 内核源码分析(gn应用篇) | gn语法及在鸿蒙的使用
2300
基于hispark_taurus开发板示例学习OpenHarmony编译构建系统(2)
860
OpenHarmony 移植案例与原理 - XTS子系统之应用兼容性测试套件(1)
890
OpenHarmony(鸿蒙南向开发)——轻量系统芯片移植指南(三)
790
OpenHarmony(鸿蒙南向开发)——轻量系统芯片移植案例(二)
820
OpenHarmony(鸿蒙南向开发)——轻量系统STM32F407芯片移植案例
1020
OpenHarmony开发——移植外设驱动子系统
3240
相关推荐
OpenHarmony(鸿蒙南向开发)——小型系统STM32MP1芯片移植案例
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档