CONFIG_BT_RPC_STACK on a custom board

RE: CONFIG_BT_RPC_STACK on a custom board

Yaxit — Wed, 05 Jun 2024 13:42:46 GMT

Hi, what would be the major advantage of using the RPC stack? Does it relieve a lot of computation from the application core? Memory?

RE: CONFIG_BT_RPC_STACK on a custom board

Hung Bui — Thu, 04 Jan 2024 10:38:56 GMT

Hi Jordan,

When you build a BLE sample for nRF5340 the RPMsg child will be built by default and it will be combined into the merged domain hex file so when you flash the application the netcore will also be flashed. You don't need to do anything.

The RPMSG should support all HCI commands. I am not aware of any limitation.

RE: CONFIG_BT_RPC_STACK on a custom board

Kyle — Wed, 03 Jan 2024 17:16:22 GMT

Thank you, this is very helpful. It sounds like it would be better to use the RPMsg child image for my case, then.

The RPC documentation provides a list of Kconfig values that must match between the host (child image on the network core) and the client (parent image on the application core). Is this necessary for the RPMsg child image as well? i.e. are there any Kconfig values that must have the same value for both the parent and child image?

RE: CONFIG_BT_RPC_STACK on a custom board

Hung Bui — Tue, 02 Jan 2024 12:57:53 GMT

Hi Jordan,
1. As far as I can see by having CONFIG_BT_RPC_STACK in your configuration, you will select BT_RPC configuration, and that in turn will select NCS_SAMPLE_RPC_HOST_CHILD_IMAGE. Please see \nrf\samples\Kconfig

2. Yes you should do the same. The RPC host is built for the netcore and usually the board config for the netcore doesn't change between custom board and the DK unless you have some special configuration for example to control GPIO pin for the netcore.

I believe building the RPC host image separately and building it using CONFIG_BT_RPC_STACK in your app core should have the same result.

3. There is a fundamental difference between RPC child image and RPMSG child image that the RPC child image has both the BLE host and the BLE controller included in the netcore when the RPMSG child image only have the BLE Controller on the netcore.
In the RPMSG you would need to have the BLE host running on the application core. In the case with RPC, you would need to use the RPC library to interface with the host on the netcore. The command from the application is serialized and send to the host on the netcore. Then when there is response data it will be sent back to the application.

In most common applications we use the RPMSG and run the host on the application core.

The drawback of using the RPC is that only a subset of Zephyr Bluetooth API is available. And that there is more latency due to overhead for exchanging message between cores.