支持MIPS 架构的轻量型开源鸿蒙系统移植

王一泠，吴 琦，安军社

（1.中国科学院国家空间科学中心 复杂航天系统电子信息技术重点实验室，北京 100190；2.中国科学院大学 计算机科学与技术学院，北京 100049）

0 概述

航天型号嵌入式软件固化在航天星载计算机中，与硬件关系密切，协同完成特定功能［1］。空间环境的复杂性导致航天器软硬件故障发生的可能性随着系统的复杂程度激增［2］，同时航天载荷需要不间断地采集处理空间实时数据并对海量历史数据进行查询［3］，当软件任务启动后，就不能直接对航天器嵌入式设备进行维护［4］。

为了提高系统可靠性，除了常规应用星载系统备份冗余等机制［2］外，空间数据系统咨询委员会（the Consultative Committee for Space Data Systems，CCSDS）高级在轨系统标准定义的分布式架构也具有一定参考意义［5］。将这种分布式架构应用在星载计算机系统上，使得星载地球敏感器、磁强计、太阳敏感器、星敏感器、热控传感器等通过导线与接插件连接低成本且具备OS 的轻型航天计算终端，再通过终端与具有处理海量数据和复杂任务能力的高性能中心计算机通信。当终端设备出现不可恢复的故障时，因其无需对数据进行保存，所以不会对星载数据中心计算机产生影响，在有效降低成本的同时也提高了系统整体可靠性。作为系统典型节点之一的航天器控制终端［5］是一种类瘦终端［6-8］的宇航级终端，具有小体积、低功耗、轻量型的特点，并具备OS、CPU 及运算处理能力，能够提供I/O 设备接口以及与服务器端的网络通信等功能，适用于以数据、服务器为中心的分布式计算模式，且因终端具备OS，能够通过统一的接口实现软硬件解耦，从固化在硬件的定制化嵌入式软件转向针对航天应用需求、快速迭代升级的软件［9］，并具有多任务处理能力和通过配置适应多协议环境的能力。鉴于这些优势，航空航天领域的类瘦终端分布式架构应用具有广阔前景，但目前宇航级终端处理器上轻量且自主可控的操作系统缺失成为这种分布式架构在国内航天领域部署应用的瓶颈。

对国外的软硬件平台长期依赖，致使系统和数据不自主可控的问题日益显现［10］，发展自主CPU 与操作系统，构建自主可控的信息技术体系，成为航天装备发展的目标［11］。美国风河公司推出的VxWorks嵌入式实时操作系统（Real-Time Operation System，RTOS）具有高实时性、低功耗、高性能、可裁剪等特点［12-14］，被广泛应用于国内航天型号任务。OpenHarmony 作为国产操作系统支持多内核，可在小型资源受限的设备上选择以LiteOS-M 为内核的轻量型实时子系统，具有实时性高、可靠性高、裁剪体积小的特点［15-17］，且具有丰富的功能组件，相较于VxWorks 可被裁剪得更小以适配资源更为受限的控制终端。2022 年，深圳软通动力信息技术股份有限公司［18］实现了龙芯自研指令集LoongArch 架构的龙芯2K1000LA 处理器与开源鸿蒙系统的兼容适配，但其适配的是基于OpenHarmony 多内核之一的Linux 内核，而非轻量型实时内核LiteOS-M。在目前OpenHarmony LiteOS-M 内核实时系统仅支持ARM、RISC-V 等架构的情况下，对于该公司专为航天空间应用研制的LS1J 与LS1C 等高可靠性、低功耗、轻量型热控处理器芯片，因采用的是龙芯CPU 原指令系统MIPS 架构［19］，尚未被开源鸿蒙系统支持。

本文对开源鸿蒙轻量型LiteOS-M 内核与MIPS体系结构进行介绍与分析，针对我国航空航天领域类瘦终端的轻量型实时操作系统的缺失与信息技术体系不完全自主可控的问题，提出支持MIPS 架构的OpenHarmony 轻量实时系统移植方案，并在MIPS 架构宇航级控制终端龙芯LS1J 与LS1C 硬件平台上验证系统适配的可行性。

1 相关技术

1.1 OpenHarmony 多内核技术

OpenHarmony 采用多内核设计，利用内核抽象层（Kernel Abstraction Layer，KAL）屏蔽多内核差异，对系统上层提供基础的内核能力，包括进程/线程管理、内存管理、文件系统、网络管理和外设管理等。

