RISC-V平台鸿蒙LiteOS-M内核移植实战：从CH32V307硬件适配到任务调度

1. 项目概述与核心思路

最近在折腾一块沁恒微电子的CH32V307开发板，这是一颗基于RISC-V V4内核的通用MCU，性能不错，外设也丰富。手头正好有个项目想试试鸿蒙OS LiteOS-M内核，看看在RISC-V平台上跑起来是什么感觉。网上关于ARM Cortex-M移植RTOS的资料汗牛充栋，但针对RISC-V，尤其是具体到某款芯片的实战细节，能找到的完整参考并不多。这次移植，我选择从鸿蒙OS的官方LiteOS-M内核源码开始，在MounRiver Studio（MRS）这个沁恒自家的IDE里完成整个搭建和适配过程。

这个项目本质上是一次“裸机”到“多任务”的跨越。对于嵌入式开发者而言，移植一个实时操作系统（RTOS）到新平台，核心目标就一个：让操作系统的调度器接管CPU，并能正确、高效地在多个任务（线程）之间切换。听起来简单，但里面涉及到底层硬件架构的深刻理解，特别是中断、异常、寄存器上下文这些最基础也最关键的机制。RISC-V虽然指令集开源、设计优雅，但其特权架构、中断处理方式与ARM Cortex-M有显著不同，这就成了移植过程中需要重点攻克的技术点。

我选择CH32V307和鸿蒙LiteOS-M的组合，有几个考虑。首先，V307是RISC-V V4内核，支持硬件单精度浮点，中断嵌套和硬件压栈机制也比早期的V3内核更完善，作为学习对象很有代表性。其次，鸿蒙OS LiteOS-M内核代码结构清晰，相对轻量，且官方源码托管在码云，获取方便。最后，MRS IDE对WCH的RISC-V芯片支持良好，工具链、调试器集成度高，能省去很多环境配置的麻烦。整个过程，我会带你从零开始，克隆源码、建立工程、分析关键移植点，最后让系统成功跑起来，并分享其中踩过的坑和总结的经验。

2. 开发环境搭建与工程初始化

工欲善其事，必先利其器。在开始代码层面的折腾之前，一个稳定、顺手的环境是成功的一半。

2.1 软件工具链准备

核心的软件就两样：MounRiver Studio (MRS)和RISC-V GCC 工具链。幸运的是，MRS安装包已经内置了适配WCH RISC-V芯片的GCC工具链（通常是基于xPack RISC-V GCC），无需我们再单独下载和配置。你只需要从沁恒官网下载最新版的MRS安装包，一路“下一步”安装即可。安装完成后，启动MRS，其界面风格与Eclipse类似，对于用过Keil、IAR或者STM32CubeIDE的开发者来说应该能很快上手。

这里有个注意事项：确保你的MRS版本与CH32V307的SDK包版本匹配。有时候新版的SDK可能需要新版的MRS才能完全支持。安装完MRS后，建议通过其内置的“Package Manager”检查并安装最新的CH32V307设备支持包、芯片闪存编程算法等。这一步能避免后续编译、下载时出现莫名其妙的错误。

2.2 获取鸿蒙LiteOS-M内核源码

鸿蒙OS的LiteOS-M内核源码托管在Gitee上，这是一个专为资源受限的微控制器设计的轻量级内核。我们不需要下载整个庞大的OpenHarmony项目，只需要内核部分。

1. 克隆仓库：打开MRS，不需要先创建工程。找到其“Git Repositories”视图（如果没找到，可通过 Window -> Show View -> Other... -> Git -> Git Repositories 打开）。点击“Clone a Git Repository”，在URI中填入：https://gitee.com/openharmony/kernel_liteos_m.git。按照提示选择分支（通常用master或最新的稳定分支），并指定一个本地目录来存放源码。这个过程相当于执行了git clone命令。
2. 源码结构预览：克隆完成后，在项目资源管理器里导入这个仓库的本地目录，先别急着往工程里拖。我们快速浏览一下核心目录：
   • kernel/include/: 内核头文件，包含任务、内存、队列、信号量等核心数据结构和API声明。
   • kernel/src/: 内核源码实现，是我们移植时需要重点关注的。
   • utils/: 一些通用工具函数，如标准库适配、链表等。
   • arch/:这是移植的“心脏”。里面通常按架构分目录，比如arm/,csky/,risc-v/。我们需要重点关注risc-v/目录下的内容，但官方可能还没有完全适配我们特定的V4内核，所以这里是我们需要动手修改和适配的主要战场。

