[MBed CLI Alternative] mbed-cmake

Mbed OS
41

USC RPL is pleased to announce release 1.6.0 of mbed-cmake, with some pretty major changes!

Changelog

  • Added the ability to configure one project for multiple targets/boards at the same time.
    • To enable it, just pass all the target names to the configuration script, e.g. configure_for_target.py LPC1768 K64F.
    • Then, when you configure a build directory, you can select which target you want to build for using the -DTARGET option to CMake.
    • By creating two or more build directories with different TARGETs, you can build your code for multiple targets at the same time.
  • Official IDE support! mbed-cmake can now generate debug configurations for both CLion and VS Code when it detects it’s being run from an IDE.
    • I wrote a guide here for setting up VS Code.
    • NOTE: You now need to call mbed_cmake_finalize() at the end of your top-level CMakeLists.txt for this to work.
  • The MBED upload method has been updated (see prev post). It no longer needs you to pass in MBED_PATH. However, it now depends on the mbed_os_tools Python package.
  • Generated cmake files now contain the command used to invoke configure_for_target.py – prevents having to struggle to remember what options you used all those months ago
  • configure_for_target.py learned a new “-a” option, which allows you to specify a custom mbed_app.json location. About time, right?
  • configure_for_target.py learned a new “-x” option, which loads custom targets from custom_targets.json in the given directory. Thanks to @ladislas for contributing these two options!
  • Fix bug where mbed-cmake would fail to find the STM32CUBE uploader if STM32CubeIDE was updated in place
1 Like
42

Version 1.7.0 of mbed-cmake has been released! This version fixes something that I’m sure has been annoying a lot of you: the need to edit mbed_app.json and .mbedignore inside of the mbed-cmake folder. This prevented it from being used as a true submodule that could be used across multiple machines without needing to make changes. Well, thanks to pull requests by mjbogusz, that era has come to an end!

Two new options have been added to configure_for_target.py: -a and -i. These allow you to specify the mbed_app.json and .mbedignore files, respectively, that will be used when compiling Mbed OS. You can, and should, store these files in your own project directory instead of the mbed-cmake submodule. These files have been added to the example project, and going forward, the standard command to use when configuring it will be python3 mbed-cmake/configure_for_target.py -a mbed_app.json -i .mbedignore <target names...>

Note that there are some breaking changes in this release. mbed_app.json and .mbedignore are no longer included with mbed-cmake. If you have a project that was previously using the defaults of these files (e.g. you never deleted them or created your own), you will need to copy the files to your own project directory before pulling the latest mbed-cmake, then run configure_for_target as above.

2 Likes
43

Hi @MultipleMonomials, how does mbed-os work-in-progress cmake build system fare against your mbed-cmake? Do you feel mbed-os’ variant is in a workable state yet?

44

I would like some configuration system where I can add or remove features to shorten build time. Would this be possible with the new cmake?

45

Yes, that’s the idea behind the new build tools.

You usually don’t “add or remove”, you just add what you need. It will then take the time it needs to build only what you need.

But to shorten build times, you can also use tools such as ccache (https://ccache.dev/).

This will make subsequent builds faster even on slow computers.

Adding or removing features, when you use a lot, at some point doesn’t make much of a difference. ccache will.

46

Thanks for your quick reply. . .

47

Note that you can also do this with mbed-cmake – that’s what the .mbedignore file is for. The default mbedignore in the example project removes all the optional features and cuts the build time down by a factor of 3ish!

48

Version 1.8.0 of mbed-cmake has been released. This shouldn’t have any breaking changes, it just rolls up some smaller changes that’ve been sitting around for a while.

  • Bump bundled Mbed OS version from 6.9.0 to 6.15.0
  • Fix errors with targets whose linker scripts relied on macros from the configuration (#35). Thanks to Michael-Liao for reporting this issue.
  • Implement MBEDCOPY upload, which brings back the old copy-to-virtual-usb-drive uploading. This is mainly for WSL support (#32). Thanks to ProExpertProg for the PR.
  • Fix ability for a custom target to override source files inside Mbed OS by providing its own source files with the same names. This should have been possible in previous releases but did not work.

Enjoy!

1 Like
49

Also note that we are probably getting towards the end of the development period for mbed-cmake, as Mbed CLI 2 is getting close to feature parity with it. I have PR #14010 open on Mbed OS to implement support for uploading on the command line. Once that is in, there will be no real reason to keep mbed-cmake around anymore so I’ll publish a migration guide to the official CMake system. If you want this support in, please go and thumbs-up the PR!

Note that if this PR ends up being denied (not sure if they’ll reject it for duplicating functionality in the Python scripts), I’ll probably publish a small companion CMake library that implements uploading support instead. So you should have one-click command line builds with Mbed CLI 2 one way or the other.

3 Likes
50

BlackMagicProbe is also a great debug probe and should be support. It has an integrated GDBServer, so no additional tools are required and you don’t need configuration, except select the target no. when multiple targets are connected.
This probe can be ordered from https://1bitsquared.com/, but the software is open source on github:
GitHub - blackmagic-debug/blackmagic: In application debugger for ARM Cortex microcontrollers.
A bluepill board is suitable and also original STLinkV2 or clones can be used. I have used mbed-os to create a network connected probe, and there is even an ESP32 based port for a wireless debug probe. Ok, some wires to the target are still needed :slight_smile:

And I just created a housing for a STLink V3Mini:

1 Like