OpenHarmony 支持轻量实时系统、小型系统和标准系统3 种系统类型，可针对不同应用场景与硬件资源选用合适的系统内核。轻量实时子系统LiteOS-M 内核面向MCU 类处理器，适用于ARM Cortex-M 平台，是开源鸿蒙面向IoT 领域资源极小设备的实时系统，应用在传感器终端及穿戴类设备上。小型系统LiteOS-A 内核适用于ARM Cortext-A平台，是支持MMU 的非实时系统，要求应用设备最小内存达到1 MB 以上，应用于智能家居领域的IP Camera、路由器等终端。标准系统Linux 内核是基于安卓开放源代码项目（Android Open Source Project，AOSP）进行改良的分时操作系统，要求应用设备最小内存达到128 MB 以上，可以提供增强的交互能力及硬件资源合成能力，应用于高端冰箱显示屏、平板等智能终端。

由于星载小型化控制终端资源十分受限且对实时性要求较高，因此选用开源鸿蒙以LiteOS-M 为内核的轻量实时子系统完成MIPS 架构适配。

LiteOS-M 是开源鸿蒙轻量型操作系统内核，自下而上由硬件抽象层（Hardware Abstraction Layer，HAL）、内核功能层、增强组件层和标准应用接口层组成。LiteOS-M 内核架构［15］如图1 所示。

图1 LiteOS-M 内核架构Fig.1 LiteOS-M kernel architecture

1）HAL。HAL 屏蔽了硬件平台的差异，给上层提供硬件无关的统一操控接口，实现系统与芯片的解耦，具有可移植性。系统移植主要是HAL 移植，包括体系结构抽象层、变体抽象层与平台抽象层。体系结构抽象层即针对不同处理器的不同体系结构，如ARM、MIPS 系列等，对中断异常及上下文切换进行差异屏蔽；变体抽象层指该类处理器所具有的特殊性，包括Cache、MMU、FPU 等；平台抽象层指对当前系统的硬件平台进行抽象，包括平台启动、芯片配置、外设I/O 寄存器访问以及中断控制等［20］。实现该层的函数可根据实际的功能需求调用板级支持包（Board Support Package，BSP）中的函数。

2）基础内核。基础内核提供任务管理、内存管理、时间管理、中断控制、进程间通信（Inter-Process Communication，IPC）等功能。移植工作的基本任务是适配系统内核与硬件相关部分的功能，保障系统内核基础功能的完整性。

3）内核功能增强组件层。配置组件启用相应功能，LiteOS-M 内核可配置包括文件系统、网络与调测工具等组件。另外，可依据移植平台应用场景配置低功耗框架组件来降低功耗，配置Trace 回溯组件与ExcHook 组件辅助开发工作。

4）KAL。内核抽象层向上层应用层提供CMSIS、POSIX 标准接口支持，对内核提供功能抽象封装，屏蔽多内核差异。

1.2 MIPS 架构

1.2.1 MIPS 与龙芯

MIPS 作为最早的商业精简指令集计算机（Reduced Instruction Set Computer，RISC）设计架构芯片之一，其机制是尽量利用软件避免流水线中的数据相关问题，与复杂指令系统计算结构相比设计周期更短［21］。

中国科学院计算技术研究所购买了MIPS 指令授权，自主研发了低功耗、低成本和完全自主知识产权的龙芯系列CPU，主要应用于嵌入式防火墙、嵌入式网关等低端嵌入式领域以及航空航天等特殊应用环 境。2020 年，龙芯团 队［22-23］独立研 制LoongArch龙架构。MIPS 与LoongArch 架构都是基于RISC 设计的处理器架构，但在指令集、寄存器约定、存储器地址映射、中断及异常、指令集扩展与执行效率等方面存在较大差异。目前，支持LoongArch 的龙芯3A500 处理器芯片已经成功量产，但在航空航天领域，仍旧大量使用龙芯处理器原兼容指令系统MIPS架构的成熟产品。

1.2.2 MIPS 架构寄存器

