HarmonyOS鸿蒙Next中从本质上学会基于Hi3861开发（主要讲授方法）

HarmonyOS鸿蒙Next中从本质上学会基于Hi3861开发（主要讲授方法） 引言：花半秒钟就看透事物本质的人，和花一辈子都看不透事物本质的人，注定是截然不同的命运
做开发也一样，如果您能看透开发的整个过程，就不会出现“学会了某个RTOS的开发，同样的RTOS开发换一块开发板又不会了”，“跟着教程学会了某块开发板的某个Demo开发，自己开发另一个Demo又不会了”等等问题，只要能看透就能做到触类旁通，游刃有余！一定要活学活用，不能学死了，多想想为什么，不要死记过程。

在基于HarmonyOS开发Hi3861之前，需要对整个开发环境及过程有一个全局上的了解，首先还是从这一张最经典的框架图给大家讲起：

目前我们对Hi3861的开发主要涉及上图中的内核抽象层、系统能力子系统、DXF子系统、公共基础库子系统（提供KV存储、文件操作、定时器、IoT外设控制等能力供OpenHarmony各业务子系统及上层应用使用）、系统服务框架子系统（用于提供面向服务编程和对外提供能力用于分布式任务调度）

1、构建系统

该构建系统由python脚本配合gn、ninja组成，若是为了开发Demo或者应用，不必细究编译构建系统的具体实现细节，只需要做到会使用即可。 当我们输入python build.py wifiiot指令，python脚本开始读取build目录中与wifiiot设备相关的各项参数信息并构造编译指令如下：

gn工具所在目录/gn gen 源码所在目录/out/wifiiot --root=. --dotfile=build/lite/.gn --args='product = "wifiiot" ohos_build_type = "release"'

这条指令用于生成一些xxx.ninja文件，这些文件将在下一阶段指导ninja编译源码生成烧录文件

ninja工具所在目录/ninja -w dupbuild=warn -C 源码所在目录/out/wifiiot

这条指令用于根据前面生成的xxx.ninja文件调用工具链编译源码最终生成烧录文件 gn用于根据每个目录下的BUID,gn文件搜寻编译生成烧录文件所需的依赖文件，所以我们只要学会如何写BUILD.gn文件即可，关于具体实现本章就暂且略过，后期会给大家补上。 这里以led_example.c程序为例，给大家分析BUILD.gn文件，希望大家能举一反三： 在code-1.0\applications\sample\wifi-iot\app目录中有一个BUILD.gn文件，大家可以将该文件理解为一个管理者，它管理app目录中的每个子目录，通过这个BUILD.gn文件中的features字段可以决定哪一个子目录中的BUILD.gn中指定的源文件会被编译到烧录文件中，如下图所示：

假设我们要将app/iothardware目录中的led_example.c文件编译到烧录程序中，需要打开app/iothardware/BUILD.gn文件查看该文件中的源代码被为静态库的名称，可以看到名称为led_example，如下图所示：

这时我们将app/BUILD.gn文件中的startup修改为iothardware:led_example就大功告成啦！

.gn文件的feature字段格式为：模块源文件所在路径:模块名称 请注意：.gn文件中的空白都是空格，不是Tab键（制表符），如果您输入了制表符，在生成ninja文件时就会产生如下图所示错误：

我出一个问题考考大家，如果我们在app/iothardware目录中添加一个hello_world.c文件，主要用于打印hello_world，假设源代码已经写好了，您应该如何将其添加进编译列表中与其他程序一起进行编译呢？

您应该修改app/iothardware/BUILD.gn文件，将hello_world.c文件添加到sources字段中，如下图所示：

若这时我们在app/iothardware目录下新建一个head的目录，并在其中新建一个名为hello_world.h的头文件，内容如下：

并修改hello_world.c的内容如下：

这时如果直接进行编译，则会产生找不到头文件错误，如下图所示：

我们应该继续对app/iothardware/BUILD.gn文件进行修改，在include_dirs中添加hello_world.h头文件所在路径，如下图所示：

上面的路径中以 //开头的路径为绝对路径，//表示root参数指定的路径，也就是code-1,0，而test路径则为相对路径，以当前BUILD.gn文件所在目录作为参照。

这样一个简单的Demo就开发好了，不知道读者有没有这样的疑问：为什么我知道启动一个任务的宏是SYSY_RUN()，IIC、SPI等等外设操作的函数是什么？一系列类似的问题，那您继续往下看就能找到答案。

目录结构

注意：Hi3861模组只用到了部分组件

希望大家能跟随我对目录的介绍，自己打开对应本地SDK的目录来看一看

