CONFIG_BT_RPC_STACK on a custom board

[JordanK]

I have a custom board with an nRF5340 on it. I'd like to offload BLE operations to the network core using the RPC library to control it from the application core.

The documentation states to do this by enabling the "CONFIG_BT_RPC_STACK" option. Some questions about this:

1. How does this actually work? Searching for "BT_RPC_STACK" in the nRF Connect GitHub repo returns the definition of this option, but I don't see where it's used and how its use causes West to build a specific sample as a child image and include it in the overall build/flash.
2. If I need to use this with a custom board, should I still use this config option? The documentation states that this causes the "rpc_host" sample to be built for the network core, but that sample is designed for the nRF5340DK board which has different pinouts than my custom board. Would it be better to clone and alter this "rpc_host" sample and customize the child image configuration (specifying it in CMake) instead of using the "CONFIG_BT_RPC_STACK" option? Or does this config value enable additional things other than just including that sample as a child image?
3. I'm not clear on the differences between the CONFIG_BT_RPC_STACK option (includes "rpc_host" as a child image) and the "CONFIG_BT_RPMSG" option (includes "multiprotocol_msg" as a child image). In which cases would you choose one over the other as the child image to run on the network core?

[Hung Bui]

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.

[JordanK]

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?

[Hung Bui]

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. 

[Yaxit]

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