MIPS 架构处理器通常具有通用寄存器、特殊寄存器、CP0 协处理器3 种寄存器类型。在通用寄存器中，a0～a3 一般用来保存函数形参，s0～s7 保存静态数据，t0～t9 保存临时数据。R28（GP）保存全局指针用于MIPS 小数据区变量的访问［24］。R29（SP）作为堆栈指针寄存器，指向系统主堆栈或任务栈。R31（RA）保存函数返回地址。特殊寄存器HI/LO 用于存储整数乘除和累加计算操作的中间结果。PC 寄存器对程序员透明不可用，当发生精确异常时将当前地址记录在实际的寄存器EPC 中。MIPS 架构CP0 协处理器提供的重要系统控制寄存器名称与功能如表1 所示。

表1 MIPS 架构CP0 协处理器重要寄存器及其功能Table 1 Important registers and their functions of MIPS architecture CP0 coprocessor

1.3 关键技术分析

系统移植适配工作主要是针对HAL、基础内核硬件相关部分的移植。开源鸿蒙不支持龙芯处理器的MIPS 架构，而MIPS 架构与LiteOS-M 内核支持的ARM、RISC-V 架构之间又具有较大差异，因此对于新的体系结构，硬件抽象层的建立具有一定难度。架构移植工作需要根据LiteOS-M 内核功能、工程构建、MIPS 架构与龙芯硬件平台的特点，设计包括引导程序启动加载、系统任务管理、上下文切换、启动任务调度、异常与中断处理、系统时钟6 个关键执行环节。除此之外，移植工作还需完成和硬件处理器存储资源适配的内核裁剪、架构工具链搭建与BSP开发等工作。

2 系统MIPS 架构移植设计方案

下面对加载程序引导、任务管理、上下文切换、任务调度启动、异常与中断处理、系统时钟6 个移植关键环节给出设计方案与实现流程。

2.1 加载程序引导

BootLoader 引导代码是操作系统运行前执行的一段汇编启动程序，帮助系统完成启动前的软硬件初始化，为最终引导操作系统提供合适的环境。移植引导代码首先需要指定硬件FLASH 偏移位置的异常入口并初始化启动时异常处理向量，确保在启动出错时正确调用异常处理程序，同时设置主堆栈（SP）、全局指针寄存器（GP）保证能够访问到主堆栈与MIPS 架构特有的.sdata 小数据区。接着初始化通用寄存器与CP0 协处理器，完成必要的硬件初始化后，再将.data 段从FLASH 中搬运到SRAM 并清空未初始化的全局变量.bss 段。最后跳转至系统初始化入口。引导程序设计流程如图2 所示。

图2 引导程序设计流程Fig.2 Design process of guided program

2.2 任务管理

任务管理功能是航天嵌入式实时操作系统的关键组成部分，是整个系统安全、可靠、高效运行的基础。任务管理包括任务的创建、删除、延时、状态控制与转换、优先级配置等功能。OpenHarmony 轻量实时系统中每个任务都是执行程序的一个实例，都有唯一的TaskID 与LosTaskCB 任务控制块描述符与之对应。LosTaskCB 结构体标识了任务在生命周期内的运行情况。由于航天任务通常具有严格的实时性要求，在多任务并发且单核的情况下，内核采用优先级抢占式调度机制引起任务上下文发生切换，避免任务因为等待或者竞争资源而出现延迟或丢失的情况。

在OpenHarmony 实时系统LiteOS-M 内核中，任务共有32 个优先级（0～31），优先级数值越低对应优先级别越高，高优先级的任务可以抢占低优先级任务当前占有的CPU。在发生任务调度时，优先执行任务就绪队列中最高优先级的任务。任务就绪队列可以方便地支持任务基于优先级进行调度。如图3所示，LiteOS-M 内核就绪队列由一个双向循环链表数组管理，每个数组元素都是一个LOS_DL_LIST 双向循环链表，通过任务描述符LosTaskCB 中的pendList 成员相互挂接，从而能够快速定位同一优先级的任务。g_losPriorityQueueList 任务就绪队列数组长度对应了系统优先级个数。

图3 任务优先级就绪队列与优先级位图Fig.3 Task priority ready queue and priority bitmap

g_priQueueBitmap 优先级位图标识了任务就绪队列中已挂载的就绪任务所在的优先级。当时间片到期发生任务调度时，遍历位图的32 位能快速找到就绪队列中最高优先级所在的双向循环链表，从而高效地定位就绪队列中最高优先级的任务。优先级位图比特位与任务优先级的关系如式（1）所示：

