"Arduino for STM32" vs "mbedOS"

Hello everyone!

I’m curious if anyone tried mbedOS for STM32 programming.

What are impressions and pros./cons. comparing to Arduino for STM32?
Also, what MCU or boards were you using it for? What tools (like IDE, etc.) did you use?

P.S. I’m not trying to make a holy-war between 2 options.

Moderator edit
Official modules
Official boards

Mbed OS
Arm Mbed OS is a free, open-source embedded operating system designed specifically for the “things” in the Internet of Things.

It includes all the features you need to develop a connected product based on an Arm Cortex-M microcontroller, including security, connectivity, an RTOS, and drivers for sensors and I/O devices.

Mbed has a more professional API. But I don’t like the online compiler so I mainly use the Arduino things. And I think there are more libraries for Arduino.

If you are talking about mbed+stm32 .. last I looked it was a bloated API sitting on top of the bloated STM32 HAL API. Has that changed?

[Rick Kimball – Thu Oct 11, 2018 1:22 pm] –
If you are talking about mbed+stm32 .. last I looked it was a bloated API sitting on top of the bloated STM32 HAL API. Has that changed?

Yes it changed, now it’s more bloated.

Aaargh…

I do not understand the “draw” of web-development; outside perhaps the classroom. If the FBI, the CIA, Equifax, Facebook, etc. cannot keep their servers secure, then what chance do we mortals with a hobby-level project budget have? Now, I do dearly believe in services such as github where code can be sync’d and version control enacted… it is a sensible product for open-source.

The whole web-hosted, web-application marketplace reminds me of the advertising manager that went running to engineering and shouted, “… we have a new slogan, now we need a new product.”

Ray

I have returned to MBED several times with the thought that “now it has to be better”, but several times I have left because “it was even worse”

I trued mbed for the Nordic nRF51 series a few years ago, but the API had all sorts of issues, so I went back to using the manufacturers own core API direct, and compiled on my own machine, ( since Nordic support the Gcc toolchain)

I also tried Adobe’s online android app development system, but it was terribly slow using the online interface and waiting to be scheduled to compile in the cloud.
So I ended up using Cordova on my local machine, which is 100 x faster then the virtual processor you get allocated on the cloud.

Plus working locally you have 24 x 7 access to you own files, and and use whatever tools you want to edit, search and process them.

For business , I would never rely on the cloud as the primary means of operation. On numerous occasions I have had either internet outages, for at several hours, sometimes at critical stages in a project.

I put my whole “arduino” sketch/libraries/hardware folder into a google drive folder. So I can work 24/7 offline or online and after sync I have it on every other machine. I don’t need something else. For “cloud” use, I set only the permissions for each folder. I don’t think there is an easier way to do that.
Maybe a better option would be building a super slick linux (slackware?) VM Virtual Box image (for each project) so you can use it many years in future without problems.
Maybe this would be a funny competition in this forum:
Who builds the most lightweight fully working STM32duino VirtualBox machine?

OK. I noticed, most commentators are discontented with the fact that compiler is an online tool and this service is down quite often.

Let me share my experience:
– IDE : VS Code + PlarformIO plug-in + mbed framework
– Target boards: BluePill, MapleMini, Nucleo-L432, Nucleo-F411
– All sketches / libraries were stored on Google Drive (now I want to try also with OneDrive) and synced between several computers. No problems with work offline observed.
So, “online-dependence” is not an issue.

Based on my experience:

Pros (+):
– some parts/libraries are working more stable (*)
– mbed library has more supported parts (sensors, screens, etc.)

Cons (-):
– has a low variety of libraries (in PlatformIO catalog), but you can install all from mbed site manually
– the libraries written by community are written without “standards”. If you need to use use several devices on same bus (let say I2C) some parts will be created as object with direct mentioning of pins, other will require you to create the I2C instance and transfer it to constructor of object class, some others will ask you to mention pointer to bus.
– with BluePill and MapleMini – need to use ST-Link for programming, unable to use serial via USB (theoretically, can be done with USB-UART adapter, but I didn’t try)

