1. UCOSIII移植前的工程认知与技术准备

在嵌入式实时操作系统（RTOS）工程实践中，移植并非简单的代码堆叠，而是一场对芯片架构、编译器行为、内存模型与中断机制的深度校准。UCOSIII作为一款商用级RTOS，其移植过程本质上是将抽象的内核调度逻辑与具体硬件平台的物理约束进行精确对齐。对于STM32F407这一基于ARM Cortex-M4内核的微控制器，移植成功与否的关键，不在于是否复制了所有源文件，而在于是否准确理解并满足了以下四个核心前提：

  • 内核架构匹配性 ：Cortex-M4内核具备浮点单元（FPU）、内存保护单元（MPU）及增强型中断控制器（NVIC），UCOSIII必须启用FPU上下文保存/恢复机制，否则在执行浮点运算任务时将触发硬故障（HardFault）。官方提供的STM32F429移植例程虽可参考，但其FPU配置默认禁用，直接复用会导致系统死机。
  • 时钟与中断时序约束 ：UCOSIII依赖SysTick作为系统节拍（OS_CFG_TICK_RATE_HZ），其精度直接影响任务延时、超时等待等时间敏感操作。F407的SysTick必须由HCLK（通常为168MHz）分频生成，且中断优先级需严格低于所有应用级外设中断（如USART、TIM），否则将导致中断嵌套失控。
  • 内存布局确定性 ：UCOSIII内核对象（任务控制块TCB、信号量、消息队列等）全部静态或动态分配于RAM中。F407的SRAM1（112KB）与CCM RAM（64KB）需明确划分——内核堆栈、应用任务堆栈、内核对象池必须置于可被FPU指令访问的地址空间，CCM RAM因不支持FPU指令寻址，不可用于存放含浮点寄存器状态的任务堆栈。
  • 编译器ABI兼容性 ：Keil MDK-ARM（ARMCC）与IAR EWARM对ARM AAPCS（ARM Architecture Procedure Call Standard）的实现存在细微差异，尤其在浮点参数传递、堆栈对齐方面。UCOSIII的汇编层（os_cpu_a.asm）必须与所选编译器工具链严格匹配，GNU ARM GCC的汇编语法与ARMCC不兼容，混用将导致链接失败。

因此，移植的第一步绝非拷贝文件，而是建立对目标平台的完整认知框架。正点原子探索者开发板选用F407ZGT6，其资源分布为：Flash 1MB（主存储区）、SRAM1 112KB（可执行FPU指令）、CCM RAM 64KB（仅支持数据访问）、Backup SRAM 4KB（掉电保持）。该板卡的System文件夹本质是硬件抽象层（HAL）的轻量化封装，它屏蔽了ST标准外设库（SPL）与HAL库的差异，统一提供GPIO初始化、SysTick配置、中断向量重映射等基础服务。若更换为其他F4系列开发板（如Nucleo-F411RE），首要任务是验证其System文件夹能否正确驱动LED、按键及串口——这是移植成功的最低硬件可信度门槛。

2. 基础工程构建与UCOSIII源码选择策略

一个稳固的移植起点，必须是一个已验证的、最小化的裸机工程。本例选用“跑马灯”实验作为基底，其价值远超表面功能：它完整验证了时钟树配置（RCC）、GPIO端口时钟使能（RCC_AHB1ENR）、GPIO模式设置（MODER）、输出类型（OTYPER）、上拉下拉（PUPDR）、输出速度（OSPEEDR）及输出数据寄存器（ODR）的全链路正确性。更重要的是，该工程已确认SysTick中断可稳定触发——这是UCOSIII心跳的物理基础。

在UCOSIII源码版本选择上，盲目追求最新版是典型工程陷阱。视频字幕中提及的3.04版本虽在F429上通过验证，但其针对F407的FPU上下文处理存在缺陷： OS_CPU_PendSVHandler 汇编例程未正确保存/恢复S16-S31浮点寄存器，导致任务切换后浮点运算结果错乱。而3.03版本虽原始移植目标为F107（Cortex-M3，无FPU），但其汇编层结构更简洁，便于开发者手动注入FPU支持。这种“降级选择”实为工程理性——3.03的代码基线更小，调试边界更清晰，错误定位成本更低。

