OpenHarmony GPIO应用开发-LED

学习于:
https://docs.openharmony.cn/pages/v5.0/zh-cn/device-dev/driver/driver-platform-gpio-develop.md
https://docs.openharmony.cn/pages/v5.0/zh-cn/device-dev/driver/driver-platform-gpio-des.md
通过OpenHarmony官方文档指导可获知:芯片厂商应当按照系统的平台驱动接口实现GPIO控制器驱动后,设备开发人员就可以按照系统GPIO的HDI接口使用GPIO,具体接口函数有:
在这里插入图片描述
其中函数参数gpioName指定IO口名,gpio指定IO口的ID,参数具体值由芯片厂商在.hcs配置文件中描述,如海思Hi3516中GPIO控制器驱动的描述:
在这里插入图片描述
Hi3516 GPIO控制器驱动自定义属性的描述:
在这里插入图片描述
其中属性groupNum指定Hi3516共有12组IO口,bitNum指定每组有8个IO口,由0 ~ 95数值分别表示96个IO,如GPIO2_3,则由数值19表示(2*8 + 3 = 19)。
属性gpioCustomName指定IO口的名称,依此名称可通过函数GpioGetByName获取IO口对应的ID。

接下来通过应用GPIO实现LED驱动:
开发板LED原理图
在这里插入图片描述
在这里插入图片描述
通过原理图可发现有: GPIO2_3 GPIO3_4 GPIO5_1控制LED的工作。

简单的LED驱动
在上篇简单的HDF驱动驱动源码基础上加入控制一个LED的代码,具体drivers/hdf_core/adapter/khdf/liteos/platform/src/myTestDriver.c驱动源码内容如下:

#include <hdf_device_desc.h>
#include <hdf_log.h>
#include <hdf_base.h>
#include <gpio_if.h>  // GPIO驱动调用接口

static int idGpio = 0;

static int32_t myDispatch(
    struct HdfDeviceIoClient *client, int id, struct HdfSBuf *data, struct HdfSBuf *reply)
{
    HDF_LOGD("### in %s : %d\n", __func__, id);
    GpioWrite(idGpio, id%2); //配置GPIO输出高低电平
    return HDF_SUCCESS;
}

int32_t myBind(struct HdfDeviceObject *obj)
{
    static struct IDeviceIoService testService = {
        .Dispatch = myDispatch,
    };
    obj->service = &testService;
    HDF_LOGD("#### in %s\n", __func__);

    idGpio = GpioGetByName("GPIO2_3"); //获取GPIO的ID
    GpioSetDir(idGpio, GPIO_DIR_OUT); //配置GPIO作输出用途

    return HDF_SUCCESS;
}
int32_t myInit(struct HdfDeviceObject *obj)
{
    HDF_LOGD("#### in %s\n", __func__);
    return HDF_SUCCESS;
}
void myRelease(struct HdfDeviceObject *obj)
{
    HDF_LOGD("#### in %s\n", __func__);
}

struct HdfDriverEntry myTestEntry = {
    .Bind = myBind,
    .Init = myInit,
    .Release = myRelease,
    .moduleName = "myTestDriver",
    .moduleVersion = 1
};
HDF_INIT(myTestEntry);

沿用上篇里的应用程序,当应用程序执行起来后,开发板的LED会在GPIO输出高电平时亮,低电平时熄。

硬件资源分离与可重用的LED驱动
按照OpenHarmony文档指导,硬件相关的资源应当在.hcs配置文件中描述。这里三个LED分别作为一个设备进行描述 :
在这里插入图片描述
然后在vendor/hisilicon/hispark_taurus/hdf_config/目录下创建myLight文件夹,并在文件夹里创建myLight.hcs配置文件,描述设备自定义的属性:
在这里插入图片描述
每个节点通过match_attr与设备节点的deviceMatchAttr进行匹配,相同值表示此节点资源由对应的设备使用。 gpioName自定义属性向LED驱动提供LED设备的控制IO。
然后修改vendor/hisilicon/hispark_taurus/hdf_config/hdf.hcs配置文件,增加myLight.hcs文件的使用:
在这里插入图片描述

