I’m unfamiliar with Mbed, and it seems to have reached a point where it is so well developed and powerful that the docs are extremely daunting to approach.
I’m kind of looking for a sanity check on what I think it does at the latest version, I believe that is 6.
Provides robust RTOS feature set. That I can wrap my head around.
Acts as an abstraction layer for supported boards, but I’m really unsure as to what it is abstracting. The RTOS APIs? GPIO pin mapping? Network APIs? Optimizations?
Acts as a custom tailored STDlib for your board… huge question mark on this one. When starting a project in the IDE it asks for a gig or more of space so it must be packing some heavy libraries of some kind I assume.
Something to do with sensor/module driver interoperability between boards? Maybe relating to the abstraction layer? Or libs?
I appreciate any help, whether entry level overview documentation for reading that my google-fu couldn’t find or answers from those more familiar with this platform.
First, mbed now comes in two flavors: bare-metal and rtos. bare-metal is for memory constrained devices and/or projects that don’t need multiple threads, just one main thread.
I2C, PWM, CAN, Analog, Network, SPI, UART, almost everything. You will also find them in the link above.
When using for example DigitalIn, mbed will rely on the HAL provided by the silicon manufacturer, for example ST.
If you change your board, most of your code will still work. You’ll have to make sure that the features exist in the two boards and that you update the pins you’re using. For simple things, it will be enough.
As you make your project more and more complex, changing board will be a little more challenging. But usually you’re committed to the hardware you use and should not be changing your main MCU every other day.
Mbed is using newlib (provided by arm-none-eabi-gcc) and the STL is also available. Not everything is working and you should always test code using new features and analyses the impact on code size, speed, etc.
The size of mbed comes from the previous point: being available on so many platform, mbed includes all the source code from all the silicon vendors and that’s a lot of files for a lot of targets. You can git clone --depth=1 for a lighter download, but it’s still a lot of stuff. In practice, you’re not downloading mbed all the time and you can even share an instance between projects.
If the libs are using mbed already, then it will be easy to port. If they let you define read and write functions for i2C for example, it will also be easy. What we usually do is make a C++ wrapper around a C low level sensor/actuator driver provided by the manufacturer. For example ST provides a lot of drivers for their mems sensors, so we pack that and use DI to inject mbed related components such as I2C or SPI.
This allows us to have a loose coupling between components, drivers and mbed-os.
Hope this helps and don’t hesitate if you need more info