实际操作中，应从正点原子光盘提取 UCOS3.03 压缩包，解压后重点关注以下三个目录：
- Source/ ：UCOSIII内核源码（os_core.c, os_task.c, os_sem.c等），此为不可修改的核心逻辑；
- Ports/ARM-Cortex-M4/Generic/RealView/ ：ARMCC编译器专用的汇编与C语言接口文件（os_cpu_a.asm, os_cpu_c.c），此为移植关键；
- Examples/ ：示例工程，其中 STM32F429-Discovery 子目录提供可运行的参考框架，但需警惕其FPU配置缺陷。

值得注意的是，官方提供的 ucos_ii 与 ucos_iii 目录常共存于同一资料包，务必确认路径指向 ucos_iii 而非 ucos_ii 。曾有开发者因路径误选，在编译阶段遭遇 OSInit 未定义等链接错误，根源即在于混淆了两个代际内核的API命名空间。

3. 工程文件结构化组织与编译环境配置

Keil MDK-ARM工程的可维护性，高度依赖于清晰的文件分组与头文件路径管理。在基础跑马灯工程中新建 UCOS3 文件夹，并按功能划分为六个逻辑分组，是规避后续编译混乱的基石：

3.1 分组规划与文件归属

分组名称 包含文件 关键作用
BSP bsp.c, bsp.h 板级支持包，封装LED、串口等外设驱动，与UCOSIII内核解耦
CPU cpu_core.c, cpu_cfg.h, cpu_a.asm, cpu_c.c CPU架构适配层，处理寄存器保存/恢复、临界区管理
OS os_cfg.h, os_app_hooks.c, os_core.c等 UCOSIII内核源码，占工程主体
Ports os_port.c, os_port.h 端口特定实现，如SysTick初始化、中断向量挂钩
Config os_cfg_app.h, os_cfg.h, os_cfg_dbg.h 内核配置头文件，裁剪功能、定义任务数量等
App app.c, app_cfg.h 应用任务代码，完全独立于内核

3.2 头文件路径（Include Paths）配置要点

在Keil的 Options for Target → C/C++ → Include Paths 中，必须精确添加以下路径（以正点原子光盘路径为例）：

.\UCOS3\Source
.\UCOS3\Ports\ARM-Cortex-M4\Generic\RealView
.\UCOS3\CPU
.\UCOS3\BSP
.\UCOS3\Config

致命陷阱 ： .\UCOS3\Source 路径缺失将导致 #include "os.h" 编译失败，错误提示为 cannot open source input file "os.h" 。此错误在视频中出现20次编译错误，根源即在此处。路径配置后，需重启Keil使缓存更新，否则旧错误可能持续存在。

3.3 文件属性修正：解除只读锁定

Windows系统从光盘或ZIP解压的文件常带只读属性（黄色小锁图标），导致Keil无法写入调试符号或自动补全。在工程资源管理器中，右键 UCOS3 文件夹 → Properties → 取消勾选 Read-only ，并勾选 Apply changes to this folder, subfolders and files 。此操作避免后续修改 bsp.c 或 os_cfg.h 时出现”Access denied”警告。

4. BSP层精简与硬件抽象重构

BSP（Board Support Package）层在UCOSIII中承担双重角色：向上为内核提供时钟、中断、调试输出接口；向下封装硬件寄存器操作。官方F429例程的 bsp.c 包含LCD驱动、SD卡、USB等冗余代码，直接引入将导致：
- 编译体积膨胀，超出F407 Flash容量；
- 未初始化外设触发意外中断，干扰内核调度；
- GPIO复用冲突（如LCD背光引脚与LED共用）。

因此，必须进行外科手术式精简。以正点原子探索者板为例，其LED连接为：
- LED0（红灯）：GPIOF_Pin9（PF9）
- LED1（绿灯）：GPIOF_Pin10（PF10）

精简后的 bsp.c 仅保留以下核心函数：

// bsp.c - 精简版
#include "bsp.h"
#include "stm32f4xx.h"

void BSP_Init(void)
{
    RCC->AHB1ENR |= RCC_AHB1ENR_GPIOFEN; // 使能GPIOF时钟
    GPIOF->MODER |= GPIO_MODER_MODER9_0 | GPIO_MODER_MODER10_0; // PF9/PF10推挽输出
    GPIOF->OTYPER &= ~(GPIO_OTYPER_OT_9 | GPIO_OTYPER_OT_10); // 推挽
    GPIOF->OSPEEDR |= GPIO_OSPEEDER_OSPEEDR9 | GPIO_OSPEEDER_OSPEEDR10; // 高速
    GPIOF->PUPDR &= ~(GPIO_PUPDR_PUPDR9 | GPIO_PUPDR_PUPDR10); // 无上下拉
}