2.3 创建基础工程与源码整合

接下来，我们在MRS中为CH32V307创建一个裸机工程作为起点。

1. 新建工程：File -> New -> C/C++ Project。选择“MounRiver RISC-V C Executable Project”。在下一步中，输入工程名（例如CH32V307_LiteOS），选择正确的芯片型号（CH32V307），工具链默认即可。这一步MRS会自动生成一个包含启动文件（startup_ch32v30x.s）、链接脚本（.ld文件）、系统初始化代码和主函数框架的工程。
2. 导入内核源码：不要简单地复制粘贴。我推荐的方法是，在工程目录下（例如与User/目录平级），创建一个kernel/文件夹。然后，将之前克隆的kernel_liteos_m源码目录下的kernel/,utils/,arch/等核心文件夹，有选择地复制到我们工程的kernel/目录下。注意，arch/目录下我们可能只保留risc-v/并对其进行修改，其他架构的可以先删除以避免干扰。
3. 添加源码到工程构建：在MRS的“Project Explorer”视图中，右键点击你的工程，选择“Import...”。然后选择“File System”，找到你刚才放置kernel/目录的路径，将必要的.c和.s文件导入到工程中。更高效的方法是，在工程上右键 -> “Properties” -> “C/C++ Build” -> “Settings” -> “Tool Settings” -> “GNU RISC-V Cross C Compiler” -> “Includes”。在这里的“Include paths (-I)”中，直接添加我们内核源码的头文件路径，例如../kernel/include，../kernel/src，../arch/risc-v/include等。这样，编译器就能找到所有头文件了。
4. 排除非必要文件：内核源码可能包含一些我们当前平台不需要的组件（例如某些架构的汇编文件、未启用的功能模块）。在MRS的工程视图中，右键点击不需要参与编译的目录或文件，选择“Resource Configurations” -> “Exclude from Build...”。在弹出的对话框中，选择“Debug”和“Release”（或你当前使用的构建配置），点击“OK”。这个文件或目录就会变灰，表示已被排除在构建之外。这个操作非常有用，可以保持工程树的清晰，并避免编译错误。

实操心得：在添加头文件路径时，务必注意路径的相对关系。我建议使用相对于工程根目录的路径（如../kernel/include），而不是绝对路径，这样工程拷贝到其他电脑上也能正常编译。另外，先进行最小化集成，即只添加最核心的内核调度、任务管理相关源码，等基础跑通后，再逐步加入内存管理、软件定时器、IPC等组件，这样可以有效定位问题。

3. RISC-V架构关键点深度解析

在动手修改代码之前，我们必须对CH32V307所使用的RISC-V V4内核有一些关键了解。这些知识点是移植任何RTOS到该平台的基石，理解不到位，后面就会处处碰壁。

3.1 中断与异常处理机制

这是与ARM Cortex-M差异最大，也最需要厘清的地方。

