Hi all,
I tried searching for related posts but could not find a clear answer. Basically we are trying to build a device that supports both BLE and Matter. We do not need the protocol to be running concurrently. The idea is to be able to choose which protocol to use at start up via a button press. I was wondering what would be the best practice to implement something like this?
Thank you.
Hi,
Here are our resources on Matter in nRF Connect SDK here as well as the overview over Matter samples.
It is possible to do multiprotocol application but we do not have any existing samples that does this. "In the nRF Connect platform applications, the Bluetooth LE interface is used to perform pairing and Thread network provisioning operations between the Matter device and the Matter controller. Afterwards, the fully provisioned device is able to communicate with other devices inside the Thread network.
For the Bluetooth LE communication purposes, the nRF Connect platform application is using the Bluetooth LE stack, in which the Bluetooth LE Host part is provided by the Zephyr RTOS and the SoftDevice Controller is implemented in the nRF Connect SDK’s driver."
As far how to implement this and best practices goes that would depend on your application design, but a suggestion is to have a look at some existing samples for how Bluetooth scanning/pairing/searching functionality works in our existing samples, and tro to add that together with an existing Matter sample and implement some required multi protocol support according to the need of your application.
Of course, the thread is open to the community for responses as well, so feel free to join in if there are developers with experience on this type of applications as well as let me know if this clarifies your situation a bit.
Kind regards,
Andreas
Thanks Andreas for the quick reply.
To clarify, I understand that Matter uses BLE for commissioning. However, we are looking to have the product function in a standalone BLE mode, OR Matter mode (with commissioning via BLE).
Would this usually be implemented via two separate images, and loading the selected one via the bootloader?
Thanks Andreas for the quick reply.
To clarify, I understand that Matter uses BLE for commissioning. However, we are looking to have the product function in a standalone BLE mode, OR Matter mode (with commissioning via BLE).
Would this usually be implemented via two separate images, and loading the selected one via the bootloader?
Hi again,
I think it all depends on the size of the application. If you can fit both BLE and Matter variant in the internal flash partition, I would go for it and decide which stack to initialize at the beginning of main function (based on some persistent setting). That would be the simplest solution and the time to switch the variants would be the shortest. If both variants are big and have a lot of non-overlapping functions so that sum of their sizes exceeds the internal flash size, then using a bootloader seems like a must. It would complicate Device Firmware Update though - there would need to three application slots in the external flash to store the current inactive variant, and two variants for the new firmware.
Regarding how well the bootloader handles the case with multiple slots for a single image (in case the DFU is needed), I can not say for certain at this point in time , and since it is somewhat unrelated to the original question, I would recommend you open up a new ticket for that question and we will assign it to someone whos more experienced with how the bootloader works
Kind regards,
Andreas
Hi Andreas,
Thanks for the further explanation. I don't expect that we will exceed the 1MB of internal flash, but we won't know for sure until we get there!
Given your reply, we might not need to have multiple images for different operating "modes". I had assumed that having separate images might be a cleaner architecture, but could be mistaken. I think we just need to take a step by step approach as there are still many unknowns.
Hi,
whyeye said:we might not need to have multiple images for different operating "modes".
That might hold true, but again it will depend on the scale and size of your application. In case you have not seen this page on multi image builds I would recommend take a look at it to see if your application fits some of the "criteria" for using multi image builds that we suggest here.
whyeye said:I had assumed that having separate images might be a cleaner architecture, but could be mistaken
It might not be a wrong assumption to make, but to be sure you can open a new ticket with a more specific question related to that. Feel free to link this case as a related case so the new case handler can see what has been discussed here.
Let me know if your initial questions has been answered,
Kind regards,
Andreas