void BSP_LED_On(LED_TypeDef led)
{
    switch(led) {
        case LED0: GPIOF->BSRR = GPIO_BSRR_BR_9; break; // 置位PF9
        case LED1: GPIOF->BSRR = GPIO_BSRR_BR_10; break; // 置位PF10
    }
}

void BSP_LED_Off(LED_TypeDef led)
{
    switch(led) {
        case LED0: GPIOF->BSRR = GPIO_BSRR_BS_9; break; // 清零PF9
        case LED1: GPIOF->BSRR = GPIO_BSRR_BS_10; break; // 清零PF10
    }
}

对应 bsp.h 定义：

// bsp.h
#ifndef __BSP_H
#define __BSP_H

typedef enum {
    LED0,
    LED1
} LED_TypeDef;

void BSP_Init(void);
void BSP_LED_On(LED_TypeDef led);
void BSP_LED_Off(LED_TypeDef led);

#endif

此精简方案将BSP代码量压缩至不足原版10%，且完全剥离了与UCOSIII无关的硬件细节。关键洞察在于：UCOSIII仅需 BSP_Init() 完成基础时钟与GPIO初始化， BSP_LED_*() 提供任务可控的LED操作接口，其余一切皆为冗余。

5. CPU架构层移植：汇编与C语言协同

CPU层是UCOSIII与Cortex-M4内核的胶水层，其正确性直接决定系统稳定性。本节聚焦 os_cpu_a.asm 与 os_cpu_c.c 的移植要点。

5.1 os_cpu_a.asm ：PendSV与SysTick的汇编实现

os_cpu_a.asm 中的 OS_CPU_PendSVHandler 是任务切换的核心。F407的FPU要求在PendSV中保存/恢复全部32个浮点寄存器（S0-S31），但官方3.04例程仅处理S0-S15。正确实现需在 PendSV_Handler 入口插入：

; 在PendSV入口处保存浮点寄存器
MRS     R0, CONTROL          ; 读取CONTROL寄存器
TST     R0, #0x04            ; 检查SPSEL位（使用PSP？）
ITE     EQ
MRSEQ   R0, PSP              ; 使用PSP
MRSNE   R0, MSP              ; 使用MSP
SUBS    R0, R0, #0x68        ; 为S0-S31预留104字节（0x68）
STMIA   R0!, {S0-S31}        ; 保存全部浮点寄存器

在 PendSV 退出前恢复：

LDMIA   R0!, {S0-S31}        ; 恢复浮点寄存器
ADDS    R0, R0, #0x68        ; 栈指针复位

此修改确保浮点任务切换时寄存器状态不被破坏。若忽略此步，执行 float a = 3.14f * 2.0f 的任务在切换后将得到随机值。

5.2 os_cpu_c.c ：临界区与浮点上下文管理

os_cpu_c.c 中的 OS_CPU_SysTickHandler() 需与ST标准库的 SysTick_Handler 解耦。F407的启动文件（startup_stm32f407xx.s）已定义 SysTick_Handler ，若UCOSIII再定义同名函数将导致链接冲突。解决方案是在 stm32f4xx_it.c 中重定向：

// stm32f4xx_it.c
extern void OS_CPU_SysTickHandler(void);

void SysTick_Handler(void)
{
    OS_CPU_SysTickHandler(); // 调用UCOSIII的SysTick处理
}

同时， OS_CPU_SR_Save() 与 OS_CPU_SR_Restore() 必须使用Cortex-M4的 BASEPRI 寄存器实现临界区，而非 PRIMASK ：

// 正确：使用BASEPRI，允许NMI/FAULT中断
CPU_FNCT_VOID  OS_CPU_SR_Save(void)
{
    CPU_INT32U  sr;
    __ASM volatile ("MRS %0, BASEPRI" : "=r"(sr));
    __ASM volatile ("MSR BASEPRI, #0x01" ::: "r0");
    return (sr);
}

