We've been working on the next version of the Mbed Tools for some time now, and believe now is a fine time to share additional details about why we've been working on new tools, the design goals of the new tools, and how we'll be rolling the new tools out.

Note: This blog post has been updated since first publication to more clearly describe the way that the existing tools are deployed with the Online Compiler and the value of the new tooling.

What's wrong with the current Mbed Tools?

As we've built and maintained our Mbed Tools for a number of years now, we've come to understand that Mbed Tools and their integration into the Mbed Online Compiler have a number of limitations.

Release effort

For users of the Online Compiler, one version of the Mbed tools must support all versions of Mbed OS 5.x and 6.x. It isn't feasible to change the Online Compiler to use the Mbed Tools shipped with the Mbed OS version the compiler is targeting.

During Mbed OS development, many changes land in the Mbed Tools (to various files in the tools folder.) Unfortunately, these changes are not routinely tested withprevious versions of Mbed OS or if they will work at all when deployed in the Online Compiler. At the point in time we'd like to make an Mbed OS release, the tools we would deploy to the Online Compiler have only been tested only with the latest Mbed OS.

We do have automated testing around Mbed Tools and the Online Compiler with multiple versions of Mbed OS. Unfortunately, there are gaps in the coverage and the test system takes around 16 hours to run and provide feedback.

All of this means for each Mbed OS release we have a very high likelihood of discovering late-breaking issues, with a lengthy debug-fix-verify cycle time. It’s a very error prone and manual process, making a release.

Given this release overhead, we are often too busy making releases to improve the tools. The tools have become an a bit of an unmaintainable mess which we can’t improve, as we are too busy trying to keep up with maintenance. It’s really inefficient to work on the existing tools, which slows down how quickly we can fix bugs or implement features you care about.

Organic requirements

The tools have a do-everything architecture that evolved organically over time. They try to be everything to everyone. That there are no clear public interfaces, documentation, or tests means we often break certain use cases.

Why do we need new tools?

Fundamentally, the issues with the current "legacy" version of the Mbed Tools are architectural. Because of this, we took the drastic decision to rewrite the tools (being sure to leverage existing open source tools as far as possible to reduce maintenance costs) something one should do rarely and as a last resort. The new Mbed Tools are tested with every version of Mbed OS they need to work with, throughout development. The test cycle time is faster, due to the priority given to unit testing over integration testing.

With a maintainable and clearly defined foundation, we are setting ourselves up to make a number of valuable improvements now and into the future.

Design goals for the new Mbed Tools

The primary design goal for the new Mbed Tools is maintainability. We also need more decoupling from Mbed OS itself, so that we can support the Online Compiler more easily.

Through increasing quality and clarity in purpose, the new tools aim to provide a better developer experience. We'll support this by providing a well-defined and documented set of interfaces for all tools. We also need to provide clarity around which boards are supported and work with which versions of Mbed OS.

Another goal is to have a dedicated test suite for the tools, rather than indirectly testing the tools through Mbed OS tests. These tests must test more than just the current version of Mbed OS.

I'm happy to share that, today, we have near-100% code coverage and, to help us maintain high code coverage, a per-pull-request CI job in place to fail if a change is added without sufficient tests.

It was not a goal for the change of tooling to be invisible to the user or developers. The emphasis was instead on ensuring a stable, maintainable and extensible tools; as such, the first release may not provide all current features. If there are features critical to your workflow, please let us know so we can prioritize bringing these features to the new tools.

While performance is a highly desirable characteristic, it will be second to maintainability. Incidentally, even though we didn't prioritize it, performance with the new tools is no worse than the existing legacy tools and should continue to improve over time. Adding the ability to use pre-built libraries can help speed up initial application build times further.

The new tools will support only the forthcoming Mbed OS 6 and versions that follow. Mbed 5.x users should continue using the existing legacy tools.

In the new Mbed Tools current shape, the working practices of Mbed OS maintainers and developers will have to change. Things aren’t necessarily done the same way anymore. For contributions to the tools, this is now done in the mbed-tools repo (rather than the mbed-os repo). How to add new boards or toolchains will also change.

How can I try the new tools?

We'll share more details on how to use the tools when the documentation becomes available. If you'd like to try before our how-to guides are ready, you can poke around in the new Mbed Tools repository where minimal instructions are available. The tools depend on CMake and work with the feature_cmake branch of mbed-os and mbed-os-example-blinky.

We aren’t going to get this perfect from the get go. There are gaps in everyone’s understanding of what these tools do and how they do it. Everyone has a particular corner-case that’s critical to their workflow. If you do try out the tools in their early state, please try out the tools in your use case, which is likely different from ours, and let us know how it goes. We need your feedback to make this work.

How are we rolling out the new tools?

Step 1: Freeze the current Mbed Tools with Mbed OS 6.2

We are freezing the current, legacy Mbed Tools. This will free up bandwidth from maintaining and releasing the tools so we can get these new tools in place in a reasonable amount of time. Changes to the legacy Mbed Tools are limited to absolutely critical issues only. Without freezing the legacy tools, we would not be able to focus on their replacement.

To enforce and communicate the freeze, from this point onwards, the Mbed OS per-pull-request CI will reject changes to tools in the mbed-os repository. Any changes to tools that would require a re-release of the tools for the online compiler will be rejected. This enables us to focus our effort on developing a far more maintainable set of tools, rather than on performing existing tool releases which are very error prone, time consuming, and labor intensive.

No new releases of the online tools are planned. To keep feature parity between the offline and online tools (and thus to keep the online compiler working), we are locking the Mbed OS tools. If we permitted changes to the Mbed OS tools, we'd risk the Mbed Online Compiler not working (either due to bugs or simply the lack of features required to build or configure Mbed OS).

Step 2: Support using both tools with Mbed OS

The new tools will be available for use with Mbed 6 within the next few months. We’ll take feedback onboard and improve the tools. You can use either the new Mbed Tools or the legacy Mbed Tools during this transition period. The tools can be used side-by-side. Both sets of tools can be installed within the same development environment without conflicting with each other.

Step 3: Drop support for the legacy tools

Finally, we will switch entirely to the new tools. The legacy tools will be unsupported at this point. The legacy tools will not be guaranteed to work for building the latest Mbed OS version after this point.

Summary

Thanks for reading. We hope you've enjoyed getting an inside view of how we are improving Mbed. We've discussed the fundamental limitations of the legacy Mbed Tools and Online Compiler, why we are building new Mbed Tools, what design principles we followed in the new tools design, and how we'll be rolling out the new Mbed Tools. Stay tuned for further updates as development progresses.