COMPONENT_BlueNRG_MS creation : ST Bluetooth Low Energy module #12456
Conversation
|
@ARMmbed/team-st-ble |
|
@jeromecoutant, thank you for your changes. |
82926b1 to
40fef69
Compare
|
@jeromecoutant I really love this PR! It gives mbed os users a real life example for using an external BLE module with a bigger MCU. A few remarks/questions: DISCO-L562QE cannot be found on the ST website with this name. ST references this board as STM32L562E-DK --> The mbed documentation page gives us the ST name, but I think it would be nice to have a link in the readme or at least a reference to the ST name. Both boards are using SPBTLE-RF but its status is ST references two modules that could be used, both part of the longevity program (which is super cool for users betting on those modules!):
How compatible with the SPBTLE-RF HCI Driver would those two modules be? BlueNRG-M0 seems to be a replacement of SPBTLE-RF as they both have the BlueNRG-MS network processor. We are building a smart robotic education tool for children with special needs and pre-selected those two modules to use but are not experts in HCI Driver development. This PR seems like a good starting point but we need help choosing the right module. BLE 5.0 with higher data rate would be really useful for us, but if it means longer and more complicated development times, we would happily stick to 4.2. |
I changed https://os.mbed.com/platforms/ST-Discovery-L562QE/ page
Agree :-(
@avilei please comment |
That's correct. You can replace SPBTLE-RF with the BlueNRG-M0 module without any issues. They're pin-to-pin compatible and you can reuse the same software that you have today without any changes.
That's based on a different chip, so it is not compatible with the current version of Mbed drivers. |
|
CI started |
Test run: FAILEDSummary: 3 of 4 test jobs failed Failed test jobs:
|
|
Hi |
|
@jeromecoutant in this case yes, please fix the examples |
|
@avilei Thanks a lot for the detailed answer! We'll got for the BlueNRG-M0 as our base solution for BLE.
You mean if we wanted to run mbed on the BlueNRG-M2? In our case, we don't want to run mbed on the BlueNRG-M2, mbed runs on our custom board based on the STM32F769 and we just need a BLE module to connect to iOS. I have a hard time understanding how concretely we could port the HCI driver for BlueNRG-M2 and how hard it would be. And if it is possible at all. The porting instructions are detailed but hard to follow, as I don't have much experience there :( Another solution we are thinking about is to program the BlueNRG-M2 with ST's tools (setup services and characteristics we need), use mbed on the STM32F769 and create a simple communication protocol between the two using UART to received the data send through BLE. |
|
@jeromecoutant the PR description talks about
Should it not be the Cordio one?
Or both? |
My mistake... |
|
|
@jeromecoutant @avilei -- I was going through the PR again last night and I had some thoughts about the naming and the README.md in regard of custom board designs. I know that SPBTLE-RF is the module used by the shields, but it is listed on the ST website as not recommended for new designs. In addition to that, it is not even mentioned in the ARMmbed/cordio-ble-x-nucleo-idb0xa1 repository. The README.md also mentions the BlueNRG-MS which adds to the complexity Per @avilei , the BlueNRG-M0 is the go-to replacement for new designs:
With all this information, I'm wondering how we could make it easier for future users to know what they can or cannot actually use. I myself spent countless hours reading through specs and manuals to make sure I was not mistaken before choosing a BLE module. Maybe a simple table like this could help:
Finally regarding the naming of the path in components and the HCI driver, I would suggest the following by referencing the BLE processor instead of the module name: - components/BLE/COMPONENT_SPBTLE_RF/BlueNrgHCIDriver.x
+ components/BLE/COMPONENT_BlueNRG_MS/BlueNrgMsHCIDriver.x
// or
+ components/BLE/COMPONENT_BLUENRG_MS/BlueNrgMsHCIDriver.xThis way we refer to the BLE processor which is the same for SPBTLE-RF and BlueNRG-M0 and allows us to use them interchangeably. This would mean renaming - "SPBTLE_RF"
+ "BLUENRG_MS"
// and
- "CORDIO_BLUENRG"
+ "CORDIO_BLUENRG_MS"And if/when we add support for the BlueNRG-M2 module we'll be able to add: + components/BLE/COMPONENT_BLUENRG_2/BlueNrg2HCIDriver.xWhat do you think? |
|
@ladislas Please note that we're about to distribute a replacement board for X-NUCLEO-IDB05A1, called X-NUCLEO-IDB05A2, which will be based on the newer modules for BlueNRG-MS. |
|
CI restarted |
|
I had to abort a job, will restart later today. We need 5.15 issues to be addressed today. |
Test run: FAILEDSummary: 2 of 3 test jobs failed Failed test jobs:
|
|
CI restarted |
Test run: FAILEDSummary: 2 of 3 test jobs failed Failed test jobs:
|
What is this shields directory ? |
|
@ARMmbed/mbed-os-test Please review ^^ Isn't this expected - ble examples uses own config - adds BLE to a target and with this PR there are multiple defined symbols - a reason why this PR was dependent on mbed-os-example-ble#284 ? |
|
I'll start CI later today. The example was updated. This should pass the build now |
|
CI started |
Test run: SUCCESSSummary: 6 of 6 test jobs passed |
|
This needs to get in to unblock master (example was already updated) |
Summary of changes
BlueNRG chip is embedded in the IOT L475 and DISCO-L562 boards
Proposition is to migrate the specific repo to a mbed-os component
@donatieng @bulislaw
@ARMmbed/team-st-mcd
@MarceloSalazar
Impact of changes
Set https://github.com/ARMmbed/cordio-ble-x-nucleo-idb0xa1
as deprecated
Migration actions required
Documentation
Pull request type
Test results
Reviewers