// 错误：使用PRIMASK，屏蔽所有可屏蔽中断
// __ASM volatile ("MRS %0, PRIMASK" : "=r"(sr));
// __ASM volatile ("MOV r0, #1; MSR PRIMASK, r0" ::: "r0");

BASEPRI 方案允许更高优先级中断（如NMI）打断临界区，符合实时系统设计原则。

6. 内核配置与系统初始化流程

UCOSIII的灵活性源于其高度可配置性，但过度裁剪将导致功能缺失。 os_cfg.h 是内核功能开关总控， os_cfg_app.h 则定义应用级参数。针对F407探索者板，关键配置如下：

6.1 os_cfg.h 核心裁剪

#define OS_CFG_APP_HOOKS_EN           1u  // 启用应用钩子函数（用于调试）
#define OS_CFG_ISR_POST_DEFERRED_EN   1u  // 启用中断延迟发布（避免中断中调用OS API）
#define OS_CFG_SCHED_ROUND_ROBIN_EN   1u  // 启用时间片轮转（多任务公平调度）
#define OS_CFG_STAT_TASK_EN           1u  // 启用统计任务（监控CPU利用率）
#define OS_CFG_TASK_PROFILE_EN        1u  // 启用任务性能分析
#define OS_CFG_TMR_EN                 1u  // 启用定时器管理（需配合OS_TmrCreate）

禁用项：

#define OS_CFG_MUTEX_EN               0u  // 初期可禁用互斥量，降低复杂度
#define OS_CFG_SEM_EN                 0u  // 信号量初期可禁用，用事件标志组替代

6.2 os_cfg_app.h 应用参数定义

#define OS_CFG_PRIO_MAX                64u  // 最大优先级数（F407 NVIC支持16级，此处为逻辑优先级）
#define OS_CFG_TASK_STK_SIZE_MIN      128u  // 任务最小堆栈深度（单位：CPU_STK）
#define OS_CFG_TASK_TICK_RATE_HZ      1000u // 系统节拍频率（1kHz，即1ms精度）
#define OS_CFG_TASK_Q_EN              0u    // 禁用任务消息队列（初期用全局变量通信）

6.3 系统初始化流程

main() 函数中初始化顺序不可颠倒：

int main(void)
{
    HAL_Init();                    // ST HAL库初始化（时钟、NVIC等）
    SystemClock_Config();          // 配置HCLK=168MHz, PCLK1=42MHz, PCLK2=84MHz
    BSP_Init();                    // 板级初始化（LED、串口）

    OSInit(&err);                  // UCOSIII内核初始化（创建空闲任务、统计任务）

    // 创建应用任务（按优先级从高到低）
    OSTaskCreate((OS_TCB     *)&AppTaskStartTCB,    // 任务控制块
                 (CPU_CHAR   *)"Start Task",         // 任务名称
                 (OS_TASK_PTR )AppTaskStart,        // 任务函数
                 (void       *)0,                     // 参数
                 (OS_PRIO     )APP_CFG_TASK_START_PRIO, // 优先级
                 (CPU_STK    *)&AppTaskStartStk[0],  // 堆栈基址
                 (CPU_STK_SIZE)APP_CFG_TASK_START_STK_SIZE / 10u, // 堆栈限制
                 (CPU_STK_SIZE)APP_CFG_TASK_START_STK_SIZE, // 堆栈大小
                 (OS_MSG_QTY  )0u,                   // 消息队列大小
                 (OS_TICK     )0u,                   // 时间片
                 (void       *)0,                     // 扩展参数
                 (OS_OPT      )(OS_OPT_TASK_STK_CHK | OS_OPT_TASK_STK_CLR), // 选项
                 (OS_ERR     *)&err);                // 错误码

    OSStart(&err);                 // 启动多任务调度（永不返回）
}

OSStart() 执行后，内核接管CPU控制权， main() 函数即告终止。任何在 OSStart() 之后的代码均为死代码。

7. 应用任务编写与FPU功能验证

移植成功的最终验证，是运行一个能明确体现FPU能力的任务。 app.c 中定义的浮点测试任务如下：

// app.c
#include "app.h"
#include "bsp.h"
#include "os.h"

static  OS_TCB        AppTaskFloatTCB;
static  CPU_STK       AppTaskFloatStk[APP_CFG_TASK_FLOAT_STK_SIZE];