驱动源文件myTestDriver.c代码修改为:

#include <hdf_device_desc.h>
#include <hdf_log.h>
#include <hdf_base.h>
#include <gpio_if.h>
#include <device_resource_if.h>
#include <osal_mem.h>

struct myLightService {
    struct IDeviceIoService service;
    int idGpio;
    const char *gpioName;
};

static int32_t myDispatch(
    struct HdfDeviceIoClient *client, int id, struct HdfSBuf *data, struct HdfSBuf *reply)
{
    struct HdfDeviceObject *obj = client->device;
    struct myLightService *srv = (struct myLightService *)(obj->service);

    HDF_LOGD("### in %s, %s  %d\n", __func__,  srv->gpioName, id);
    GpioWrite(srv->idGpio, !!id);
    return HDF_SUCCESS;
}

int32_t myBind(struct HdfDeviceObject *obj)
{

    struct myLightService *srv = NULL;

    struct DeviceResourceIface *dr = DeviceResourceGetIfaceInstance(HDF_CONFIG_SOURCE);

    srv = OsalMemCalloc(sizeof(struct myLightService));
    dr->GetString(obj->property, "gpioName", &srv->gpioName, NULL);
    srv->service.Dispatch = myDispatch;
    srv->idGpio = GpioGetByName(srv->gpioName);

    GpioSetDir(srv->idGpio, GPIO_DIR_OUT);

    obj->service = &srv->service;

    return HDF_SUCCESS;
}
int32_t myInit(struct HdfDeviceObject *obj)
{
    return HDF_SUCCESS;
}
void myRelease(struct HdfDeviceObject *obj)
{
    struct myLightService *srv = (struct myLightService *)(obj->service);
    OsalMemFree(srv);
}

struct HdfDriverEntry myTestEntry = {
    .Bind = myBind,
    .Init = myInit,
    .Release = myRelease,
    .moduleName = "myTestDriver",
    .moduleVersion = 1
};
HDF_INIT(myTestEntry);



在applications/sample/camera/myhello/mytest.c代码修改为:

#include <fcntl.h>
#include <sys/stat.h>
#include <sys/ioctl.h>
#include <unistd.h>
#include "hdf_log.h"
#include "hdf_sbuf.h"
#include "hdf_io_service_if.h"

int main(int argc, char *argv[])
{
    if (3 != argc)
    {
        printf("usage: %s  serviceName  num \n", argv[0]);
        return 1;
    }

    struct HdfIoService *srv = HdfIoServiceBind(argv[1]);
    if (srv == NULL) {
        printf("fail to get service\n");
        return 1;
    }

    int ret = srv->dispatcher->Dispatch(&srv->object, atoi(argv[2]), NULL, NULL);
    printf("test end\n");

    HdfIoServiceRecycle(srv);
    return 0;
}

同目录下的BUILD.gn内容如下:

hdf_framework_path = "../../../../../framework"

executable("mytest") {
  sources = [ "mytest.c" ]

  include_dirs = [
    "$hdf_framework_path/ability/sbuf/include",
    "$hdf_framework_path/core/shared/include",
    "$hdf_framework_path/core/host/include",
    "$hdf_framework_path/core/master/include",
    "$hdf_framework_path/include/core",
    "$hdf_framework_path/include/utils",
    "$hdf_framework_path/utils/include",
    "$hdf_framework_path/include/osal",
    "//third_party/bounds_checking_function/include",
    "//base/hiviewdfx/hilog_lite/interfaces/native/innerkits",
  ]

  deps = [
    "//drivers/hdf_core/adapter/uhdf/manager:hdf_core",
    "//drivers/hdf_core/adapter/uhdf/posix:hdf_posix_osal",
    "//base/hiviewdfx/hilog_lite/frameworks/featured:hilog_shared",
  ]

  public_deps = [ "//third_party/bounds_checking_function:libsec_shared" ]
  defines = [ "__USER__" ]
}

