Is Mbed OS a good OS? - Page 1
Forum section: electronics / general

author: lollandster
author_rank: Contributor
timestamp: December 21, 2019, 03:37:16 am
content: I some times need to make something quickly without having to dive deeply into a reference manual, and for that I have used Arduino and Mbed. This worked great for testing out simple concepts, but I now want to take it one step further. More specifically I want networking and RTOS.I have a total of 5 boards that are marked Mbed compatible where 3 are older ones and 2 are very new. But I find that neither of the two newer boards actually works in Mbed. My MIMXRT1010-EVK isn't listed at Mbed.com so I guess support is coming later. My NUCLEO-G071RB can be added in the Mbed compiler, but when I try to compile it says that the target is recognized. I tried with completely new blinky project, I tried updating library and I tried Mbed Studio, nothing works. Since I had just ordered the NUCLEO-H743ZI2 specifically for the Mbed support I tried adding that and compiling for it and it did not compile for that one either. Either I'm doing something wrong or Mbed support is awful for new boards.So before I go any further I wanted to ask your opinions, is Mbed OS a good choice?I'm new to RTOS and networking on MCU so I don't know my options. I guess freeRTOS is one option, but the learning curve seems a bit steep.

author: viperidae
author_rank: Frequent Contributor
timestamp: December 21, 2019, 05:49:07 am
content: I've found platformio is quite good at sorting out the project config stuff. There are a lot of supported boards and many work with multiple frameworks - mbed, Arduino and cubemx. My latest project is cubemx based with freertos as a library on a nucleo 452

author: ebclr
author_rank: Super Contributor
timestamp: December 21, 2019, 12:54:51 pm
content: Try Updating the firmware on Nucleo boardhttps://os.mbed.com/teams/ST/wiki/Nucleo-FirmwareI have 15 different boards and all works, Mbed has Keil behind the scenes, who is the compiler made by arm

author: emece67
author_rank: Frequent Contributor
timestamp: December 21, 2019, 01:57:36 pm
content: .

author: lollandster
author_rank: Contributor
timestamp: December 21, 2019, 03:55:29 pm
content: Quote from: viperidae on December 21, 2019, 05:49:07 amI agree, platformio is nice now that debugging is available without paying $100 a year. It doesn't support the boards I'm having trouble with though.Quote from: ebclr on December 21, 2019, 12:54:51 pmThe problem isn't the board. The online Mbed compiler simply fails to compile with the error message: Error: Target "NUCLEO_G071RB" is not recognizedYou can compile for board you don't own so the firmware shouldn't make any difference. I did update it just to make sure though.Since everyone is positive to mbed I guess I'll make an effort to figure out what's wrong.I may have to change the question to, what board (with ethernet) is known to be working with mbed.

author: janoc
author_rank: Super Contributor
timestamp: December 21, 2019, 04:18:49 pm
content: If you are getting that error it simply means that their compiler/setup has not been updated to support that particular board yet. I had the same issue with STM32F042 based boards. They came with the nice blue logo "mBed enabled" (or what it was) on the packaging even - and there waszerosupport for them for a long time and only a fairly limited support to this day.mBed (libraries) and mBed OS (their RTOS) are nice if you are running it on exactly that one or two boards they have been developed on. The rest is a major hit-and-miss - MCU may be supported but peripherals are not, major components like USB are not supported, etc. And, worse, this is not documented and you have to dig the information out from various forum posts. "Supported" often only means that the thing compiles on that specific MCU and you can maybe blink a LED with it. That's all.Better look elsewhere if you want a system for some serious work.

author: rstofer
author_rank: Super Contributor
timestamp: December 21, 2019, 09:15:07 pm
content: Quote from: lollandster on December 21, 2019, 03:55:29 pmSome years back I needed an interface to send plot data to my LaserJet via a TCP connection. I used the original mbed LPC1768 and the associated TCP/IP library. The only external component needed for that board to connect to the network is a MagJack. In terms of network code, I just used a Berkeley Socket to make the connection to the LaserJet. Easy!

