search

ARMmbed / mbed-os-example-mesh-minimal

Simplest Mesh capable test application for mbed OS
Apache License 2.0
38 stars 42 forks source link

Thread protocol support removed? #319

Closed georgejourneaux closed 4 years ago

georgejourneaux commented 4 years ago

Description of defect

It's more of a question/problem with getting started with the mesh api.

I was looking to develop a Thread mesh network using the STM32WB55 Nucleo board and mbed-os, but I've noticed that Thread seems to be getting removed from all of the mbed documentation (For example: ARMmbed/mbed-os-example-mesh-minimal/#306).

Is there any particular reason for this?

What target(s) are you using? NUCLEO-WB55RG

What toolchain(s) are you using? Mbed Studio 1.3.0

What version of Mbed OS are you using (tag or sha)? mbed-os 6.3.0

It would help if you could also specify the versions of any tools you are using? The latest

How can we reproduce your issue? N/A

ciarmcom commented 4 years ago

@georgejourneaux thank you for raising this issue.Please take a look at the following comments:

Could you add some more detail to the description? A good description should be at least 25 words. What target(s) are you using? What toolchain(s) are you using? What version of Mbed OS are you using (tag or sha)? It would help if you could also specify the versions of any tools you are using? How can we reproduce your issue?

NOTE: If there are fields which are not applicable then please just add 'n/a' or 'None'.This indicates to us that at least all the fields have been considered. Please update the issue header with the missing information, the issue will not be mirroredto our internal defect tracking system or investigated until this has been fully resolved.

georgejourneaux commented 4 years ago

Similar question here: ARMmbed/mbed-os/#13624

ciarmcom commented 4 years ago

@georgejourneaux it has been 5 days since the last reminder. Could you please update the issue header as previously requested?

georgejourneaux commented 4 years ago

@ciarmcom Apologies, I've updated it now!

ciarmcom commented 4 years ago

@georgejourneaux it has been 5 days since the last reminder. Could you please update the issue header as previously requested?

ciarmcom commented 4 years ago

@georgejourneaux it has been 5 days since the last reminder. Could you please update the issue header as previously requested?

ciarmcom commented 4 years ago

@georgejourneaux it has been 5 days since the last reminder. Could you please update the issue header as previously requested?

ciarmcom commented 4 years ago

@georgejourneaux it has been 5 days since the last reminder. Could you please update the issue header as previously requested?

ciarmcom commented 4 years ago

@georgejourneaux it has been 5 days since the last reminder. Could you please update the issue header as previously requested?

georgejourneaux commented 4 years ago

Having had a bit of a deep dive into how the mbed connectivity APIs work, I believe I have two options:

As the target technically has an off-board network-stack (user loaded on its M0+ core) with an IPCC transport layer to interact with it, I believe that I should be looking at creating a NetworkInterface not a NanostackRfPhy driver. The NetworkInterface I create would then pass the network calls from the mbed-os APIs to the off-board stack, via the IPCC transport layer.

To me it seems like this would make the best use of the STM32WBs' architecture, but please do let me know if I'm completely wrong here as I'm fairly new to mbeds connectivity APIs. In the meantime I'll close this issue as I think I've solved my problem.