然后修改applications/sample/camera/bundle.json文件增加内容:
在这里插入图片描述
完成后编译系统,并重新烧录OHOS_Image.bin与rootfs_vfat.img

应用程序执行时通过指定不同的服务名与电平值控制LED,如:

  ./bin/mytest  myTestService0   1      
  ./bin/mytest  myTestService1   1    
<think>好的,用户遇到了Git合并时本地更改会被覆盖的问题,需要解决方案。根据之前的引用资料,解决方法主要有commit、stash和revert三种。首先,我得确认用户的具体情况,比如他们的本地更改是否已经完成,是否需要保留,或者是否可以丢弃。用户可能不太清楚这三种方法的适用场景,需要详细解释每个选项的步骤和优缺点。比如,commit适用于需要保留更改的情况,stash适合临时保存以便后续恢复,而revert则是直接撤销更改,适用于不需要保留的情况。需要结构清晰,分点说明,每个方法都给出操作步骤和适用场景,帮助用户理解哪种情况最适合他们。还要注意使用中文,避免技术术语过于复杂,让用户容易理解。同时,生成相关问题,可能涉及如何恢复stash的内容,或者如何避免频繁冲突等,扩展用户的知识点。另外,要确保LaTeX格式正确,但在这个问题中可能用不上数学公式,所以主要关注代码块和引用标识。检查引用是否正确,比如引用[^1]和[^2]的来源是否相关,用户提供的引用内容是否准确对应解决方案。 最后,确保回答真实可靠,操作步骤准确无误,避免误导用户。可能还需要提醒用户根据具体情况选择方法,比如如果有未完成的实验性代码,stash可能是更好的选择,而如果是确定要保留的修改,则应该commit。</think>要解决Git合并时本地更改被覆盖的问题,可根据不同场景选择以下三种方法: ### 一、提交本地更改(commit) **适用场景**:当本地更改已测试通过且需要保留到版本历史中。 **操作步骤**: 1. 将改动添加到暂存区: ```bash git add . # 添加所有文件 # 或指定文件 git add file1.txt file2.py ``` 2. 提交更改并添加描述: ```bash git commit -m "完成用户登录模块优化" ``` 3. 执行合并操作: ```bash git merge origin/main ``` **优点**:保留完整的开发记录,便于后续追溯[^1]。 ### 二、暂存更改(stash) **适用场景**:需要临时保存未完成的修改(如调试代码),优先处理合并操作。 **操作步骤**: 1. 保存当前工作状态: ```bash git stash # 可选添加备注 git stash save "用户登录模块调试代码" ``` 2. 查看暂存记录列表: ```bash git stash list ``` 3. 合并远程分支: ```bash git merge origin/main ``` 4. 恢复暂存内容: ```bash git stash pop # 恢复并删除最近一次暂存 # 或指定特定暂存 git stash apply stash@{1} ``` **优点**:保持工作目录整洁,特别适合处理紧急合并任务[^2]。 ### 三、撤销本地更改(revert) **适用场景**:本地修改可丢弃(如实验性代码或错误修改)。 **操作步骤**: 1. 撤销所有未提交的修改: ```bash git checkout -- . # 全部文件 # 或指定文件 git checkout -- file1.txt ``` 2. 执行合并操作: ```bash git merge origin/main ``` **风险提示**:此操作不可逆,需确认文件无需保留。 --- ### 对比决策表 | 方法 | 保留记录 | 可恢复性 | 适用阶段 | |---------|----------|----------|------------------| | commit | ✅ | ✅ | 功能开发完成时 | | stash | ❌ | ✅ | 开发中途临时切换 | | revert | ❌ | ❌ | 放弃无效修改 | ### 扩展应用场景 - 当存在多个暂存时,可用`git stash list`查看记录,通过`git stash apply stash@{n}`精准恢复 - 合并后出现冲突时,可使用`git mergetool`可视化工具解决冲突 - 长期分支开发推荐使用`git rebase`保持提交历史线性
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值