Virtual NCP Architecture Details#

With the CMSIS Stack IPC component enabled, the Connect stack runs within an RTOS task while the Application Framework code runs within a separate RTOS task. This two-task model is also known as the virtual Network Co-Processor architecture (vNCP) because the processing and communication between the two tasks is the same as for the host/NCP architecture. The difference is that instead of running on separate processors and passing messages to each other through the serial port, the application and NCP run on the same processor but in different RTOS tasks. Message passing is handled using RTOS message queues or protected global data structures and is transparent to the application.

By enabling an RTOS Kernel component, the requested kernel code is added to the project. The CMSIS Stack IPC component will automatically start the two required main tasks for the stack to operate:

  • A Connect stack task (higher priority task, 39 by default) responsible for running the Connect stack. This task is responsible for the following operations:

    • Periodically tick the Connect stack by invoking the emberTick() API.

    • Process incoming IPC (inter-process communication) commands from application tasks (if any) and send out a response.

    • Send callback IPC commands (if any) to the application tasks.

    • Attempt whenever possible to suspend itself to allow lower priority application tasks to run.

  • An Application Framework task (lower priority, 38 by default) responsible for running the Application Framework code. This task is responsible for the following operations:

    • Periodically calls emberAfTickCallback() and emberAfTick(), ticking the application and connect components respectively.

    • Run application events.

    • Process incoming callback IPC commands (if any) from the stack task.

    • Attempt whenever possible to suspend itself to allow lower priority custom application tasks to run.

Of course, you can create additional RTOS tasks, but Silicon Labs recommends that you keep the Connect stack task priority as high as possible.

Custom application tasks can call stack APIs freely because the underlying IPC protocol ensures that all stack APIs are thread-safe. Keep in mind that only stack APIs are channeled through the above described vNCP. HAL functions and any MCU-related code might not be thread-safe. You should rely on the documentation for these to verify whether or not they are thread-safe. For non-volatile storage, only NVM3 is supported, because neither simEEv1 nor simEEv2 are thread-safe.