Processing Modes - Usage Scenarios#

Bluetooth Low Energy (BLE) application examples in the WiSeConnect SDK live under examples/snippets/ble/<example_folder>/ (Silicon Labs wiseconnect GitHub - examples/snippets/ble). Snippets are written for SoC/ACP (M4 + Network Processor (NWP)): sl_wifi_init(), rsi_ble_* callbacks, GAP/GATT/SMP through the WiSeConnect SDK on the M4. Many folders also ship *_ncp.slcp (and sometimes *_uart_ncp.slcp) for EFR32 host + Si91x, sharing the same app.c as *_soc.slcp. There is no examples/snippets/ble/ RCP path using rsi_ble_*; RCP uses Linux + HCI docs. NCP on a custom host may still need HAL porting (NCP mode). This page summarizes SoC/ACP, NCP (EFR vs porting), and RCP.

Related: BLE usage scenarios hub, Processing modes overview, BLE initialization and configuration, BLE architecture.

Typical Use Case 1: SoC/ACP — Full Stack on NWP, Application on M4#

When to Use#

• You run the WiSeConnect SDK on the SiWx917 M4 and want standard BLE API flows (advertising, scanning, connection, GATT, SMP) with low latency and a single-chip design.

• You need a concrete code path to copy from: use any examples/snippets/ble/ project (for example ble_central, ble_secureconnection) as the reference for init order and rsi_ble_* usage.

Implementation Outline#

1. Wireless/BLE stack initialization — Call sl_wifi_init() with a sl_wifi_device_configuration_t that selects WLAN + BLE coexistence (for example SL_SI91X_WLAN_BLE_MODE) and BLE feature bits as required by your product. See BLE initialization and configuration and SoC/ACP mode.

2. Register callbacks — rsi_ble_gap_register_callbacks(), and rsi_ble_gatt_register_callbacks() / rsi_ble_smp_register_callbacks() when needed (same pattern as GAP — usage scenarios).

3. GAP procedures — Start advertising or scanning, connect, then GATT/SMP per GAP — usage scenarios, GATT — usage scenarios, SMP — usage scenarios.

Illustrative Excerpt (SoC)#

The following pattern appears across SoC BLE snippets (names and event IDs vary by project). It is illustrative; full sources are under examples/snippets/ble/<example_folder>/app.c.

#include "rsi_ble_apis.h"

// After sl_wifi_init() and rsi_ble_gap_register_callbacks(...):
  status = rsi_ble_start_scanning();   // central — or rsi_ble_start_advertising() for peripheral
  if (status != RSI_SUCCESS) {
    return;
  }#include "rsi_ble_apis.h"

// After sl_wifi_init() and rsi_ble_gap_register_callbacks(...):
  status = rsi_ble_start_scanning();   // central — or rsi_ble_start_advertising() for peripheral
  if (status != RSI_SUCCESS) {
    return;
  }

SDK example projects: Any folder under examples/snippets/ble/ (see the BLE usage scenarios hub table of examples/snippets/ble/ projects).

See also: SoC/ACP mode, Getting Started with SoC Mode.

Typical Use Case 2: NCP — External Host + Full Stack on NWP#

When to Use#

• The application runs on an external MCU (not the SiWx917 M4); the full BLE stack stays on the SiWx917 NWP.

• You integrate the WiSeConnect host library over UART / SPI / SDIO and implement the host HAL for your board.

Implementation Outline#

NCP mode does not use a separate examples/snippets/ble/ tree that is only host-side; follow the porting sequence and the same rsi_ble_* API names on the host (through the host library), with transport handled by your HAL. For EFR32 + Si91x reference projects that reuse snippet app.c with *_ncp.slcp or *_uart_ncp.slcp, see NCP with EFR.

1. Add the WiSeConnect SDK to the host application and configure build/includes (Add WiSeConnect SDK to Application).

2. Implement the HAL — Serial transfer (sl_si91x_host_spi_transfer(), sl_si91x_host_uart_transfer()), reset/sleep/wake GPIOs, bus interrupts, sl_si91x_host_init() / sl_si91x_host_deinit() (Implement HAL).

3. Port CMSIS-RTOS2 primitives expected by the SDK (Define CMSIS RTOS2 APIs).

4. Initialize the stack from the host per NCP documentation, then call BLE APIs (conceptually the same entry points as SoC: GAP registration, advertise/scan/connect, GATT/SMP).

Reference: NCP mode, Getting Started with NCP Mode, Porting WiSeConnect SDK for an External Host — Overview.

NCP With EFR#

On EFR32 (or listed) host boards, many snippet folders include *_ncp.slcp (SPI to Si91x) or *_uart_ncp.slcp (UART) next to *_soc.slcp, with the same app.c. The .slcp selects host bus components (for example spidrv, sl_si91x_spi_bus) instead of on-chip SoC integration; rsi_ble_* usage matches SoC. Configure the host interface before sl_wifi_init() as required for NCP (BLE initialization and configuration).

See: Getting Started with NCP Mode with EFR32, NCP mode. Not every snippet folder ships every variant; check the folder for .slcp files.

Typical Use Case 3: RCP — Controller on NWP, Host Stack on Linux (HCI)#

When to Use#

• Only the BLE Controller runs on the NWP; the BLE Host (GAP, GATT, L2CAP, SMP) runs on a Linux system.

• You use standard HCI (and typically BlueZ), not the WiSeConnect rsi_ble_* application API on the application processor.

Implementation Outline#

1. Install and load the SiWT917 Linux (RCP) driver; HCI is over SDIO on Si917 RCP (Getting Started with SiWT917 in RCP Mode).

2. Configure BLE through driver/module parameters and kernel options (RCP Mode BLE Configuration).

3. Use the Linux Bluetooth stack (HCI commands/events, BlueZ, D-Bus) for applications; vendor HCI extensions apply for power save and similar features documented in the RCP guides.

WiSeConnect SDK BLE API guides (GAP, GATT) describe SoC/NCP-style rsi_ble_* usage. For RCP, treat HCI and Linux docs as authoritative for the host side.

See also: RCP mode. Raw HCI over UART (different integration) is illustrated in the SDK by bt_stack_bypass (listed on the BLE usage scenarios hub); that is not the same as full RCP Linux bring-up but is related to HCI-oriented development.

Typical Use Case 4: Mode Selection (SoC vs NCP vs RCP)#

When to Use#

• You are choosing how to partition host software vs SiWx917 before locking hardware (external MCU vs Linux vs M4-only).

Guidance#

Use the comparison and decision bullets on Processing modes overview. Summary:

API compatibility (same functional BLE features, different integration): see Processing modes overview - API compatibility.

Wi‑Fi + BLE Coexistence (Cross-Area)#

Samples that combine WLAN and BLE often live under examples/snippets/wlan_ble/ (not under examples/snippets/ble/ alone). For coexistence behavior, performance profiles, and power save across radios, see the BLE usage scenarios hub (Wi‑Fi + BLE note).

APIs Used in This Section#

SDK: Developing with WiSeConnect SDK.