Bluetooth Low Energy Remote Procedure Call¶
The nRF Connect SDK supports Bluetooth® Low Energy (LE) stack serialization. The full Bluetooth LE stack can run on another device or CPU, such as the nRF5340 DK network core using Remote procedure call library (nRF RPC).
The Bluetooth: Host for nRF RPC Bluetooth Low Energy sample is designed specifically to enable the Bluetooth LE stack functionality on a remote MCU (for example, the nRF5340 network core) using the Remote procedure call library (nRF RPC). You can program this sample to the network core to run standard Bluetooth Low Energy samples on nRF5340. You can use either the SoftDevice Controller or the Zephyr Bluetooth LE Controller for this sample.
To use the Bluetooth LE stack through nRF RPC, an additional configuration is needed.
When building samples for the application core, enable the
CONFIG_BT_RPC_STACK to run the Bluetooth LE stack on the network core.
This option builds Bluetooth: Host for nRF RPC Bluetooth Low Energy automatically as a child image.
For more details, see: Building and programming a sample.
Open a command prompt in the build folder of the application sample and enter the following command to build the application for the application core, with Bluetooth: Host for nRF RPC Bluetooth Low Energy as child image:
west build -b nrf5340dk_nrf5340_cpuapp -- -DCONFIG_BT_RPC_STACK=y
Some configuration options related to Bluetooth LE must be the same on the host (network core) and client (application core). Set the following options in the same way for the Bluetooth: Host for nRF RPC Bluetooth Low Energy and application core sample:
To keep all the above configuration options in sync, create an overlay file that is shared between the application and network core. Then, you can invoke build command like this:
west build -b board -- -DCONFIG_OVERLAY=my_overlay_file.conf
This library does not define a new API. Instead, it uses Zephyr’s Bluetooth API. The nRF Connect SDK currently supports serialization of the following:
The behavior of the implementation is almost the same as Zephyr’s with the following exceptions:
The latency is longer because of the overhead for exchanging messages between cores.
bt_gatt_cancel()function is not implemented.
flagsfield of the
bt_gatt_subscribe_paramsstructure is atomic, so it cannot be correctly handled by the nRF RPC. The library implements the following workaround for it:
flagsare sent to the network core when either the
bt_gatt_resubscribe()function is called. This covers most of the cases, because the
flagsare normally set once before those functions calls.
If you want to read or write the
flagsafter the subscription, you have to call