1. 非统一入口的中断向量表：ARM Cortex-M有一个固定的中断向量表，表项是中断服务函数（ISR）的地址。RISC-V（特指WCH的实现）的中断控制器（PFIC）也使用向量表，但表项的内容可以是跳转指令或函数地址。对于V4内核（如V307），我们可以配置为“向量模式”，即向量表里直接存放ISR的函数地址，这样中断发生后，硬件能直接跳转到对应的函数，减少了指令跳转开销。这个配置通常在启动代码或系统初始化时完成。
2. 硬件压栈与关闭：WCH的RISC-V内核支持硬件自动压栈。发生中断时，硬件会自动将一部分寄存器（主要是整数caller-saved寄存器，如x1(ra), x5-x7, x10-x17等）保存到当前任务的堆栈中。这听起来是个好事，能加速中断响应。但是，在RTOS移植中，我们通常需要关闭这个功能！原因在于，任务切换的本质是人为保存和恢复完整的CPU上下文（所有需要保存的寄存器）。如果硬件帮我们压了一部分，我们自己又压了另一部分，就会导致上下文保存的不完整和混乱，任务恢复时必然出错。因此，在系统初始化早期，我们需要通过配置PFIC的相关寄存器，明确关闭硬件压栈功能。后续所有的上下文保存与恢复，都由我们自己的汇编代码精确控制。
3. 中断嵌套与优先级：V4内核支持中断嵌套，并且硬件压栈深度也支持多级（例如三级）。即使我们关闭了硬件压栈，其中断嵌套的优先级机制仍然是有效的。在RTOS中，SysTick定时器中断和用于任务切换的软中断（或PendSV）的优先级需要仔细设置。通常，SysTick中断的优先级应设置为最低之一（但高于任务），以确保时间片轮转的公平性；而任务切换中断的优先级可能需要根据具体OS的设计来定。
4. 关键CSR寄存器：
   • mstatus(机器状态寄存器)：其中的MIE位控制全局中断使能。MPIE位在中断发生时，用于保存进入中断前的MIE值。MPP位表示中断发生前的特权级（机器模式或用户模式）。我们的OS通常全程运行在机器模式（MPP=11）。
   • mepc(机器异常程序计数器)：当异常（包括中断）发生时，mepc会被硬件自动更新为中断发生时那条指令的地址（对于精确中断）或下一条指令的地址（对于某些不精确中断，WCH通常为精确中断）。mret指令执行时，CPU会跳转到mepc指向的地址继续执行。任务切换的核心技巧之一，就是通过修改即将运行任务的mepc，让mret后能跳转到该任务的入口点。
   • mcause/mtval: 用于诊断异常原因和附加信息，在复杂的错误调试时有用。

3.2 寄存器上下文详解

RISC-V有32个通用整数寄存器（x0-x31）和32个浮点寄存器（f0-f31，V4内核支持）。任务切换时，我们需要保存和恢复哪些呢？

• 必须保存的寄存器（Caller-Saved）：按照RISC-V调用约定，函数调用时，如果子函数会修改x5-x7, x10-x17, x28-x31这些寄存器，它需要负责保存它们（通常压栈）。对于中断/任务切换这个“超级函数调用”，我们需要保存所有可能被破坏的寄存器。简化的原则是：除了x0（恒为0）、x2（sp，堆栈指针由我们显式管理）、x3（gp，全局指针，通常不变）和x4（tp，线程指针，可能由OS使用）外，其他所有整数寄存器在任务切换时都应被视为需要保存的上下文。为了保险和通用，很多RTOS实现选择保存除x0外的所有整数寄存器。
• 浮点寄存器：如果任务使用了浮点运算（V4内核支持），那么在切换使用了浮点的任务时，也必须保存和恢复f0-f31这32个浮点寄存器，以及浮点状态寄存器fcsr。这是一个不小的开销，因此有些OS会采用“惰性保存”策略，即直到任务第一次使用浮点时，才保存浮点上下文。
• CSR寄存器：除了mepc，mstatus也是上下文的一部分，因为它包含了中断使能状态等信息。通常也需要保存。

生活类比：你可以把CPU寄存器想象成一个工作台的桌面。每个任务（工匠）上台工作时，都会把自己的专用工具（寄存器值）从工具箱（任务堆栈）里拿出来摆好。任务切换时，当前工匠必须把桌上所有自己的工具收回工具箱（保存上下文），然后下一位工匠再把自己的工具摆出来（恢复上下文）。硬件压栈就像有个助理，在工匠A被打断时，自动帮他收起了几件常用工具，但助理不知道工匠A所有工具的摆放习惯，反而可能让工匠A回来时找不到某些特殊工具。因此，我们宁愿关掉这个“热心”的助理，让每个工匠自己完整地收拾和布置桌面。

3.3 任务堆栈初始化设计

任务堆栈不仅仅是一块内存，它更是一个精心设计的“上下文模板”。当创建一个新任务时，我们需要手动初始化它的堆栈，使其看起来就像这个任务曾经运行过，然后被中断了一样。这样，当调度器第一次切换到该任务时，通过恢复这个“伪造”的上下文，就能无缝地开始执行任务函数。

初始化的堆栈顶部（高地址）通常会预先放置好一系列数据，模拟一次中断压栈后的场景：