├── applications  存放例程
│   └── sample
├── base
│   ├── global  全球化子系统
│   ├── hiviewdfx  DXF子系统
│   ├── iot_hardware  iot设备的公共基础库子系统，提供外设操作，IIC、SPI等等
│   ├── security  安全子系统
│   └── startup  启动恢复相关
├── build  构建系统相关，存放各类芯片的编译构建参数等等
│   └── lite
├── build.py -> build/lite/build.py 与构建系统相配合的python脚本（用于启动构建）
├── docs  文档
├── domains 集成各个厂商的SDK
│   └── iot
├── drivers 驱动相关，HDF驱动框架
│   ├── hdf
│   └── liteos
├── foundation
│   ├── aafwk  提供一个Want名称的数据类型用于加速应用的启动
│   ├── ace  JS应用开发框架
│   ├── appexecfwk 用于程序框架子系统
│   ├── communication 分布式通信子系统（软总线）
│   ├── distributedschedule 系统服务框架子系统（面向服务编程，提供服务、使用服务等）、分布式任务调度子系统
│   ├── graphic 图形子系统
│   └── multimedia 媒体子系统
├── kernel 内核以及kal层
│   ├── liteos_a 面向Hi3516 3518等资源较丰富设备的内核
│   └── liteos_m 面向资源受限设备的内核
├── out 编译输出文件
│   ├── ipcamera_hi3516dv300
│   └── wifiiot
├── prebuilts 提供一些库文件
│   └── lite
├── test 测试子系统
│   ├── developertest
│   ├── xdevice
│   └── xts
├── third_party 第三方库，例如cmsis、cJSON、Fatfs等等
├── utils 公共基础系统，提供文件操作统一接口、KV存储、文件操作、定时器
│   └── native
└── vendor 各个厂商提供的SDK
    ├── hisi
    └── huawei

base以及foundation中的各个组件中都有两个名字相同的文件夹frameworks和interfaces，其中frameworks中存放该组件的具体实现，interfaces中存放对外提供的调用接口，这里以base/iot_hardware为例，其中hal文件夹中存放hi3861的SDK中提供的KV存储、文件操作、定时器和IoT外设控制的函数接口（函数接口指的是函数声明，我们只要知道函数声明，就不用关心函数的实现细节就能调用该函数完成相应操作），frameworks是对hal中的函数声明进行一定的封装，从而实现统一的接口，封装后的函数声明位于interfaces文件夹中，换句话说，我们想使用某个组件只需要查看interfaces文件夹中的声明，这样做的好处是：更换硬件或软件实现的情况下无需改动上层应用（例如目前我使用hi3861开发板实现了一些功能，这时甲方爸爸叫我用hi3516来实现同样的功能，我只需要将相应功能的底层支持函数的调用接口修改为interfaces文件夹中的形式，即可完成新的需求），大大的提高了开发效率。

如何创建一个任务？

SYS_RUN宏定义的正确用法为：

首先定义一个“初始化函数”，例如下面的“LedExampleEntry()”，所谓初始化是指初始化即将启动的任务需要的各类资源（例如：GPIO外设初始化），在这个“初始化”函数中初始化好了各类资源后调用osThreadNew函数（该创建线程的函数中调用了LOS_TASK_Create函数，也就是上面liblitekernel_flash.a库中提供的函数）创建线程即可。最后将“初始化”函数传入SYS_RUN宏中，在系统启动阶段时，系统会为其创建一个进程，优先级默认为2。SYS_RUN宏会在链接时将进程入口函数统一链接到某个段中，等待系统启动去这个段中将这些进程加载并运行（之前LiteOS的思想），这样做的优势是：可以让系统在合适的时候自动加载这些进程，无需用户考虑什么时候加载进程比较合适。 其中体现了一个进程和线程的思想，首先通过SYS_RUN宏创建了一个进程，该进程下面可以有多个线程。

//来源于code-1.0\utils\native\lite\include\ohos_init.h
/**
 * @brief Identifies the entry for initializing and starting a system running phase by the
 * priority 2.
 *
 * This macro is used to identify the entry called at the priority 2 in the system startup
 * phase of the startup process. \n
 *
 * @param func Indicates the entry function for initializing and starting a system running phase.
 * The type is void (*)(void).
 */
#define SYS_RUN(func) LAYER_INITCALL_DEF(func, run, "run")
 
//来源于code-1.0\applications\sample\wifi-iot\app\iothardware\led_example.c
static void LedExampleEntry(void)
{
    osThreadAttr_t attr;
 
//第一步初始化该进程需要用到的资源
    GpioInit();
    IoSetFunc(WIFI_IOT_IO_NAME_GPIO_9, WIFI_IOT_IO_FUNC_GPIO_9_GPIO);
    GpioSetDir(WIFI_IOT_IO_NAME_GPIO_9, WIFI_IOT_GPIO_DIR_OUT);
 
    attr.name = "LedTask";
    attr.attr_bits = 0U;
    attr.cb_mem = NULL;
    attr.cb_size = 0U;
    attr.stack_mem = NULL;
    attr.stack_size = LED_TASK_STACK_SIZE;
    attr.priority = LED_TASK_PRIO;
 
//第二步：为该进程创建线程
    if (osThreadNew((osThreadFunc_t)LedTask, NULL, &attr) == NULL) {
        printf("[LedExample] Falied to create LedTask!\n");
    }
}
 
SYS_RUN(LedExampleEntry);

如何找到您想使用函数API？

您首先需要对开头的框架图以及第2点的目录结构有一个大概的了解，并且根据您需要的API进行分析该API可能位于哪里。

例如：我需要找一个创建线程的函数，通过框架图我能得知，线程创建函数在KAL层或者内核层中，Hi3861设备遵循cmsis接口标准，首先我打开kernel\liteos_m\components目录，即可在其中寻找，最终在cmsis文件中找到该函数。 我需要寻找一个iic操作的函数，根据目录结构，我能得知该函数在base/iot_hardware/interfaces目录中，最终找到wifiiot_i2c.h。

搭建iot世界的积木已经交给您啦，最后能搭建出什么样子就全看您啦！