Arm Mbed OS support forum

I need help to understand the way Mbed OS makes things "simpler"

Please forgive me if I am talking about has already been discussed or it is a wrong topic.

How I got here:

I am an embedded engineer, who has mostly used STM32 MCU-s, and for programming they used STM32CubeMX generated templates. From the tools, I have tried many things - from Keil to Eclipse-based solutions like STMWorkbench and Atollic True Studio.

Most of the programming I do is for the custom cost-optimized boards that we manufacture in hundreds to thousands.

I have a new project that uses the STM32L422 MCU (the cheapest one that meets the requirement) and ublox SARA G450 GSM/GPRS modem.

I thought about going my usual route - use the FreeRTOS and write most of my libraries. You can imagine my excitement when I found Mbed OS that has official ublox libraries, and so many features- HTTP support, device management, OTA updates and so much more!

For the last week, I have been trying to configure Mbed for my use, unsuccessfully so far.

It seems like the Mbed isn’t targeted for serious people who actually want to use their own hardware? Because everything is targeted for “officially supported boards” - the boards that no one will ever use in production.

For example, my board will cost me about 30 EUR in production, but a similar functionality board like u-Blox C030-U201 costs about 150 EUR. And that is okay, devkits are usually expensive.

But then why is PORTING MADE SO COMPLICATED for any other “unsupported target”? It even seems like most of the porting documentation is targeted for people wanting to make their board public - which is almost never the case with proprietary designs. I am not interested in making an official bord and I don’t need to run all of your tests, I just need to use the OS as-is.

Why is everything so focused on USB copy/paste programming when that doesn’t work in series production? Why are IDE/development tools so archaic? Where is line-by-line debugging?

You have to dig to find anything, and you have to dig even harder to find anything on working with custom designs - and even then on forums its a link to the official porting page that both have too little and too much information.

Am I missing something? there are apparently 40 big companies using this in their devices, in production, making smart lamps and such - but all resources available are from people using NUCLEO boards?

Hi @aoreskovic! –

I went through the same process as you and struggled a lot with our custom design.

We saved our selves a lot of time and issues by using an “officially supported board” as a template to create our own. In the process we gained a deeper understanding on how and why mbed works the way it does.

We are a very small team ( 2 devs with basic electronic skills) and we decided to use mbed for the same reason as you: it provides a lot of things!

Our design process mainly consisted in finding the right MCU, modules, flash, etc., that would meet our requirements and still be compatible with mbed. We spent countless hours diving in hundred pages long specs to make sure things would click and work. We changed modules at the last minute because of one line we missed somewhere.

In the end, our custom board works great, we don’t have (or very little) to work on the low level drivers, we can spend our time on the application and on the few modules (Bluetooth BM64 to be precise) for which we need to write our own drivers.

Our board has:

  • STM32F769
  • MIPI-DSI LCD Screen
  • QSPI Flash
  • BLE
  • Wifi
  • Bluetooth
  • Audio
  • Motors + driver
  • Sensors (a lot!)
  • LEDs
  • etc.

Regarding tools, we really don’t like IDE that hide all the magic behind, where configuration is made by checking boxes in a GUI and that don’t work well with SCM such as Git.

So we do everything from the command line. I wasn’t able to configure vim for autocomplete easily, so I use Visual Studio Code and the mbed-vscode-generator.

Regarding creating a custom target, I’ve only worked with ST and once we understood the structure, the ideas and the tools available, it was quite easy to create new target.

As you mentioned the porting guides seems to tell you to share you target but in practice your don’t have to. You can just have your own target directory in your app tree and create a custom_targets.json with the info needed.

I’m happy to help if you have more specific questions.

Best,
– Ladislas

Hi Ante,
maybe you should ask more detailed questions.
There is already a large section in the documents, but porting to custiom board is really an advanced subject:

The good thing is, Mbed-os has become very stable due to lot of testing. That can be done only with common hardware. And specially for STM, there a now a lot of similiar MCU that can be used as a template for deriving new boards. However, this is an error prone process and Mbed is very agile, so there are breaking changes because your hardware is not covered by the tests.

For the L422, the L432 looks similiar with less resources. So the way is to start with creating a custom_target dir and add the target specific files and the custom_target.json description.
You need to adust the linker script, the clock configuration and peripherial/pinnames.
The bonus is that you get lots of stuff like rtos, filesystems and connectivity for free.

I debug on Nucleo boards with GDB. I reflashed the on-board debugger to Segger so it works properly and stops popping up as a mass storage device. With a custom board you won’t have these problems, you can place your preferred debug header.

For building I use mbed-cli in Docker. The ELFs show up in the build directory. I use a makefile to flash and load GDB and so on.

I think Docker is essential for managing tools like mbed-cli. It has particular Python dependencies that will conflict with the rest of your system.

+1 for Docker! Need to set on up for my team as well.

If you have any feedback or documentation to share, let me know :slight_smile:

As always, I suggest giving my mbed-cmake tool a shot for any serious, long-term embedded project. First and foremost, it concentrates all dependencies in a single repo, removing some of the worries associated with how Mbed downloads/updates things from the Internet and guaranteeing that it will work exactly the same years in the future. Also, it lets you use almost any IDE you want (including VS Code and CLion, which are both very capable), or just build and upload code from the command line.

Also, re boards, my team has been using a custom PCB in our avionics unit for years, but we still have it configured in Mbed OS as the “dev board” for that chip. This works just fine as long as some of the basic PCB components (such as the clock IC) are the same type as on the dev board, but yeah if you wanted to changed those then you need a custom board.

My Docker file isn’t in version control but it’s based on this on this one.