1. 程序计数器（PC）：即任务的入口函数地址。在RISC-V中，这对应于mepc寄存器的值。堆栈初始化时，我们需要把这个地址放在合适的位置，将来恢复上下文时，会将它加载到mepc，mret后CPU就从这里开始执行。
2. 状态寄存器：mstatus的初始值，通常设置为允许中断（MIE=1）且处于机器模式（MPP=11）。
3. 通用寄存器：除了sp（堆栈指针会指向这个初始化区域的合适位置）和gp等，其他寄存器可以初始化为0或特定的值（例如，可以给某些寄存器赋初值用于调试）。
4. 参数：如果任务入口函数带参数，也需要按照调用约定（通常a0, a1寄存器）在堆栈的对应位置放置好参数值。
5. 返回地址：虽然任务函数通常不会返回，但为了符合调用规范，往往也会在堆栈中放置一个“任务退出处理函数”的地址到ra (x1) 寄存器对应的位置。如果任务函数意外返回，会跳转到这个处理函数，进行任务删除等清理工作。

在LiteOS-M的代码中，你会看到一个类似于LosTaskContext的结构体，它定义了上下文保存的顺序。在arch/risc-v/目录下的汇编文件里，会有一个HalTaskContextInit或类似的函数，它接收任务函数指针、堆栈基址和大小，然后按照上述逻辑填充堆栈空间，并返回初始化后的当前堆栈指针位置。这个指针会被保存在任务控制块（TCB）中。

4. 鸿蒙LiteOS-M内核移植实战

有了前面的理论铺垫，我们现在可以深入到具体的代码层面，看看如何让LiteOS-M在CH32V307上“动”起来。

4.1 启动流程与硬件适配层（HAL）实现

操作系统的启动是一条精密的链条，从芯片上电复位到第一个任务开始执行，每一步都不能出错。

1. 复位向量与启动文件：CH32V307的启动文件（如startup_ch32v30x_D8C.s）由MRS自动生成。它定义了复位向量（Reset_Handler），在这里我们需要完成最基本的硬件初始化：关闭看门狗、配置系统时钟（HSE/HSI/PLL）、初始化RAM（如果需要）。然后，最关键的一步是跳转到C语言的main函数，或者更准确地说，跳转到LiteOS-M的启动入口。
2. 主函数与内核初始化：在main.c中，我们不应该再写裸机的while(1)循环了。取而代之的是调用LiteOS-M的初始化序列。

   #include "los_init.h" int main(void) { /* 1. 硬件外设初始化：串口、GPIO、时钟等，用于调试和系统节拍 */ BoardEarlyInit(); // 自定义函数 /* 2. 内核初始化 */ LOS_KernelInit(); /* 3. 创建初始任务（例如一个LED闪烁任务或Shell任务） */ CreateInitTask(); // 自定义函数 /* 4. 开启内核调度，永不返回 */ LOS_Start(); /* 程序不会执行到这里 */ while (1); }

   LOS_KernelInit()会初始化内核的核心数据结构：任务池、就绪队列、软件定时器、内存池等。它会调用底层硬件抽象层（HAL）的初始化函数。
3. 硬件抽象层（HAL）移植：这是移植工作的核心区域，对应arch/risc-v/目录。我们需要实现或修改以下几个关键文件：
   • los_context.c / .s：包含上下文初始化(HalTaskContextInit)、任务切换(HalTaskSwitch)的汇编实现。这是最核心的代码，需要根据我们之前分析的寄存器列表来编写。通常需要参考官方已有的其他RISC-V架构实现（如gd32vf103），但必须根据WCH V4内核的特点进行调整，特别是关闭硬件压栈后，完整的寄存器保存/恢复顺序。
   • los_interrupt.c：中断管理。需要实现系统中断的使能/禁止(HalIntLock/HalIntUnlock)、中断控制器初始化、以及系统节拍定时器（SysTick）的配置。CH32V307的SysTick可能由某个通用定时器（如TIM2）模拟，或者使用RISC-V标准的mtime/mtimecmp寄存器（如果内核支持）。我们需要在这里初始化一个定时器，使其以固定的频率（例如1ms）产生中断，并在中断服务函数中调用LOS_TickHandler()，为内核提供时间基准。
   • los_dispatch.s：可能包含任务调度开始的汇编入口(HalStartToRun)。这个函数负责从内核初始化状态，切换到第一个最高优先级任务的上下文。它需要加载第一个任务的堆栈指针，设置好mepc和mstatus，然后执行mret“跳入”任务。
   • los_hw.c：其他硬件相关初始化，如FPU（浮点单元）的使能。