author: lollandster
author_rank: Contributor
timestamp: December 21, 2019, 09:26:18 pm
content: Quote from: janoc on December 21, 2019, 04:18:49 pmThanks for the sharing your experience. Nice to know it's not just me doing something wrong.I have been poking around a bit and I have found two things. The Nucleo-G071RB is actually not listed on the mbed site, so the only way to add it (afaik) is to use the mbed.html file on the board. That may be a big red flag that this board isn't supported yet. So both NXP and STM is selling Mbed enabled boards that doesn't work with Mbed. Nice. To be fair, neither of them uses the mbed logo.The Nucleo-H743ZI2 on the other hand is clearly marked with the mbed logo and is listed on the mbed site. But for some reason it doesn't work in the online compiler. It does however work in Mbed studio and the online compiler allows exporting code. Mbed studio doesn't support the sockets example to be used with H743ZI2 but it does for H743ZI. Those boards use variants of the same processor with the same specifications, so I hope that it's just the example that doesn't work and not the sockets library. The only difference I can see between the boards are a change to ST-Link v3 (from v2.1) and to SMPS power converter.I was very close to ordering a FRDM-K64F (it would be my first choice if it wasn't for the EAR BS last time I ordered a NXP board), but I'm optimistic about the H743ZI2 now.Quote from: rstofer on December 21, 2019, 09:15:07 pmThat board was on my short list, but it didn't have the port and it was twice the price of the H743ZI2. If the H743ZI2 doesn't work out I'll definitively order that so I have something I know is working. Thanks.

author: rstofer
author_rank: Super Contributor
timestamp: December 21, 2019, 10:41:55 pm
content: Quote from: lollandster on December 21, 2019, 09:26:18 pmHow much do you save if you have to order two boards? As a hobbyist, I'm not going to buy more than one or two of anything. Price isn't all that important.OTOH, if the board doesn't meet the needs in other areas, well, it simply isn't suitable. By the way, you can use the DMA memory in your application by applying some compiler wizardry like:static char queue __attribute__((section("AHBSRAM0")));orbuffers __attribute__((section("AHBSRAM1"))); // only 16k bytesI wanted a queue of TCP buffers for output and a queue of input chars that came in via SPI and an interrupt.As I recall, the LPC1768 was the first and only board available when I started the project. ARM hadn't bought out mbed way back when.

author: lollandster
author_rank: Contributor
timestamp: December 21, 2019, 11:07:25 pm
content: Quote from: rstofer on December 21, 2019, 10:41:55 pmI agree, but looking at the specs the H743ZI2 is way superior to the Mbed-LPC1768 at almost half the price. I would be stupid to choose LPC1768 given the information I had at the time. The main reason LPC1768 was on my short list is the form factor, I like how it can be used as a module and not just a dev board. Now that I have more information I probably would have ordered the LPC1768.

author: rstofer
author_rank: Super Contributor
timestamp: December 22, 2019, 12:53:01 am
content: I actually chose the mbed LPC1768 based on form factor. I just built a daughter card with the MagJack and SPI input terminals and plugged the mbed board on top. I like easy!For something dedicated like my TCP application, I like the 'stamp' style boards. For more general purpose development purposes, I like boards with gadgets like 7 segment displays, switches, LEDs and buttons (mostly for FPGA projects).Still, I have several STM32F development boards just for tinkering. I don't use the mbed infrastructure for these boards, I don't know if they are really supported.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: January 08, 2020, 12:24:32 am
content: My experience with MBED is very limited.I once wrote a test program: Read ADC value from a pot, scale it and output it to a standard RC servo, in a tight loop.The output was extremely glitcy, I guess it was not capable of reading the ADC at 1MHz and outputing it to a 20ms RC signal without adjusting the timing.So then I had a look into it's internals.MBED seems to be a nice idea, but not much effort has been made in writing good code.MBED was also a layer over the CMSIS stuff, so after about 5 or 6 layers deep of funcion calls in the initialisation I found empty functions with comment "insert your code here".Duh, If it did not have those 6 function calls, I would not have wasted time following them.If you want to do some "quick" project every now and then, just take a (pre built / development) -board you are familar with and use that.Even if the board itself is complete overkill for the application.If you spend some effort in writing decent code for "real" / complex projects, then you will build a collection of your own libraries, or build the knowledge of which libraries are of decent quality.Then you can simply reuse those libraries for a "quick" project, and just ignore the extra functionality in those libraries.If you use a 32bit processor to toggle a LED, I'm sure the firmware fits in it 128kB of flash.For one-off projects the defelpont time & effort usually also is much more important than the cost of the hardware.

