MBed, yea or nay?

[westfw]

I haven't seen much love (or hate) here for the MBED development environment, compared to Arduino, Cube, ASF, and etc.I personally haven't paid much attention to it since "the bad old days" when it was rejected for being "cloud-only", but I keep seeing hints that a lot has happened since then (cloud-requirement gone, MBED-OS, etc.)
Is it worth taking another look?

[rjp]

It is true it needs the bigger ARM chips with larger flash - plenty of libraries you need to trim manually or tolerate wasting space.

Ive personally found the offline mbed-cli version of it great for when i want an RTOS with all the batteries included.

the STM32 version i use has a fairly obvious layering of stm hal - > arm cmsis -> mbed rtos so you can easily use low levels functions when you wish.

Its probably no good if you are a high volume, saving cents per part type of person, the projects I do tend towards saving money on developer time being worth more than a dollar or two on the parts.

The original online only version was a stinker, I gave up on that quickly.

[rstofer]

I have a few of the original LPC1768 mbed boards and I like them a lot.  I also use the online toolchain and it works fine.  I don't get any kind of JTAG debugging but I can certainly use printf() which is more productive anyway.

I have downloaded my projects and the associated libraries and then build the same code using Rowley Crossworks but I think any GCC based toolchain will work just as well.

One of the very cool things about the online tools is the ability to work on your code from any computer in the world.  Any browser, any place.

My major project, a few years back, involved TCP/IP and I didn't want to have to write the stack.  MBED already had lwIP working so I just dropped it in and followed the yellow brick road.  Works well!

I am aware that many STM boards are MBED compatible and I think I tried an example but I haven't done a project involving those boards.  No reason, really, it just hasn't come up.

[jnz]

It's ARM's Arduino.

[ebclr]

"the bad old days" when it was rejected for being "cloud-only"


That's not true you can do offline also, just need to export and use Keil

[janoc]

Just be careful with the board selection - if you use anything except the original LPC1768 based boards, many libraries/peripheral drivers will simply not work or not be available.

E.g. many of the ST's Discovery & Nucleo boards are labeled as mBed compatible but it only means that you can compile some blinking LED code for them using it. Not that there is a meaningful software support. Do your homework if you are planning on investing into this ecosystem.

It's ARM's Arduino.

That's quite generous to mBed. Compared to Arduino the documentation sucks (or doesn't exist), lots of the libraries don't work on many of the ostensibly supported platforms and the community/ecosystem around it is not even close.

Seriously, one can dismiss Arduino as a kid's toy but if there is one thing that they got right it is the ecosystem. Documentation is easy to find, there are plenty of working examples to work from, the stock libraries are very much guaranteed to work on all supported platforms (as long as the required HW is present) and there is a large user community around it.

[emece67]

.

[rjp]

The board listing on the site lets you know which chipsets have the full RTOS support and which ones are only poorly supported.

As for the doco, it puts the entire source tree   in your project code so you can prune it or read it and confirm behaviours to your hearts content. If I plug a class name into the search facility online, it so far has always returned a useful overview.

the only similarity to Arduino is that its a C++ framework - unlike the simple blocking model used by the Arduino libs its a fully fledged RTOS, based on the "RTX implementation of the CMSIS-RTOS API"

Its not perfect but it has come along way to the new offline version 5 .

[janoc]

The problem is not the RTOS support that much. The CPU core is not all that different between the ARM families, so this is quite trivial to make work. Moreover, the mBed RTOS is quite recent add-on that isn't that popular.

However, MCUs are all about peripherals and e.g. USB, ethernet or even basic stuff like timers is hit and miss, even between chips that have the same peripheral on them (supported on one, not on other e.g. USB on STM32F072 vs STM32F042 if I recall right).

And finding out which peripheral is actually supported on which board is a stupendously arduous task, sometimes involving trawling their crappy forums for a few hours only to find an obscure post saying "Oh sorry, that doesn't work on XYZ" ...

