Brief: Why is Mbed developing a thread stack and not just using OpenThread?

TLDR version:

The last time I seriously looked at MCU based 802.15.4 mesh networks Mbed was promising a solution and OpenThread had only just been released. The OpenThread at the time supported no MCU that I had interest in - just two or three "other" solutions. Mbed did support the MCU's I had - just not yet with a matching radio stack.

Fast forward a couple of years to now and things have changed quite a bit.

I saw and started playing with mbed-os-example-mesh-minimal. Excluding LoRa, Mbed now has a 6lowpan and thread stack for two 802.15.4 radios and perhaps a sub 1GHz radio:

1) An Atmel AT86RF233 with a purchase link that is now dead.

2) NXP/Freescale FRDM-CR20A (including FRDM-KW24D).

3) And, if you dig deep, perhaps the start of an undocumented stm-s2lp-rf-driver (sub 1GHz).

With two FRDM-KW24D's and mbed-os-example-mesh-minimal I was able to get the boards to blink each other's LED.

However, I also have FRDM-KW41Z's and ThunderBoard Sense II's that are listed as Mbed boards. The lack of Mbed radio support for these boards got me to look at OpenThread again. The associated platforms page lists 11 radios:

https://openthread.io/platforms

That list includes KW41Z and EFR32.

Hmm. OpenThread supports different but more radio hardware than Mbed. And, it is newer hardware. I do like how Mbed generalizes pins and other I/O and supports many more boards in general but... it simply doesn't support the radio's I want to use.

The other thing that caught my eye on the OpenThread platform list is that it lists two different RTOS's - neither of which is Mbed.

Another observation is that the OpenThread forum seems much more active with respect to mesh development than related posts in the main Mbed forum. Finally, and I have no experience to base it on, but the OpenThread approach to testing seems more robust for testing radio stacks.

OpenThread building does appear to use more traditional build tools - a good thing for me because it is familiar. That said, I wont know for sure until I try it. To me, the Mbed tool approaches, online (which I will never consider as an option) and mbed-cli, seem to obscure critical things that are going on.

One final thing that my untrained eye noticed during my quick perusal of OpenThread is that their radio abstraction seemed similar to that in Mbed - a bunch of straight C calls.

...

It is unfortunate that I can't have the best of both Mbed and OpenThread.

Or, can I?

Hi,

We actively work with silicon partners to enable our customers so your feedback is valuable. Please let us know about which parts your solution requires. Thanks!

The development boards representing the chips:

• Silicon Labs Thunderboard Sense II (aka SLTB004A), and

• NXP FRDM-KW41Z

Thunderboard is available now: https://os.mbed.com/platforms/thunderboard-sense-2/

KW41Z radio driver is under development: https://os.mbed.com/platforms/FRDM-KW41Z/

And KW41Z radio driver is here: https://github.com/ARMmbed/mbed-os/tree/master/features/nanostack/targets/TARGET_NXP/TARGET_KW41Z

Thanks, Pasi. So the Silabs EFR32MG12P radio driver is still not available for the Thunderboard Sense II, is it?

ThunderBoards Sense II example:

git clone https://github.com/ARMmbed/mbed-os-example-mesh-minimal mesh
cd mesh
mbed update
mbed toolchain GCC_ARM
mbed target TB_SENSE_12
mbed compile

Results in multiple errors like:

[Error] NanostackRfPhyAtmel.h@29,26: 'D11' was not declared in this scope

So... why is it trying to compile for the Atmel radio?

KW41Z example:

git clone https://github.com/ARMmbed/mbed-os-example-mesh-minimal mesh
cd mesh
mbed update
mbed toolchain GCC_ARM
mbed target KW41Z
mbed compile

Results in:

[DEBUG] Errors: /Users/jahess/opt/gcc-arm-none-eabi-8-2018-q4-major/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld: BUILD/KW41Z/GCC_ARM/mbed-os/features/nanostack/targets/TARGET_NXP/TARGET_KW41Z/NanostackRfPhyKw41z.o: in function `NanostackRfPhy::get_default_instance()':
[DEBUG] Errors: /Users/jahess/dev/embedded/mesh/./mbed-os/features/nanostack/targets/TARGET_NXP/TARGET_KW41Z/NanostackRfPhyKw41z.cpp:1090: multiple definition of `NanostackRfPhy::get_default_instance()'; BUILD/KW41Z/GCC_ARM/mbed-os/components/802.15.4_RF/atmel-rf-driver/source/NanostackRfPhyAtmel.o:/Users/jahess/dev/embedded/mesh/./mbed-os/components/802.15.4_RF/atmel-rf-driver/source/NanostackRfPhyAtmel.cpp:2327: first defined here

Why is it trying to link with the Atmel radio code?

Hi Jonathan,

Please find below link to update the mbed_app.json. https://github.com/ARMmbed/mbed-os-example-mesh-minimal/issues/250