鸿蒙硬件开发:HarmonyOS下的LiteOS | 您所在的位置:网站首页 › 鸿蒙系统对芯片的要求 › 鸿蒙硬件开发:HarmonyOS下的LiteOS |
前言
先来看看HarmonyOS的技术架构: 总的来说,在轻小型系统中,HarmonyOS所使用的内核为LiteOS,在标准系统中使用Linux。 而目前Huawei LiteOS支持多种芯片架构,如Cortex-M series、Cortex-R series、Cortex-A series等。LiteOS有两个应用方向,分别是LiteOS-M和LiteOS-A。 LiteOS-M适用于轻量级的芯片架构,面向的MCU一般是百K级内存,例如cortex-m、riscv32;而LiteOS-A则适用于小型的芯片架构,面向设备一般是M级内存,例如cortex-a。我使用的hi3861v100,芯片架构为riscv32,所适配的就是LiteOS-M内核。 这是官方文档中的一段描述: 首先看看LiteOS-M的内核架构图。可以看到应用于轻量级内核的LiteOS-M整体的架构非常简单,底层支持的内核目前只有Cortex-M和RISC-V系列,在此之上抽象出统一的硬件架构。以该硬件架构为基础,加入OS内核和拓展模块,再继续将这两部分抽象出来,适配到CMSIS和POSIX两个标准上,这样在应用层所编写的程序,就可以具有良好的移植性和可拓展性。
├── components # 可选组件 │ ├── cppsupport # C++支持 │ └── cpup # CPUP功能 ├── kal # 内核抽象层 │ ├── cmsis # cmsis标准接口支持 │ └── posix # posix标准接口支持 ├── kernel # 内核最小功能集支持 │ ├── arch # 内核指令架构层代码 │ │ ├── arm # arm32架构的代码 │ │ └── include # 对外接口存放目录 │ ├── include # 对外接口存放目录 │ └── src # 内核最小功能集源码 ├── targets # 板级工程目录 ├── utils # 通用公共目录 那么根据上方的LiteOS-M架构图,一层一层分析。 硬件架构抽象层姑且这么叫。在官网可以看到对这部分的定义。可以看到现有的工程已经对特定的架构进行了适配支持。 还是姑且这么叫吧,我随便起的🙃。 基本上所有的OS都会有的一些东西,包括事件、队列、信号量、互斥量、线程/任务等等。这些模块的具体实现文件在 /kernel/liteos_m/kernel/src 中,如下图。 这就是最开始那张架构图中的基础内核部分,实现了LiteOS的核心内容。 内核抽象层,终于有正经名字了🙃。这一层的目的其实跟硬件架构抽象层差不多。硬件架构抽象层是为了消除一个系统中硬件架构的不同而将其抽象出统一的接口,KAL层是为了让应用层在不同的操作系统上实现统一的API调用体验而产生的。这么说好像有点绕,在代码里看一眼其实就很容易理解了。 在刚开始学LiteOS的时候,可以发现,其实LiteOS本身的API都是以 LOS 开头的,例如下图是官网对LiteOS-M的任务接口介绍。 LOS_TaskCreate(UINT32 *taskID, TSK_INIT_PARAM_S *taskInitParam); //创建一个新任务 TSK_INIT_PARAM_S //任务初始化结构体 刚看完LiteOS教程的时候,我就有这个疑惑:在上一篇中的第一个程序中,可以看到,对任务初始化的结构体变成了 osThreadAttr_t ,而创建新任务的API变成了 osThreadNew() ,明明hi3861是riscv32的架构,使用的就是LiteOS-M,为什么这里的API不是LiteOS的API呢? 它包含多个组件层,其中之一是RTOS层,该层定义了一套通用及标准化的RTOS API接口,减少了应用开发者对特定RTOS的依赖,方便用户软件的移植重用。 至于这明明是给cortex创建的标准,为什么riscv32的架构也用这套?如下: 总之,从功能上看,实现这套标准的目的,说的简单一点,就是为了让我们在基于cortex内核(riscv?)使用操作系统的情况下,所编写的应用层的代码,不会因为操作系统的变更而大量的修改OS部分的API。 举个例子,如果我使用rt-thread编写了一套应用层代码,其中使用的都是 rt_thread_create() API来创建线程,现在我想在LiteOS上实现同样的功能,加入逻辑上不需要修改,但是这显然需要将文件中所有对rt-thread的API都换成LiteOS的,例如创建线程的 rt_thread_create() 都要换成 LOS_TaskCreate() ,还有其他所有的OS有关的API,都需要替换。 但是如果我在使用两个操作系统之前,都做了类似KAL层的抽象操作,都把它抽象成 osThreadNew() ,那么我的应用代码就可以原封不动的直接照搬,移植到另一个操作系统上,这就是KAL层的作用。 上图中表示HarmonyOS LiteOS-M仅提供其版本2的实现,我们可以在代码中看看具体的实现方法。 同样在liteos_m的文件目录下,可以看到 kal/cmsis 文件夹下,有着liteos对cmsis定义的os的实现。 那么其实很容易发现,这其实就是对LiteOS的原生API再进行一次封装,封装出的API是一个cmsis对于OS的标准API格式,也就是这个 osThreadNew() 。 当然另一方面的POSIX的适配也是同样的意思。就不过多哔哔了。 |
CopyRight 2018-2019 实验室设备网 版权所有 |