A ble peripheral project of nrf5340

[Jacob Lee]

Hi,

We will create a ble peripheral device and also can handle timing-critical uart request.
The uart will be always communicating and response time can't be slower than 20ms.

We want to choose nrf5340 to be our platform and have some questions:
1. If using the Split BLE Controller and Host architecture, can we integrate our application in the network core?
If yes, which example is a good initial project?

2. If using the Split BLE Controller and Host architecture, will the application core be interrupted by network core?
    If yes, how does our product to match timing requirement?

3. Is any known limitation in the Full Bluetooth LE stack example?

thanks,
Jacob

[Einar Thorsrud]

Hi Jacob,

Generally speaking 20 ms is a lot of time, so although there is not a lot of information here I would not expect you should see any issues with regards to that.

1. If using the Split BLE Controller and Host architecture, can we integrate our application in the network core?
If yes, which example is a good initial project?

The radio is only accessible from the network core, and so at least the link layer (controller) of the Bluetooth stack must be located there. And if your app was to be there as well, you would also need the rest of the stack there and you would easily run out of flash and RAM. Why do you want to put your application in the network core? If you are after a single core device, then perhaps the nRF52840 is more what you need?

2. If using the Split BLE Controller and Host architecture, will the application core be interrupted by network core?
    If yes, how does our product to match timing requirement?

Yes, the application core will get interrupts from the network core. However, as the host is on the network core there is typically a lot of slack (timing wise) here, so you can have application interrupts with higher priority.

3. Is any known limitation in the Full Bluetooth LE stack example?

Which example are you referring to here? Also, generally any implementation sand samples have limitations, so we would need to know which limitations you are interested in.

Einar

[Jacob Lee]

Einar Thorsrud said:

Which example are you referring to here? Also, generally any implementation sand samples have limitations, so we would need to know which limitations you are interested in.

In this document full-bluetooth-le-stack describes:

The Bluetooth: Host for nRF RPC Bluetooth Low Energy sample is currently supported for development only.
It does not support all Bluetooth Host APIs yet.

That's why we don't have much confidence in full-bluetooth-stack.

We are considering which one is better to be our initial project , "split controller and host" or "full-bluetooth-stack"?

Any suggestion?

[Einar Thorsrud]

Hi,

In any case, the Bluetooth stack in the nRF Connect SDK consists of a host layer and a controller layer. The most common use case is to run the controller on the network core, and host on the application core. This way, the application using the Bluetooth APIs must run on the application core. This is the most common approach. Another option is to run both the host and controller on the network core, and also run the Bluetooth application on the network core. Both these are currently supported, but the latter does not suit all applications as there is a limited amount of memory on the network core. You would typically also want to use the application core for something.

The third option, is where the full Bluetooth stack runs on the network core, but the Bluetooth APIs are available on the application core. This will have several advantages, both with regards to utilizing more of the network core and reducing overhead in the communication between the cores (as it happens on a higher level). However, this has recently been introduced and is currently experimental. This is quite early, and as you see form the documentation only GAP and connection management is support. It is useful for experimentation if you want to use that approach, but lack a lot (most) of what you need in order to use it. If you are starting development today then you can experiment with it, but I recommend you go with one of the other approaches now. If you want to know more about the timeline for the full Bluetooth stack then please ask the Nordic sales representative in your region.