Then there is the problem of code size - as emece67 said, you can get tens of kB even for trivial code. I didn't use Keil but gcc so I didn't have a code limit but I certainly did have a problem when you have something like STM32F042 Nucleo board from ST sold as "mBed enabled" - and even a simple program blinking a few LEDs can take upwards of 20kB of FLASH (that chip has 32k total). Add an UART and you are out of memory already ... So even if that USB was working on that chip (it wasn't at that time), it wouldn't have been really usable because you wouldn't have been able to fit it in memory ...

Oh and even better - when ST was selling these boards already the mBed compiler had no support at all for them for several months. So you couldn't even build a blinky LED out of the box with it, despite the board being "mBed enabled" ...

The same code, implemented using something like libopencm3, was <10kB and probably could have been reduced even farther. The main reason is that mBed uses the ST's bloated HAL libraries for the ST chips. This basically constrains mBed only to the high-end chips with a lot of memory - but then there you aren't able to use (apart from writing your own drivers) many of the advanced features of those MCUs because they aren't supported.

mBed was good project while it was independent and targeting only the NXP MCUs. After they have been bought out by ARM it seems to seriously lack both manpower and actual polish to make it into something usable. It feels more like a marketing stunt (all those meaningless "mBed enabled" labels) than anything else today.

[the_janitor]

I've been using it for a while and it's not bad (I previously used FreeRTOS). The problem, as some already have pointed out, is that the drivers/libraries are ported by the community with no real supervision; sometimes you're lucky and everything works as intended, and sometimes you need to find the issues yourself (bad porting, registers/operation mode conflicts etc.).

Having said that, size can be trimmed down quite significantly if you mess with the generated Makefile. Also, you can fully set up your project offline (at least on linux) and use your editor/ide of choice (e.g. visual studio code).

Also, it saves you a lot of time if you intend to use stuff like TLS (mbedTLS).

[mac.6]

one of the only usefull stuff of MBED is TLS library (aka mbed tls). Since it's apache 2.0 it is used a lot in industry.

[rstofer]

one of the only usefull stuff of MBED is TLS library (aka mbed tls). Since it's apache 2.0 it is used a lot in industry.

How about the network stack (lwIP) for the LPC1768 version of mbed?  It sure saved me a lot of effort.  Just drop it in and handle it in a state machine.

I don't know if this library works on the other 'compatible' boards.

[mac.6]

lwIP is not a mbed owned library, it's also used on a lot of other MCU/RTOS flavor.

[rstofer]

lwIP is not a mbed owned library, it's also used on a lot of other MCU/RTOS flavor.

Absolutely!  But things were a little different in January 2012.  lwIP had been around for a long time (about 10 years at that point) but it wasn't nearly as popular as it is today.  uIP, a predecessor, was in use but it had the disadvantage of only allowing 1 packet in flight.

I'm not sure when FreeRTOS included lwIP but I don't recall seeing it in 2012.  FreeRTOS for the mbed LPC1768 wasn't included in the mbed libraries until quite recently.  In fact, all these other mbed 'compatible' boards are pretty recent - like after ARM bought out mbed.

Things change - sometimes they improve...

[richardman]

MBed was designed for a different world, IMHO. It was a way for ARM to say: ARM MCU is one big happy family, but of course the reality is that the peripherals are in fact the differentiating factors between different ARM MCUs.

We are now ready to release our "JumpStart IoT" with our own REXIS kernel, lwIP, mbedTLS, plus MQTT, NTP etc. The mbed stack is too high level, IMO.

[donotdespisethesnake]

MBed was designed for a different world, IMHO. It was a way for ARM to say: ARM MCU is one big happy family, but of course the reality is that the peripherals are in fact the differentiating factors between different ARM MCUs.

We are now ready to release our "JumpStart IoT" with our own REXIS kernel, lwIP, mbedTLS, plus MQTT, NTP etc. The mbed stack is too high level, IMO.

As soon I saw the name "richardman", I knew there was going to be an advert, and I wasn't wrong. It seems you mainly use the forums here as a vehicle for spam.

Did you ever think of paying for ad space instead of spamming?

[richardman]

As soon I saw the name "richardman", I knew there was going to be an advert, and I wasn't wrong. It seems you mainly use the forums here as a vehicle for spam.

Did you ever think of paying for ad space instead of spamming?

I am sorry you feel this way. I have contributed to a number of threads without mentioning our products, but obviously it was not enough.

[Doctorandus_P]

I have tried to do some very small evaluation projects for Mbed, both with the "blue pill" STM32 board.
I started with a blinking led & platformio. Got this working fairly quickly.

Next project was a potentiometer on the ADC, a bit of scaling and then ouput to a 1.5 to 2.5ms hobby RC servo.
I also got this (sort of) working fairy quickly.
One thing about Mbed over "arduino" is that in mbed objects are not pre-instantiated.
You can declare a timer (adc, uart, whatever) object, give it the name you want, and then use the library functions to do with that timer object what you want. Just as it should be with C++.
With "arduino" it is almost impossible to write your own libraries, because all the hardware is occupied with the arduino libraries.
If you want to do anything outside of the arduino framework you first have to dive into the framework to disable the code for that  peripheral.

It was very easy and intuitive to use the lib functions in mbed. Instantiate an ADC object, and read from it. You will get a (floating point) value between 0 and 1. (I think that working with floats is reasonably OK on a 32 bit uC. A lot of the mbed uC's have hardware support for float operations anyway.)

But a bit later my opinion of mbed plummeted somewhat.
The RC servo was jerky and here were loads of glitches in the PWM pulses (As seen on my Rigol Scope).
To debug that instantly means diving into the library code, and that looked quite messy for the STM32F103C8T6 I used.
In the background it uses the ST libraries, which are notoriously badly written, and on top of that some C++ is sprinkled to make some stuff that seems to work on first sight. I did not spend too much time to get it working though.

Next project was an example project for the USB peripheral.
Idea was to use the STM32 as a USB <--> UsART dongle to toy a bit with a simple USB application.
The example compiled into 70kB+ and my "blue pill" only has 64kB, so I did not even try to flash the chip.
I've heared lots of rumors that the STM32F103C8T6 actually has 128kiBi of Flash, but such an amount of code bloat makes me apprehensive of even wanting to go further with it.

I've also looked briefly at other ways to get started with those "blue pills", but it confuses me untill I get completely stuck, throw it aside and go do something else.
Initializing objects with templates sems to be a very nice and powerfull way to do things.
Examples:
http://xpcc.io/getting-started/
https://github.com/kvasir-io/Kvasir
https://www.voti.nl/bmptk/docs/index.html


But as I'm only a hobby programmer I've decided that the template stuff is a little too "advanced" for me.
LibopenCM3 seems to be old and/or not well maintained.
ST seems to have another framework every 3 years or so, some usable, others horrible, but what will they do next year?

As it stands now, I tend to use stm32duino.
I quite dislike the (lack of) filosofy behind arduino. It is not a platform intended for programmers, but for "artists" (whatever that means).
The Idea I'm thinking about is to make a fork of stm32duino, then drop the idea of wanting to be compatible with "arduino" (The horrible pin number scheme is the first for the garbage bin).
Then all pre-instantiated objects will dissapear, so all peripherals can be used in the way I want them to be used.
The final result will be something inbetween "arduino" and "mbed".
I also have no intention to update the whole "arduino" framework. Main goal is to disable most of it to make the flash image pretty small, and then use the code in the stm32duino framework as example source code to write my own library functions the way I want them.
And then after some time I have some lean C++ objects which only get instantiated when needed.

Last:
I found this in my notes. It may be worth reading:
https://hackaday.io/project/21045-stm32-bluepill-frameworks-evaluation