其中：PPRIORITYNUM在系统中默认被设定为31。比特值为0 标识对应优先级下无就绪任务，比特值为1 反之。通过执行CLZ 指令计算位图最高符号位与第1 个1 之间的0 的个数，当得到位图比特值标识为30 时，计算得到任务优先级为1。之后，从g_losPriorityQueueList 数组下标为1 的双向循环队列位置找到队头任务的LosTaskCB，即为时间片到期后发生调度的切入任务的任务描述符。

在MIPS 架构移植过程中，在上下文切换、启动调度时将切入首任务作为系统调度的关键环节，下文展开说明两者在实时内核MIPS 架构移植过程中的适配设计与重要HAL 接口实现。

2.3 上下文切换

任务切换过程主要包括获取就绪队列中最高优先级任务、保存切出任务上下文、恢复切入任务上下文等动作。任务上下文是任务在运行过程中使用的寄存器等资源，在任务切换时需要保存与恢复任务对应的上下文来保障系统的正常运行。依据MIPS架构并对照任务现场的保存与恢复过程，严格遵守O32 ABI 规范并兼顾硬件上下文保存与恢复效率，设计如下代码驻存在任务栈栈底的上下文TaskContext结构体中：

在任务运行中发生函数调用时的局部变量、形参、任务上下文等重要信息都需要存放在任务栈中。LiteOS-M 任务栈为满递减栈，分为主堆栈和任务栈两种类型［25］。主堆栈在引导程序文件中设置，在内存中预留出主堆栈占用空间，并将主堆栈起始地址stack 加载至SP 寄存器中。任务栈大小是在用户创建任务时配置并在运行过程中由动态内存分配函数LOS_MemAllocAlign 分配，之后调用HAL 提供的接口HalTskStackInit 函数实现初始化。该函数接口需结合MIPS 架构设计与实现，MIPS 架构下HAL 任务栈初始化设计示意图如图4 所示。初始化任务栈，首先需要将栈大小空间内存中的内容初始化为OS_TASK_STACK_INIT（即0xCACACACA）、栈顶初始化为溢出标识OS_TASK_MAGIC_WORD（即0xCCCCCCCC）。之后在任务栈底分配任务上下文的内存空间，用于当前任务上下文的保存。

图4 MIPS 架构下任务栈初始化设计Fig.4 Design of task stack initialization under MIPS architecture

HAL 任务栈初始化还需指定初始值赋给任务栈中上下文保存的寄存器域。依据MIPS 架构寄存器功能约定，HAL 任务栈各个寄存器域的初始值设置如表2 所示。

表2 HAL 任务栈上下文初始值设置Table 2 Setting of initial values of HAL task stack context

在MIPS 架构下：任务栈初始化SP 域值为任务栈上下文的地址context，指向驻存在当前栈底的任务上下文结构体TaskContext；函数调用参数寄存器a0 域保存初始值为任务唯一标识号taskID；GP 初始值设定直接读取链接时设置好的GP 寄存器值；RA域初始值设置为HAL 任务退出函数HalSysExit；FP域保存栈帧指针偏移为0x0。除上述寄存器外，其他通用寄存器初始值不重要，因此统一设置为栈空间默认值。初始化CP0 协处理器状态寄存器status 值为ST0_IE|ST0_CU0|ST0_IM，意图在初始时使能中断、协处理器，并允许任何中断源活动时产生异常。任务栈上下文中cause 寄存器域通过读取当下真实的cause 寄存器值完成初始化。初始化EPC 寄存器域为任务入口函数OsTaskEntry，是实现首任务切入的前提。

LosTaskCB 中stackPointer 指针成员变量指向其任务栈的任务上下文，stackTop 成员变量标识任务栈栈顶。g_losTask 是任务调度中关键的全局变量，标识内核相关进程信息，其中runTask 指针成员和newTask 指针成员分别指向当前运行任务的任务描述符和即将发生调度切入任务的任务描述符。通过各自任务描述符找到任务栈指针和栈顶。这些数据结构与任务栈之间的关系如图5 所示，因此内核可以方便地进行任务切换。

图5 上下文切换时任务栈数据结构关系Fig.5 Data structure relation of task stack during context switching