author: lollandster
author_rank: Contributor
timestamp: January 09, 2020, 09:51:55 am
content: I finally received the H743 card and I got to try it with Mbed. I guess the compiling error I got in the online compiler was a bug they’ve fixed since it worked now without changing anything. Unfortunately Mbed Studio doesn’t support debugging on that board or I’m missing some drivers that I don’t know about (the F446 board worked without additional drivers).There were no example projects other than the blinky project available for the card, but copy/pasting the socket example from another board worked on the online compiler, but not in Mbed Studio. The card receives correct IP address from DHCP and reports http working, so the socket library from Mbed works without problems that I could see. That’s all I got to test for now.Since Mbed looks so immature I decided to learn some freeRTOS. I finished a Udemy course on freeRTOS and started another on TI-RTOS. It’s a lot more work to get started, but I think it’s worth my time. I haven’t used TI much since I never understood their naming scheme (it turns out that MSP432 isn’t 16 bit like MSP430, who would have guessed). There were no ethernet examples in the Cube H7 for the H743ZI so I think I’ll buy a MSP-EXP432E401Y which has a lot of examples projects for ethernet (non-RTOS, freeRTOS and TI-RTOS).

author: westfw
author_rank: Super Contributor
timestamp: January 09, 2020, 11:01:36 am
content: I would be very unwilling to use a chip-specific rtos (like TI-rtos), unless I was really certain that I would be sticking with that vendor for a very long time...

author: lollandster
author_rank: Contributor
timestamp: January 09, 2020, 11:27:34 am
content: Quote from: westfw on January 09, 2020, 11:01:36 amI know, but the concepts are the same so I’m hoping that transitioning between them wont be too hard. I haven’t found many RTOS courses online so I have to take what I get.

author: janoc
author_rank: Super Contributor
timestamp: January 09, 2020, 03:50:53 pm
content: Quote from: lollandster on January 09, 2020, 11:27:34 amHigh level concept are maybe the same but RTOS is usually not only a scheduler and some locking primitives (like FreeRTOS).You often have peripheral drivers, build/IDE integration, etc. Those are necessarily vendor-specific. And if you are using a vendor-specific system it pretty much means a complete rewrite of your code should you decide to change MCU vendors (TI's system is unlikely to support ST's chips and vice versa ...).Even with vendor-independent systems supporting MCUs from multiple vendors it can be hard. E.g. I have been using ChibiOS for some of my things and changing to e.g. Nuttx, FreeRTOS or mbedOS is pretty much a complete rewrite of the code, even for the same chip family because the software architectures and APIs are so different - despite the basic principles being the same.So yes, transitioning could be pretty hard for any non-trivial codebase.

author: JojoS
author_rank: Contributor
timestamp: February 15, 2020, 01:31:08 pm
content: for me, Mbed is a very good OS. The Mbed team put lots of effort into developing the OS further. In about the last 3 years, it has grown incredibly. You get an OS with RTOS, USB, Ethernet, all standard IO stuff for free. It is also very well tested, I have never seen comparable OS with so much testing: CI, unit tests, tests, live tests on a server farm with more than 800 boards running continous tests.The concept with the online compiler is old, as far as I know it was developed by two ARM employees for education purposes. The main principle was that school computers could be used for µC development without installing toolchains. And there should be no debug or programming hardware necessary, just an USB cable.Now the online compiler is not at the main focus, the development went in direction IoT to gain some benefit and get the expensive development paid. You will find a lot of connectivity for IoT, but Mbed is still usefull for all other µC stuff. And for developing, the main tool is mbed-cli, the command line interface. This is a very convient build system where you put your source files/dirs in a project root and run 'mbed compile' without configuring toolchains or writing makefiles.Before I liked also to use the online compiler and export to an IDE, but this failed often because it is very hard to maintain. So using an editor like VSCode and some configuration to run the mbed-cli commands is my preferred way now. Mbed-studio is also still developing, it is easy to install and to use.So, about the initial question about the Nucleo G071RB board: this is working with Mbed, in the cli you can compile a blinky e.g. with 'mbed compile -m NUCLEO_G071RB' (and -t for your preferred toolchain, like '-t GCC_ARM'). And to save flash/ram space on smaller MCUs, you can exclude the RTOS now by using a bare-metal profile. This is selected by adding a mbed_app.json with the following contents:Code:{"requires": ["bare-metal", "events"],"target_overrides": {"*": {"platform.stdio-baud-rate": 115200}}}this will remove the RTOS, but keep the EventQueue that can be used as an alternative to the preemptive MT. The EventQueue is some of the cool stuff in MBed, you can simply throw callback function into this queue.

