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?
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?