注意事项：在编写汇编代码时，务必注意RISC-V的ABI（应用二进制接口）规范，即寄存器的调用约定。保存和恢复寄存器的顺序必须与HalTaskContextInit中初始化堆栈时的顺序严格一致。一个常见的调试技巧是，在任务切换的汇编代码里，在保存和恢复上下文前后，通过操作某个GPIO引脚输出高低电平，然后用示波器观察，可以清晰地看到任务切换的执行时间和频率。

4.2 系统节拍定时器与任务切换驱动

操作系统的心跳和任务切换的触发器都需要硬件定时器来驱动。

1. SysTick定时器配置：以CH32V307的通用定时器TIM2为例。

   // 在 los_interrupt.c 的 HalTickInit 函数中 void HalTickInit(void) { RCC_APB1PeriphClockCmd(RCC_APB1Periph_TIM2, ENABLE); TIM_TimeBaseInitTypeDef TIM_TimeBaseStructure; TIM_TimeBaseStructure.TIM_Period = SystemCoreClock / 1000 - 1; // 1ms中断 TIM_TimeBaseStructure.TIM_Prescaler = 0; TIM_TimeBaseStructure.TIM_ClockDivision = TIM_CKD_DIV1; TIM_TimeBaseStructure.TIM_CounterMode = TIM_CounterMode_Up; TIM_TimeBaseInit(TIM2, &TIM_TimeBaseStructure); TIM_ITConfig(TIM2, TIM_IT_Update, ENABLE); NVIC_InitTypeDef NVIC_InitStructure; NVIC_InitStructure.NVIC_IRQChannel = TIM2_IRQn; NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 15; // 设置为最低优先级之一 NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0; NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE; NVIC_Init(&NVIC_InitStructure); TIM_Cmd(TIM2, ENABLE); }

   在TIM2的中断服务函数中，清除中断标志，并调用LOS_TickHandler()。
2. 任务切换触发（软中断）：LiteOS-M内部在需要任务切换时（如任务延时到期、更高优先级任务就绪），会触发一个“软中断”或“可挂起中断”。在ARM Cortex-M上，这是PendSV。在RISC-V上，我们可以利用一个未使用的软件中断（例如，WCH PFIC可能支持一个软件触发的中断源），或者通过设置一个标志，在SysTick中断退出前进行检查并执行上下文切换。更标准的方式是使用RISC-V的msoftcallCSR或自定义一个软件中断。
   • 在los_dispatch.c或相关文件中，会有一个HalTaskSchedule或ArchIntLock函数，它最终需要触发一个上下文切换。
   • 在中断处理汇编中，我们需要判断是否是任务切换中断。如果是，则不是返回到被中断的任务，而是执行上下文切换代码：保存当前任务上下文到其TCB，从下一个任务的TCB中恢复上下文，然后返回（mret）到新任务。

实操心得：调试阶段，务必先确保SysTick定时器中断能正常进入，并且LOS_TickHandler能被稳定调用。可以在中断里翻转一个LED灯，用逻辑分析仪看波形是否精准为1ms。这是系统能够进行时间片轮转的基础。任务切换的调试更为复杂，可以创建2-3个简单任务（比如分别控制不同的LED以不同频率闪烁），通过观察LED的闪烁规律是否符合预期，来判断任务调度是否正常。

4.3 链接脚本与内存布局调整

默认的链接脚本（.ld文件）是为裸机程序设计的，可能没有考虑RTOS的需求。我们需要检查并可能修改它。

1. 堆栈分离：在RTOS中，每个任务有自己的堆栈，而中断也可能有独立的中断栈。裸机链接脚本通常只定义了一个_stack符号作为主堆栈。我们需要确保这个主堆栈空间足够大，用于内核初始化以及作为中断栈（如果我们没有启用独立的中断栈）。同时，在代码中，我们通过malloc或静态数组的方式为每个任务分配堆栈空间，这些空间位于.bss或.data段，链接脚本需要为这些段预留足够的RAM。
2. 堆（Heap）管理：LiteOS-M有自己的动态内存管理模块（如LOS_MemAlloc），它会在初始化时从一块连续的内存池（heap）中划分。我们需要在链接脚本中定义一块专供内核堆管理使用的内存区域，或者直接使用标准libc的堆（_heap）。更常见的做法是，在board.c中定义一个大的静态数组作为堆内存池，然后将其地址和大小传递给LOS_MemInit。

   // 在 board.c 中 UINT8 g_ucMemPool[1024 * 10]; // 10KB的内存池 // 在 main 函数初始化时 LOS_MemInit(g_ucMemPool, sizeof(g_ucMemPool));