(*) I had a little project, where I needed to use Sparkfun BME280 sensor module (on I2C1) and show info Adafruit ILI9431 screen (on SPI1), both connected to BluePill. With STM32duino I’ve got white screen after several days, with mbed – works fine.

P.S. I also tried Atom + PlatformIO, but moved to VSCode, since I’m using Atom for Python programming.

[mrburnette – Thu Oct 11, 2018 4:07 pm] –
Aaargh…

I do not understand the “draw” of web-development…

+1000 (including “Aaargh”)

[Just4Fun – Fri Oct 12, 2018 9:00 am] –

[mrburnette – Thu Oct 11, 2018 4:07 pm] –
Aaargh…

I do not understand the “draw” of web-development…

+1000 (including “Aaargh”)

It just keeps getting better and better. Now they want to replace native software with alpha-web-only-fake-apps. My 486 @ 33MHz had a less laggy UI, in 1989. It’s the future!

You can export the web-based project to offline toolchains, ex. Eclipse:
https://os.mbed.com/handbook/Exporting- … toolchains

I recalled the first time I tried Mbed on my Stm32F401RE board 2 years ago, just want to know how easy it could be, so I compiled a simplest project “breathing led” which increases then decreases pwm duty-cycle of the on-board led to make it fade on/off within the loop, with the Mbed pwm api. That time I forgot to add delays in the loop and … still seeing the light breathing in a 1-2 seconds cycle. It’s so terrible that those pwm apis have such performance on a cortex-M4 84mhz mcu.

stm32duino(s) is lean, mean and probably a best one out there on stm32 (mm/bp) for now, i’m yet to see any serious ‘competitor’ (not even mbed come close)

Pros (+) mbed:
Mbed works good without cloud compile in mbed-cli mode.
Doesn’t see on STM32Duino yet: stable CAN-bus driver (works on mbed LPC1768 (2 CAN transivers at once), STM32F103, etc..), LWIP ethernet hardware (works on mbed LPC1768, STM32F407 etc..), TLS libraries.

Actually stable and robust code on mbed for LPC1768, LPC11Uxx, LPC1114, STM32 part a little bit worse (thanks HAL and the late start of support for STM32).

First I ignored the whole mbed website, exept for comparison of development boards. (> 100 on that site).
When I noticed I could compile for mbed with Platformio on my own pc I did a small example.
The start was very easy,
My example project was to controll a RC servo with a potmeter and the program was:

1). Read adc.
2). Scale adc value to 0.5ms to 1.5ms interval.
3). Output pwm.
4). Repeat.

Mbed’s idea of reading an ADC is to return a float between 0.0 and 1.0.
I do not know what the cost of a float on a STM32 is, but I think you need an F4xx for hardware floating point support.

My simple loop caused lots of glitches on the PWM signal. It seems that writing a new value to an already running PWM glitches the PWM output, while in my opinion it should only update the compare register, so I had to add my own delays, and not update the PWM too often, and I did not like that at all. I fully expected something so simple to “just work” (flawlessly).

Mbed is also written on top of cmsis and neither seem to be given much thought on structure, or made by men in suits with grey beards.
Diving into 5 or 6 layers of function calls to find empty initialisation functions is not something that encourages me to want to use it.

mbed also seems to have 2 versions. A “simple” version and a “RTOS” based version.
RTOS adds un needed complexity to small uC programs. They are good for managing big projects which would otherwise bee too complex to manage, but my typical uC program is much better of with a few small polling loops and well placed ISR routines. Simply avoiding the overhead of the constant thread management gives a significant speed improvement.
It looks like mbed tries to abandon the “simple” version in favour of the “RTOS” version. These 2 combined caused me to abandon mbed. Maybe I’ll port a mbed library if it has some nicely written code in it.