在任务运行过程中，不论是处于事件读写、互斥锁、信号量等资源阻塞的情况下主动发生调度，还是时间片到期触发被动调度或是中断处理结束检查全局调度标识为真值时，都会引发上下文切换。

先保存当前任务上下文，再将指针runTask 指向切入任务硬件上下文，使得切入任务得以顺利执行。实现与上下文结构体相关的HalTaskContextSwitch汇编函数，通过将runTask 指向的任务描述符切换成newTask 指向的任务描述符完成任务切换。任务切换详细设计流程如图6 所示。

图6 任务切换设计流程Fig.6 Design process of task switching

2.4 任务调度启动

系统执行LOS_Start 函数开启调度，获取当前系统优先级最高的就绪任务作为首任务，对该任务只需恢复其任务上下文。

首任务切入是通过调用HAL 接口HalStartToRun实现。在ARM 架构下，HalTskStackInit 函数使用任务入口地址OsTaskEntry 初始化PC 寄存器，因此执行HalStartToRun 时会恢复任务上下文，即依据初始设定的上下文保存值一一对应恢复至寄存器中，依据PC 直接实现首任务的切入。但在MIPS 架构PC寄存器对程序员透明的情况下，不能通过对PC 赋值进行地址跳转，因此无法采用这种方式。

鉴于上述情况，需结合MIPS 架构设计一种首任务切入方式。EPC 作为能够实现地址跳转的协处理器寄存器，通常用来保存MIPS 架构中发生精确异常的地址。EPC 寄存器常见的应用情形是：在中断或异常处理函数执行后，MIPS 架构通常应用ERET 指令从协处理器EPC 寄存器中取出重新执行指令地址，从该地址处继续取指执行。另外，在用户程序需要使用内核提供的服务时会发生系统调用，也由ERET 指令实现从内核态到用户态的切换。因此在设计任务切入时，将任务入口OsTaskEntry 在任务栈初始化时赋值给上下文中的EPC 寄存器域，在调用HAL 接口HalStartToRun 恢复上下文时采用ERET指令实现地址跳转与处理器状态切换，从而起到类似于ARM 架构下的跳转至PC 执行一样的作用，使得设定的任务函数能够执行。

HalStartToRun 函数将切入任务描述符LosTaskCB中的栈指针成员变量stackPointer 加载到SP 寄存器中并恢复任务上下文。最后通过MIPS 的eret 指令实现将EPC 中保存值作为当前程序执行地址，即可通过硬件切入首任务执行入口。另外，还需将任务描述符LosTaskCB 中描述任务状态信息的成员变量taskStatus 修改为运行状态。MIPS 架构下HAL 开启调度并切入首任务的HalStartToRun 核心汇编代码具体如下：

2.5 异常与中断处理

异常处理是CPU 根据内部或外部的异常事件从正常执行的程序转入处理特定的异常服务程序。MIPS 架构将中断归为异常的一种。

结合MIPS 架构与LiteOS-M 内核，设计一种异常与中断处理方法。当异常发生时，首先跳转至固定地址的异常入口general_excption 函数，该函数取出协处理器Cause寄存器中的ExcCode域判断异常类型，并计算偏移量从而跳转入异常向量表中对应的异常处理函数。MIPS 架构下异常向量表Exception_handler 如图7 所示。

图7 MIPS 架构下异常向量表设计Fig.7 Design of exception vector table under MIPS architecture

ExCode 域值为0 标识中断发生。对于中断的处理，内核提供了g_hwiForm 与g_hwiHandlerForm两个函数指针数组来管理。首先，经过上述异常处理步骤后执行中断处理程序HalInterrupt 函数，保存被打断任务的上下文到堆栈中。接着，根据MIPS 架构CP0 协处理器status 寄存器与cause 寄存器掩码CR.IPMASK 与SR.IPMASK 对中断类型进行判定获得中断号，依据中断号从g_hwiForm 中取出对处理例程前后附加定制化处理操作的函数。然后，通过hwiHandlerForm 函数跳转至用户通过LOS_HwiCreate函数注册的中断服务。最后，完成中断处理后恢复现场并返回。

异常与中断的移植工作主要包括异常向量表与中断向量表初始化、异常入口处理函数实现、异常与中断服务函数实现，并针对上文提到的系统异常与中断HAL 接口函数进行MIPS 架构下的设计与实现。