author: kamtar
author_rank: Regular Contributor
timestamp: February 18, 2020, 02:34:48 pm
content: I find OS in a bare-metal embedded application little bit itchy and rather avoid it. They are often used in bigger projects with some substantial development time where you can spend time on developing your own which is worth it (mainly if you can use it in your future projects too). Using a huge library which is trying to hide hardware and timing under abstract layers of "fits-all-use-cases" in a bare-metal development seems counterproductive to me. You will end up having to hack around it or to use more powerfull MCU then you need.

author: Karel
author_rank: Super Contributor
timestamp: February 18, 2020, 03:00:58 pm
content: When I need an OS, I take a Raspberry Pi. It has UART, SPI and I2C.

author: lollandster
author_rank: Contributor
timestamp: February 18, 2020, 09:18:18 pm
content: Quote from: JojoS on February 15, 2020, 01:31:08 pmThanks for your input. I haven't had much time to play with personal projects lately so my quest for a good OS has halted. I am however about to start on a work project where I plan to use a microcontroller with ethernet and CAN-Bus. Mbed will suite that well.Since everyone says to use the CLI, I gave it a try today. I compiled one of the projects that Mbed Studio refused to compile for my board (mbed-os-example-tls-tls-client) and it worked first try (target NUCLEO_H743ZI2). I also tried the mbed-os-example-sockets that worked in Mbed Studio but not in the online compiler and that too worked first try. I feel there might be hope.Compiling for the G071, however, just doesn't work for me. It is not listed by the mbed-cli. I don't understand how everyone else manages to compile for it, my only guess is that it was supported at some point but isn't anymore.Now I just have to find out how to get debugging working correctly.

author: JojoS
author_rank: Contributor
timestamp: February 19, 2020, 10:31:51 am
content: I'm happy when I can help someone to understand mbed-os, I'm very convinced that it is a real good piece of development.G071: you can show the supported targets with 'mbed compile -S'. It is supported in the current master branch, that is > mbed-os-5.15.0. You can update by 'cd mbed-os' and 'mbed update', this will checkout the latest master branch. So, the support for the NUCLEO_G071RB is very hot.The examples in the armmbed github repo refer usually to the latest release. So when you clone an example and follow the compiling instructions, it will work because it was tested against the referred mbed-os version. Historically, Mbed used the mercurial source code versioning and has switched now to git. The mbed-cli still handles both systems and thats the reason for not using git submodules and referring libraries by a simple tag file, f.e. mbed-os.lib.About the bare-metal:this is also a newer feature. It is also better to understand when you see the Mbed history: there was the mbed2 (or also called mbed-classic). That was in the beginning very slim, I have used it for targets with LPC812 for sensors with rf modules. The rtos came as an additional library, but you had to take care because many other features where not thread safe. A newer development of mbed3 (yotta) was not very popular. So when ARM started again to improve, mbed5 as a result of mbed2+3 was born. This had grown very fast with the IoT in focus. mbed2 was still updated, but the parallel development became more difficult and is stopped now for mbed2. As a replacement, mbed5 can be stripped now by removing the RTOS part. There are still more improvements now to reduce code size further.Using an OS or standardized API has the advantage of better reusable code. It is not only to simplify the usage of some gpio, serial, SPI, I2C, it makes also the targets interchangable. And I can use my components written for mbed2 still in mbed5 for 'fat' targets like F4 or F7 or interesting nRF BLE MCUs. I'm also not tied to a code generator that creates only code for one vendorAlthough, ST has pushed Mbed also a lot and is bringing in support for their MCUs very fast.So, give Mbed a try