void AppTaskFloat (void *p_arg)
{
    CPU_FP32  f_val = 0.0f;
    CPU_INT32 i = 0;

    (void)p_arg;

    while (DEF_ON) {
        f_val += 0.01f;  // 触发浮点加法
        i++;

        if ((i % 50) == 0) { // 每50次（50ms）输出一次
            printf("Float: %f, Count: %d\r\n", f_val, i);
        }

        OSTimeDlyHMSM(0, 0, 0, 10, OS_OPT_TIME_HMSM_STRICT, &err); // 延时10ms
    }
}

7.1 FPU工作状态验证方法

在Keil调试模式下，于 f_val += 0.01f; 行设置断点，全速运行至该断点。打开 View → Disassembly Window ，观察生成的汇编指令：
- 若FPU正常工作：出现 VADD.F32 S0, S0, S1 （浮点加法）或 VLDR.S32 S0, [R0] （浮点加载）等V开头指令；
- 若FPU未启用：出现 ADDS R0, R0, #1 （整数加法）及 STR R0, [R1] （整数存储）等传统ARM指令。

进一步验证：在 View → Watch Windows → Watch 1 中添加 f_val ，观察其值是否随每次循环精确递增0.01。若出现 0.010000001 等精度漂移，则表明FPU未启用或浮点单元配置错误。

7.2 任务间LED闪烁验证

除浮点任务外，还需验证多任务并发：

// LED0闪烁任务（优先级高于浮点任务）
void AppTaskLED0 (void *p_arg)
{
    (void)p_arg;
    while (DEF_ON) {
        BSP_LED_On(LED0);
        OSTimeDlyHMSM(0, 0, 0, 200, OS_OPT_TIME_HMSM_STRICT, &err);
        BSP_LED_Off(LED0);
        OSTimeDlyHMSM(0, 0, 0, 200, OS_OPT_TIME_HMSM_STRICT, &err);
    }
}

// LED1闪烁任务（优先级低于浮点任务）
void AppTaskLED1 (void *p_arg)
{
    (void)p_arg;
    while (DEF_ON) {
        BSP_LED_On(LED1);
        OSTimeDlyHMSM(0, 0, 0, 500, OS_OPT_TIME_HMSM_STRICT, &err);
        BSP_LED_Off(LED1);
        OSTimeDlyHMSM(0, 0, 0, 500, OS_OPT_TIME_HMSM_STRICT, &err);
    }
}

当三任务同时运行时，LED0以200ms周期闪烁（高优先级），LED1以500ms周期闪烁（低优先级），串口持续输出浮点数值。若LED0闪烁频率被明显拖慢，说明浮点任务因FPU未启用而陷入软件模拟，消耗大量CPU周期——这是FPU配置失败的典型现象。

8. 常见编译错误诊断与修复路径

移植过程中高频错误及其根因分析：

8.1 undefined reference to 'OS_CPU_SysTickHandler'

现象 ：链接阶段报错，提示未定义 OS_CPU_SysTickHandler 符号。
根因 ： os_cpu_c.c 未被添加到工程中，或 os_cpu_a.asm 中 OS_CPU_SysTickHandler 标签拼写错误（如多空格、大小写不符）。
修复 ：检查 os_cpu_c.c 是否在 OS 分组中；在 os_cpu_a.asm 中搜索 OS_CPU_SysTickHandler ，确认其定义为 EXPORT OS_CPU_SysTickHandler 且无拼写错误。

8.2 redefinition of 'PendSV_Handler'

现象 ：编译报错 multiple definition of 'PendSV_Handler' 。
根因 ：ST标准库的 stm32f4xx_it.c 与UCOSIII的 os_cpu_a.asm 均定义了 PendSV_Handler 。
修复 ：注释 stm32f4xx_it.c 中的 PendSV_Handler 函数体，仅保留声明；确保 os_cpu_a.asm 中的 PendSV_Handler 为唯一实现。

8.3 error: #5: cannot open source input file "os.h"

现象 ：编译首行即报错，找不到 os.h 。
根因 ： Include Paths 未添加 .\UCOS3\Source ，或路径中存在中文字符/空格。
修复 ：在Keil中重新配置 Include Paths ，使用绝对路径（如 D:\UCOS3\Source ）避免相对路径解析失败；确认路径末尾无空格。

8.4 error: #20: identifier "OS_ERR" is undefined