3. 代码与数据段：检查链接脚本中.text（代码）、.rodata（只读数据）、.data（已初始化数据）、.bss（未初始化数据）的地址和大小是否符合芯片的Flash和RAM映射。CH32V307的RAM可能有多块（如高速RAM和备份RAM），需要根据数据特性合理放置。例如，将频繁访问的数据（如任务就绪表）放到高速RAM。

修改链接脚本后，编译生成的map文件（.map）是重要的分析工具。通过查看map文件，你可以确认各个段、变量、堆栈的地址和大小是否符合预期，避免内存溢出或冲突。

5. 调试、问题排查与优化心得

移植过程几乎不可能一帆风顺，遇到问题是常态。这里记录几个我踩过的坑和解决方法。

5.1 常见问题与排查技巧

5.2 性能优化与进阶技巧

当系统基本跑通后，可以考虑一些优化措施：

1. 中断响应优化：对于极其注重实时性的应用，可以考虑启用中断栈。为中断分配一块独立、固定大小的堆栈，这样中断处理就不会占用被中断任务的堆栈空间，既能保护任务堆栈，也能避免任务堆栈污染对中断的影响。这需要在启动时初始化中断栈指针（mscratch寄存器是一个常用的选择），并在中断入口汇编中切换SP。
2. FPU惰性保存：如果系统中有大量任务，但只有少数使用浮点，为每个任务都保存/恢复32个浮点寄存器开销巨大。可以实现惰性FPU上下文切换：当任务切换时，如果上一个任务使用了FPU（通过一个标志位记录），才保存其FPU上下文；同样，只有当下一个任务需要使用FPU时，才恢复其FPU上下文。这需要在首次FPU访问异常中处理上下文的延迟加载。
3. Tickless 模式：当系统处于空闲状态时，如果没有任务需要运行，可以让SysTick定时器完全停止，或者进入深度睡眠模式，以极低的功耗等待下一个外部中断（如按键、串口数据）唤醒。这需要修改LOS_TickHandler和空闲任务，在进入空闲前计算下一个任务唤醒的时间点，并动态调整定时器。

5.3 调试工具与手段

1. printf调试法：虽然原始，但在嵌入式开发中永远有效。确保一个稳定的串口输出，在关键路径上打印信息（如任务切换、中断进入退出）。注意，在中断服务函数中打印要谨慎，避免耗时过长。
2. 调试器（Debugger）：MRS集成了GDB调试器，配合WCH-Link，可以进行单步、断点、查看寄存器/内存、反汇编等操作。这是分析复杂问题（如HardFault）的利器。学会查看调用栈（Call Stack）、反汇编窗口，以及监控关键变量。
3. 逻辑分析仪/示波器：对于时序相关的问题（如中断响应延迟、任务切换时间），没有比硬件工具更直观的了。用几个GPIO引脚输出特定的脉冲信号来标记关键事件的开始和结束，然后用逻辑分析仪测量时间间隔。
4. 系统状态查看：可以扩展LiteOS-M的shell组件，或者自己实现一个简单的命令解析器，通过串口输入命令来查看当前所有任务的状态（优先级、堆栈使用率、运行时间等）、内核对象（信号量、队列）的信息。这对于系统运行时的监控和问题定位非常有帮助。

移植完成后，你得到的不仅仅是一个能在CH32V307上运行的鸿蒙LiteOS-M，更是一套对RISC-V内核和RTOS原理的深刻理解。这套理解可以平移到其他RISC-V MCU（如GD32VF103、ESP32-C3）或其他RTOS（如FreeRTOS、RT-Thread）的移植工作中去。后续，你可以基于这个基础，进一步探索鸿蒙OS的更多组件，如文件系统（FATFS）、网络协议栈（LwIP）、图形界面（LittlevGL）的移植与集成，构建更复杂的物联网终端应用。