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/Kvasirhttps://www.voti.nl/bmptk/docs/index.htmlBut 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