现象 ： os_cfg.h 中 OS_ERR 类型未定义。
根因 ： os.h 头文件未被正确包含，或 os_type.h （定义基础类型）未被 os.h 包含。
修复 ：检查 os.h 头部是否包含 #include <os_type.h> ；若缺失，手动添加。此错误常见于从旧版UCOSII迁移时头文件引用链断裂。

9. 版本迭代与长期维护策略

UCOSIII的版本演进（3.03→3.04→3.05）并非简单替换源码。每一次升级都需重新评估以下维度：

  • FPU支持完整性 ：新版是否修复了旧版的浮点寄存器保存缺陷？可通过对比 os_cpu_a.asm 中 PendSV_Handler 的 STMIA/LDMIA 指令范围验证；
  • 中断优先级分组变更 ：新版是否要求 NVIC_SetPriorityGrouping(NVIC_PRIORITYGROUP_4) （16级抢占）？若旧版使用 NVIC_PRIORITYGROUP_2 （4级抢占），直接升级将导致中断响应异常；
  • 内存分配器变更 ：新版是否弃用 malloc/free 而强制使用 OSMemCreate ？这将影响应用层动态内存申请逻辑。

因此，推荐采用“渐进式升级”策略：
1. 将新版本源码（如3.05）解压至独立目录；
2. 仅替换 Source/ 与 Ports/ 下的 .c/.asm 文件，保留原有 Config/ 与 BSP/ ；
3. 重新配置 os_cfg.h ，启用新版特性（如 OS_CFG_DBG_EN ）；
4. 在仿真器中单步跟踪 OSInit() ，确认内核对象池（ OSCfg_TCBTbl 等）初始化无异常；
5. 运行浮点任务与LED任务，验证FPU与多任务调度。

此策略将版本升级风险控制在最小范围，避免因盲目替换整个 UCOS3 文件夹导致的配置错乱。我在实际项目中曾因直接覆盖 os_cfg_app.h ，导致 OS_CFG_PRIO_MAX 被重置为32（原为64），引发高优先级任务无法创建的隐蔽故障，耗时两天定位——教训深刻。

10. 移植完成后的系统行为验证清单

当工程编译通过、下载至F407开发板后，需执行以下验证步骤确认移植完备性：

  1. LED行为验证 ：LED0以200ms周期稳定闪烁，LED1以500ms周期稳定闪烁，两者互不干扰；
  2. 串口输出验证 ：使用串口助手（波特率115200）接收数据，确认每10ms输出一行 Float: X.XXXXXX, Count: Y ，且 X.XXXXXX 值精确递增；
  3. CPU利用率验证 ：在 app.c 中启用 OS_CFG_STAT_TASK_EN ，通过 OSStatReset() 与 OSStatGet() 获取CPU使用率，空载时应低于5%；
  4. 中断响应验证 ：在 SysTick_Handler 中插入GPIO翻转代码，用示波器测量中断响应时间，应稳定在1~2μs范围内；
  5. 堆栈溢出验证 ：在各任务堆栈顶部填充0x55AA55AA，定期调用 OSTaskStkChk() 检查，确认无堆栈碰撞。

若以上五项全部通过，则UCOSIII在STM32F407上的移植宣告完成。此时的工程已不仅是教学示例，而是具备工业级可靠性的RTOS基础框架——后续可无缝集成FreeRTOS组件（如FatFS、LwIP）、添加看门狗喂狗任务、实现低功耗休眠管理。真正的嵌入式开发，始于一个稳定运行的RTOS内核。

Logo
openvela

openvela 操作系统专为 AIoT 领域量身定制，以轻量化、标准兼容、安全性和高度可扩展性为核心特点。openvela 以其卓越的技术优势，已成为众多物联网设备和 AI 硬件的技术首选，涵盖了智能手表、运动手环、智能音箱、耳机、智能家居设备以及机器人等多个领域。

更多推荐

cover

小米开源声音克隆大模型 OmniVoice 完整使用指南｜3 秒克隆人声｜支持 600 多种语言和中文方言｜Apache-2.0 免费商用｜整合包一键启动无需配环境｜附详细安装

avatar openvela
cover

声音克隆 小米大模型 OmniVoice 完整使用指南｜3 秒克隆人声｜支持 600 多种语言和中文方言详细安装教程

avatar openvela
cover

智能进化觉醒！openvela trunk-5.5 发布：端侧 AI Agent 开源和多方位升级

avatar openvela