2.6 系统时钟

系统systick 时钟在target_config.h 文件中配置为1 ms。通过实现内核抽象层HalTickStart 函数完成时钟的初始化，包括时钟配置、时钟中断挂接等。由表1 可知，协处理器的Count 与Compare 寄存器配合使用，实现一个处理器内部高精度定时器及定时中断。Compare 寄存器存放的值在写入后保持不变，与自增的Count 寄存器进行比较，两者相等则触发计时器中断。在时钟中断处理函数中，执行系统全局时钟计数的自增、清中断以及判断定时任务是否到期主动发生调度的操作。通过软件写Compare寄存器实现清除CPU 定时器中断的操作。除此之外，系统时钟部分的移植工作还需实现Cycle 与Tick之间的转换、微秒与毫秒之间的转换等辅助函数。

3 系统编译与部署

3.1 硬件平台

实验选取MIPS 架构星载控制终端LS1J 与LS1C 作为硬件平台。LS1J 主频10 MHz，具有32 KB NOR FLASH，8 KB SRAM，集成了中断控制器、定时器、串口控制器、SPI 控制器、AD/DA 等功能模块。LS1C 相较LS1J 资源丰富，能够实现较为复杂的数据处理，主频最高可达240 MHz，具有128 MB FLASH，64 MB SDRAM，包含硬件浮点处理单元，提供丰富的外设接口及片上模块。LS1J 与LS1C 硬件环境搭建分别如图8 与图9 所示。

图8 LS1J 实验环境Fig.8 LS1J experimental environment

图9 LS1C 实验环境Fig.9 LS1C experimental environment

3.2 移植操作

如表3 所示，架构移植工作增加的源码主要在arch 和device 目录下，其 中MIPS 架构的HAL 实现代码位于arch 目录。硬件平台相关BSP 部署在device 目录下，且在device 目录下创建IPC 模块、时钟模块、硬中断模块等系统模块的资源配置文件target_config.h，并创建Makefile 文件定义编译链接规则。最后新增APP 工程目录，调用内核API 接口实现测试用例的设计。

表3 关键移植操作Table 3 Key porting operations

3.3 编译环节

编译工作在Ubuntu 20.04 下进行，使用龙芯提供的mips-mti-elf-gcc 交叉编译平台。

受限于LS1J 片上极小的存储资源，对系统进行函数级裁剪并且在编译过程中调整编译选项实现空间优化。在编译时，使用-ffunction-sections 选项将每个函数放在单独的section 中，并使用-mno-abicalls选项避免输出.abicalls、.cpload 等伪指令。链接ld 选项使用--gc-section 不链接未使用函数生成的section，从而满足硬件空间对映像大小的约束。编译出的LS1J 系统映像各段占用的FLASH 空间情况如表4 所示，满足硬件空间约束。

表4 LS1J 系统映像各段占用的FLASH 空间Table 4 FLASH space occupied by each section of the LS1J system image 单位：Byte

LS1C 因存储资源较大，为便于调试可选择支持栈回溯组件，其编译情况如图10 所示。

图10 LS1C 编译情况Fig.10 LS1C compilation status

将生成的可执行镜像通过龙芯提供的GDB 与EJTAG 等工具分别对应下载到两种开发板中进行调试，在系统启动后，通过串口在上位机putty 工具中输出系统打印信息。

4 验证与测试

经过实际应用后发现LS1J 硬件较为特殊，不支持异常与中断入口动态跳转，致使中断发生后不能跳转至系统用户通过内核系统函数注册的中断服务，只能将处理代码在引导程序中使用汇编指令固化在FLASH 中硬件指定的偏移位置。下面针对龙芯MIPS 架构更具普适性的LS1C 处理器的移植结果进行测试与验证，对系统运行功能、实时性能进行分析与说明。

4.1 系统运行

LOS_KernelInit 函数实现系统启动后内核基础模块的初始化，其中包括内存、中断、时钟、任务、IPC和IDLE 任务创建等，还可通过配置组件实现栈回溯、任务监控等模块的初始化。为了验证系统的基础功能运行的正确性，自定义main 函数设计测试用例如下：

1）创建任务优先级为6 的任务Task 1，任务体循环执行打印输出TaskSampleEntry1，并调用LOS_TaskDelay 主动阻塞延时0.5 s。

