Questions of porting a new BLE chip to Mbed-OS 6

Mbed OS
,
1

We are considering to port our own BLE chip to Mbed-OS 6, and we have two questions now:

  1. In latest BLE API, is it acceptable to use the Cordio stack + our own S/W LL+BB codes which without the WSF and PAL? This can help us a lot to port the BLE chip to Mbed-OS.

  2. If Mbed-OS BLE supports Mesh in future. Does the Mesh is based on the Cordio stack, and all BLE chips can work well?

2

Hi @ccchang

Could you add more informations on your first question ? What are you trying to achieve ? If it is a port at the HCI level you shouldn’t have to deal with the PAL or is it something else ?

To answer your second question, the upstream Cordio stack includes a mesh stack: GitHub - packetcraft-inc/stacks: Packetcraft Open Source products: Controller, Host, Profile and Mesh . It is not exposed by Mbed today but if it were, it would work on any controller supported by Mbed.

3

For the first question, due to the Nordic SoftdDevice stack and Maxim stack are removed in Mbed-OS 6.0, we want to confirm is it allow merged to Mbed-os main stream with below conditions,

  1. The BLE host uses Mbed Cordio, but the BLE controller uses our own S/W LL + BB.
  2. The BLE host and controller use a “thin” HCI to communicate.
  3. The S/W LL + BB includes a library and few H/W related source codes, and does not use the WSF and PAL.

For the second question, do you have a schedule of support BLE Mesh in Mbed?

4

Thanks for providing more details @ccchang . The model you described is used by other stacks where the LL + BB are proprietary and the HCIDriver interfaces the host stack with them. For an example see mbed-os/connectivity/drivers/ble/FEATURE_BLE/TARGET_STM32WB at master · ARMmbed/mbed-os · GitHub .

I don’t have any timeline to share for the integration of BLE Mesh in Mbed. In theory it should be possible to use it today importing the sources from Cordio I shared in my previous post but this would require some work.

5

@vcoubard The STM32WB uses the H/W BLE controller that run at another M0+ MCU. The only two solutions that use S/W proprietary BLE controller should be Nordic SoftDevice and Maxim BLE stack, but Mbed OS 6.0.0 removes these two stack and announce only accept the up-to-date Cordio stack.

Summary of changes in Mbed OS 6.0.0 release

  • Remove Nordic SoftDevice stack (used by nRF51* targets). Notes: nRF52* targets are unaffected as they use Cordio stack.
  • Remove the current Maxim BLE stack (until a newer version based on up-to-date Cordio stack becomes available).

Based on above information, I know the S/W proprietary BLE host + S/W proprietary BLE controller is not allowed now. I still want to double confirm the S/W Cordio BLE host + S/W proprietary BLE controller is allowed.

6

@ccchang The Maxim ports were using external BT controllers, it was the same architecture as the one used today except they were providing binaries of the Cordio stack instead of sources. The STM32WB controllers runs within the same MCU but a different core. From an architecture standpoint it is between Nordic and an external controller.

We removed the option for S/W proprietary BLE host + S/W proprietary BLE controller because it was ending with too many differences between implementation when owner support was low.

Instead, we allow S/W Cordio BLE host + S/W proprietary BLE controller. The HCI is the interface is small and won’t vary over time which allows us to be more flexible while it reduce the amount of work required to make a controller port.