Rust for hardware vendors

Better support

For customers it's great when there is existing vendor support for the chips you've selected. But one of the biggest disappointments is not being able to make it work for your project, which can have many reasons. Rust tends to make this process easier in several ways.

We, the developers, all have our own workflows and code setups, and whatever our setup might be, downloading a zip file or installer is always extremely bothersome. We want to put our code in version control, we want new project members to be up and running very fast and we want to build our project on the CI server. Distributing your support package in this way isn't great especially if you need to update versions once in a while. Being able to pull it in as a git submodule is better, but also has many downsides.

With Rust there is a standard way for distributing packages with crates.io. Anybody with a Rust installation can make use of this central repository and you get package versioning for free as well.

Once we have the code/package and are able to use it everywhere we want to, we need to be able to build it or link it to our code. There are a near infinite ways to do that, ranging from shell scripts and make, through more advanced build systems like cmake and ninja, all the way to fully closed systems like visual studio projects. It's not doable to support all of these, so in practice we see that every vendor picks one or builds its own bespoke system.

With Rust, however, there's a standard build system called cargo which pretty much all Rust projects use. If you provide a so-called 'crate', then any Rust install can download it, build it and link it.

The combination of crates.io and cargo makes using a support package as easy as adding one line to the 'Cargo.toml' config file. Using vendor support should be easy and when I design hardware, that's also a big factor I consider.

An added bonus is that Rust also has a built-in documentation tool, rustdoc, so it's even possible to deliver your documentation in a standardized and familiar way.

All in all, with Rust it is almost trivial to get your support in the hands of the developers and have them successfully apply it to their project. This means you can deliver better support, without increasing your effort.

Easier platform support

So now we know that Rust is user-friendly. But what is it like to actually give the support?

Because of Rust's trait system, it's easy to make abstractions and this has been used to great effect by projects like embedded-hal. They define abstractions for common operations like SPI, I²C and GPIO. This means that if a device driver makes use of these abstractions, then that driver can be used from any platform that has an implementation. The inverse is that if you build microcontroller support and implement the embedded-hal for your platform, you instantly build support for all drivers that are out there.

This saves a lot of time of having to port drivers that either you or your end users would otherwise need to do. And if you thought supporting multiple platforms was never worth it, then that's not an issue anymore either.

Of course not everything you need is communication. Sometimes, especially for more complex support, you need concurrency. Traditionally this is solved by using some kind of threaded executor, an RTOS. But tying your support to one executor is not great. Sure, you can depend on freeRTOS, but what are your bare-metal and Zephyr users supposed to do?

Since 2018, Rust has a language level solution for this in the form of async/await. You don't need to know about an executor if you simply express what operations are asynchronous. Your users are then free to pick the executor of their choice (or not even use one at all).

So again, Rust makes it easier to support more of your users' use cases, without increasing your effort.

Lower maintenance effort and costs

Maintaining software can be hard and costly. And if you have to maintain a lot of it, that burden had better be as light as possible.

You want to minimize the bugs in your support package. This is obvious of course, but bugs have two costs: users are going to ask questions that somebody needs to answer, and the bugs require fixing.

With Rust it's much easier to write correct software and that's not only due to its memory-safety - though let's not understate how good that is - but also due to all the different language features Rust has.

For example, with the combinations of macros and traits (where the macro auto-implements a trait for a type) you can quickly implement functionality without introducing bugs. Of course bugs do still exist in Rust code. But with some care and good use of the available tools, the number of bugs can be reduced significantly compared to alternative options.

Using the type system can also make your APIs very insightful. A good example is the open source DW1000 driver, which uses so-called 'typestate' to limit what chip functions are available to call in different chip states at compile-time. For example, the function wake_up can only be called when the chip is in the Sleeping state.

This kind of API design will make users more confident and more likely to use the API correctly, leading to fewer questions.

Google have also started using Rust more and they regularly blog about it. Particularly interesting is their observation about Rust code being much easier to review:

More than half of respondents say that Rust code is incredibly easy to review. As an engineering manager, that result is in many ways at least as interesting to me as the code authoring results, since code reviewing is at least as large a part of the role of a professional software engineer as authoring. - Lars Bergstrom

In short, Rust allows you to offer support that requires less maintenance.

Become a leader in a growth area

Rust is not used as much as C or C++ in embedded development, but that doesn't mean it will stay that way. I can't predict the future, but looking at the current developments as somebody who helps companies start out with Rust, I am seeing noticeable interest in Rust. For example, Tweede golf have given Rust training at:

• Sioux Technologies
• Netherlands Aerospace Centre (NLR)
• TomTom
• Nedap
• Netherlands Organisation for Applied Scientific Research (TNO)

There's also Renault's EV innovation project "Ampere" using Rust and it's known that Volvo has been using Rust for quite a while now.

My expectation is that embedded Rust will continue to grow in the future and that more and more of your customers will be expecting or demanding Rust support.

Even right now, with a comparatively small userbase, it might still be worth investing in Rust support. If you have official Rust support, everyone doing embedded Rust will know about it. Before Espressif started supporting Rust, I'd hardly ever seen anyone running their Rust project on one of their chips. But now that they do, I see lots. So Rust can definitely help you grow.

One final thing to keep in mind is that supporting Rust doesn't have to be an all-in endeavor. Support can come in many forms. You could wrap an existing C package or support an existing open source effort. If your support is in the form of a static binary, that binary could be written in Rust. And even if you only have a Rust driver, you can still let C users use it, which is less work than supporting two drivers.

If you want to explore the opportunities or clear technical hurdles, my colleagues and I can help you take the first steps, or even carry the project from idea to the finish line. Feel free to contact us with your case and we can discuss how you could support Rust and whether there are any pitfalls.

Image credits

• Background: https://depositphotos.com/
• Rust logo: https://foundation.rust-lang.org/