2）创建任务优先级为7 的任务Task 2，任务循环执行打印输出TaskSampleEntry2，并调用LOS_TaskDelay 主动阻塞延时2 s。

测试用例运行结果如图11 所示，验证系统的基础功能运行符合预期。由于OpenHarmony LiteOS-M内核优先级数值越低代表优先级越高，Task 1 优先级为6，小于Task 2 的任务优先级7，因此Task 1 会比Task 2 更先抢占CPU。测试用例设计Task 1 时延为0.5 s，Task 2 时延为2 s，因此在Task 2 长时延 中，Task 2 会放弃抢占CPU，发生任务调度执行Task 1，因此Task 1 执行次数较Task 2 更多。

图11 测试用例运行结果Fig.11 Test case running result

4.2 实时性能

任务切换时间和中断响应时间是影响操作系统性能的最重要因素，也是RTOS 实时性能的重要指标。利用高精度系统时钟，分别在测量指标相关执行节点的入口和出口处标记时间戳，时间戳之差即被测操作所需时间［2627］。

上下文切换时间被定义为系统在两个相互独立且相同优先级的就绪任务之间切换所需要的时间［28］，反映了任务切换的速度。这段时间主要包括保存当前被切出任务上下文所需的时间、OS 调度选择新任务的时间以及恢复即将切入新任务上下文所需时间3 个部分，故任务的切换时间取决于系统任务调度策略和上下文结构体大小。

航天轻量型实时终端的具体配置和运行任务数目依据不同的任务需求存在差异，轻量型星载龙芯1系列终端执行的任务通常包括接收和处理遥测数据、向航天器发送指令、数据压缩与加密传输、姿态控制以及异常监控等任务。如图12 所示，任务切换时延检验采用交替悬置与恢复任务的测试方法［29］，主要测试步骤如下：

图12 任务上下文切换时间示意图Fig.12 Schematic diagram of task context switching time

1）创建5 个相等的优先级任务，标记其中任意2 个任务为Task 1 和Task 2。

2）任务在无限循环中执行，记录执行Task 1 最后一条指令的时间T1，Task 2 第一条指令的时间T2，时间戳的差值T2-T1即为上下文切换的时间。

重复100 次实验的测试数据如图13 所示，计算得到系统任务切换时间的均值为0.229 μs、标准差为0.003 5 μs、最大值为0.234 μs。

图13 任务切换时间Fig.13 Task switching time

中断响应时间是从系统收到中断信号到进入中断处理程序的时间。中断响应实时性能检验采用PWM 硬件定时器作为外部时钟源定时产生1 000 μs中断信号，并且屏蔽系统其他中断。主要测试步骤如下：

1）创建一个任务。任务起始时间戳记录为T1，计时器中断设置在1 ms 之后。

2）计时器中断开始执行中断服务例程第一条指令的时间戳记录为T2。

3）重复上述步骤，中断响应时延为T2-T1-1 ms。

重复100 次独立测试，计算得到系统中断响应时延均值为4.73 μs、标准差 为0.61 μs、最大值 为6.01 μs。实验结果如图14 所示。

图14 中断响应时延Fig.14 Interrupt response delay

在同等实验条件下，在VxWorks 实时操作系统中重复上述实时性能测试，对比两者任务切换与中断响应时延的均值，结果如表5 所示。

表5 实时性能测试结果对比Table 5 Comparison of real-time performance test results 单位：μs

由上述实验结果可得，两者实时性能指标的均值相近，OpenHarmony 以LiteOS-M 为内核的轻量型系统实现MIPS 架构移植后能够满足航天实时性应用需求。

5 结束语

本文对轻量型开源鸿蒙操作系统的LiteOS-M内核与MIPS 架构进行介绍与分析，详细阐述了MIPS 架构相关的寄存器、上下文切换、启动引导、中断异常及时钟的核心部分移植方法，并选择作为航天控制终端的MIPS 架构龙芯处理器硬件平台完成了系统功能与性能测试，为国内航空航天领域类瘦终端的星载计算机分布式架构的部署与应用提供了解决方案，对构建星载计算机可靠与安全且自主可控的信息技术体系具有一定参考意义。后续将针对更多型号的MIPS 架构航天控制终端进行系统移植，并对具体硬件平台集成的外设接口进行符合架构的驱动开发，以支持更多的外部设备。