author: lollandster
author_rank: Contributor
timestamp: February 20, 2020, 05:27:40 am
content: @JojoS - Thanks again, the -S option was very useful. My problem was the blinky-example, it refuses to update. If I create a new project however, the G071 starts working with mbed-cli. The online compiler still refuses to work reliable on my newer targets, but I was never planning to use that anyways.Now I just need to integrate Mbed-CLI into some editor together with debugging. Any recommendations?

author: JojoS
author_rank: Contributor
timestamp: February 20, 2020, 07:31:02 am
content: As an editor/IDE I'm using VSCode. It is very flexible in the configuration and there are many many extensions, also for debugging Cortex-M. The configuration is using simple json files, it is not the nightmare as with eclipse based IDE. I can give later some examples.Debugging the H7 is more difficult, but I found the reason a simplified core that ST is using. Stepping is not working as wanted, I tried also several workarounds.

author: ralphrmartin
author_rank: Frequent Contributor
timestamp: February 20, 2020, 05:47:54 pm
content: One problem I found with mBed is that not all boards implement all parts of it despite claiming to be compliant. I'm not sure if it's still true now, but some while back I tried to use ethernet on a board that was sold as working with mBed, only to find that it had a different ethernet controller to the one assumed by mbed, so the ethernet was not supported. Essentially, board suppliers have to generally provide some "glue" to make their boards work with mBed, and it seems some boards have more glue than others. And it is not just the smaller players who are at fault in this respect, either. A few boards have very good support - e.g. K64F, LPC1768. For others, check carefully.

author: JojoS
author_rank: Contributor
timestamp: February 21, 2020, 02:47:46 pm
content: yes, you're right, not all the boards have everything implemented. The support is also a matter of the board or MCU vendor. But now, many boards have a very good coverage of the features. The Mbed team and the community is steadily creating new features, so its hard for all vendors to follow immediatelyThe LPC1768 was the grandfather of Mbed boards, the Mbed API is implented by very direct register programming. That gives a very good performance, but adding new MCUs is a lot of work. Ethernet and USB were addons and the implentation was limited to a few targets. ST has used their HAL and have 'flooded' the market with eval boards. But they are able to add Mbed support very soon for nearly all the eval boards.Ethernet was revamped a few years ago and is now available on many boards. I'm currently using cheap chinese STM32F407VE/VG boards and Ethernet can be added easily by a PHY Module. Ok, that revealed some problem with the PHY code, but the Mbed team is open for issues and PR's.

author: rstofer
author_rank: Super Contributor
timestamp: February 21, 2020, 06:30:01 pm
content: Quote from: Karel on February 18, 2020, 03:00:58 pmNot trying to be a smart-ass but can SPI Slave at a high datarate be implemented on a Pi? I'm thinking in terms of clocking at 1 MHz or so, grabbing the data and stuffing it into a shared queue such that the user program can repackage the data and send it out over a TCP connection. For such a trivial application, I'm not sure what Linux brings to the dance. I don't think I'm capable of writing Linux device drivers.Back around 2011, I used the LPC1768 for this application and it worked well. All I had to do was add a MagJack to the mbed board (I built a daughter card) and it was off to the races. It's been working well so far.

author: GeorgeOfTheJungle
author_rank: Super Contributor
timestamp: February 21, 2020, 08:55:56 pm
content: Free RTOS is the dogs bollocks. Espressif (esp32), Amazon, Aliexpress, Google, NXP, everybody and his brother are using it for "IoT" things. There are plenty of tutorials everywhere, it's open source (https://freertos.org/), and youtube is full of vidjeos. This is the author speaking:

author: jnz
author_rank: Frequent Contributor
timestamp: March 01, 2020, 03:31:36 am
content: I’m sure mbed quality is fine. But.... if you are going to learn a new thing, imo it makes sense to learn FreeRTOS instead, used on more chips than just ARM and it’s got a much larger support community.A little advice I’ll pass on... you need as many threads, as you need statemachines, no more. People go thread/task crazy when they get an RTOS and have to learn that the hard way.