2 years, 10 months ago.
When to use mbed OS 5
Now mbed OS is available in the online compiler, the main question I would ask is: Why? Why should I use mbed OS 5 instead of classic mbed? If I look at some documentation and by checking it in the online compiler it seems mainly that many libraries are built-in, but I don't know if one giant library offers me advantages. I guess if you want to focus on (some specific forms of) networking connectivity it certainly offers advantages. But if I want to make lets say a quadcopter, or a BLE watch, etc, does mbed OS offer me any advantages?
The blinky example already takes double the flash and ten times the SRAM on an LPC1768 compared to a basic one. Although I guess/hope that is mainly due to RTOS (still of course if you don't need RTOS it is quite a bit).
Maybe I am mistaken, but to me it seems mainly like many more libraries in the classic mbed one, and if you don't need those it is of limitted value. But I am happy to be proven wrong :).
Btw1: Mbed-os has some files in the online compiler which aren't really useful, like a picture and a CLI readme.
Btw2: If you go to developer.mbed.org your entire screen will be filled by a single banner.
Btw3: While technically the LPC1114 is apparently mbed enabled, the blinky example takes 70% of its flash and 50% of its SRAM.
Question relating to:
2 years, 10 months ago.
As you rightly point out, mbed OS 5 is fully integrating these RTOS, connectivity and security components as part of the maintained core, so they are all developed, integrated and tested together such that they can become relied upon and official parts of the OS - so things like Ethernet, BLE, WiFi, 6LoWPAN and Thread, TLS security. They are still componentised within that core, so they don't need to be "enabled" and built in to the end image.
So sure it will make sense to build a BLE watch with mbed OS 5, even if it is not using some of the features. In fact, we'd like to ensure there is no reason not to upgrade from classic mbed to mbed OS 5 in most cases, and this is what we expect to happen. Hopefully you can help us refine things to make sure that is the case.
At the moment, on some very small applications you'll notice some code size jumps mainly due to us using the standard C libraries rather than the "microlib" or "nanolib" variants for builds; this is due to them not yet having the hooks for thread safety in we want, but they are being worked on.
Thanks also for all the BTWs! I'll get someone to look at those.
To post an answer, please log in.