Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/dsyx/docs.silabs.com_zh/llms.txt

Use this file to discover all available pages before exploring further.

Silicon Labs Connect v3.x 支持在 Micrium OS 内核上运行，只需通过 Simplicity Studio 启用单个组件即可实现。Micrium OS 的引入使 Connect Stack 与应用程序框架运行在独立的任务（Task）中，并通过 IPC（进程间通信）机制进行协作，这也称为 vNCP（Virtual Network Co-Processor，虚拟网络协处理器）架构。对于需要严格任务调度、互斥量或信号量等 RTOS 特性的应用场景，启用 Micrium OS 是推荐的方案。

​
快速开始

只需在 Project Configurator > SOFTWARE COMPONENTS 中安装 Micrium Stack IPC 组件，即可将任何 Connect 应用程序转换为在 Micrium OS 上运行的应用程序。安装该组件将自动引入 Micrium OS Kernel 组件作为依赖项。
有关 Micrium OS 的完整文档，请访问 doc.micrium.com。

​
Micrium Stack IPC 配置选项

安装 Micrium Stack IPC 组件后，可在 Component Editor 中配置以下选项：
配置项说明
CPU usage tracking启用后，应用框架编译额外代码，使调试工具可获取 OS 扩展调试信息
Connect Task call stack sizeStack 任务使用的调用栈大小（字节）
Application Framework Task call stack size应用程序框架任务使用的调用栈大小（字节）
Max callback queue size从 Stack 任务到应用程序任务同时支持的最大回调消息数
Application Task (N)（共 3 个）自定义应用程序任务（最多三个），可分别配置调用栈大小和优先级
启用 Micrium OS Kernel 还会影响其他组件的行为。例如，CLI Core 组件将为其自身创建一个独立的 Micrium 任务（通常情况下它是从主 while 循环中调用的）。

​
vNCP 双任务架构

启用 Micrium Stack IPC 组件后，系统将运行两个主要任务：

Connect Stack Task

优先级：较高（默认为 6）负责：
  • 调用 emberTick() API 定期 tick Connect Stack
  • 处理来自应用程序任务的 IPC 命令并发出响应
  • 向应用程序任务发送回调 IPC 命令
  • 尽可能挂起自身以让优先级较低的任务运行

Application Framework Task

优先级：较低（默认为 7）负责：
  • 定期调用 emberAfTickCallback() 和 emberAfTick() 以 tick 应用程序和 Connect 组件
  • 运行应用程序事件
  • 处理来自 Stack 任务的回调 IPC 命令
  • 尽可能挂起自身以让优先级较低的自定义任务运行

​
自定义应用程序任务

除了两个主要任务外，开发者还可以启用最多三个自定义应用程序任务，对于每个任务可以指定：
  • 调用栈大小
  • 任务优先级
自定义应用程序任务可以自由调用 Stack API，因为底层 IPC 协议确保所有 Stack API 都是 thread-safe 的。
HAL 函数和 MCU 相关代码可能不是 thread-safe 的，应根据文档验证后使用。对于非易失性存储，仅支持 NVM3；simEEv1 和 simEEv2 均不是 thread-safe 的，不可用于 Micrium OS 场景。

​
裸机模式与 Micrium OS 模式对比

  • 单线程，所有代码在主循环中顺序执行
  • Connect Stack 通过 emberTick() 在主循环中轮询
  • 不支持互斥量、信号量或任务间队列
  • 使用 Connect 事件框架（最多 256 个事件）进行延迟/定时任务调度
  • 内存占用更小，适合资源极度受限的场景
即使启用了 Micrium OS，Connect 事件框架仍然可用。事件只需在 RAM 中为每个事件分配 6 字节的 EmberEventControl，而 Micrium OS 任务使用大量内存，因此只能创建少量 RTOS 任务。建议将两者结合使用：复杂的并发逻辑使用 RTOS 任务，简单的定时/延迟逻辑使用事件框架。

​
架构说明

vNCP 架构之所以称为”虚拟 NCP”，是因为两个任务间的处理和通信方式与 Host/NCP 架构完全相同——区别仅在于两个任务运行在同一处理器上而非通过串行端口通信。消息传递通过 Micrium 消息队列或受保护的全局数据结构处理，对应用程序完全透明。 
┌─────────────────────────────────────────┐
│           同一 EFR32 处理器              │
│                                         │
│  ┌──────────────────┐  IPC/消息队列      │
│  │ Connect Stack    │◄──────────────►   │
│  │ Task (优先级 6)   │                   │
│  └──────────────────┘                   │
│                                         │
│  ┌──────────────────┐                   │
│  │ App Framework    │                   │
│  │ Task (优先级 7)   │                   │
│  └──────────────────┘                   │
│                                         │
│  ┌──────────────────┐                   │
│  │ Custom App Task 1│  （最多 3 个）      │
│  │ Custom App Task 2│                   │
│  │ Custom App Task 3│                   │
│  └──────────────────┘                   │
└─────────────────────────────────────────┘
Silicon Labs 建议将 Connect Stack 任务的优先级保持尽可能高，以确保协议栈能够及时处理无线电和网络事件。不建议降低其默认优先级（6）。

Build docs developers (and LLMs) love

Get started for freeTalk to us