Embedded Commercial Rust Gaps

[johnthagen]

Overview

This post is a summary of the our evaluation of using Rust for an embedded project, and the gaps we hit and why we ultimately decided to use a subset of C++14 instead. This is from a team that wanted to use Rust, but ultimately couldn't justify it in its current state.

Goal

We needed to build an embedded application that utilized CAN, UART, and GPIO. We wanted to use a common, popular embedded platform so we decided to start with the STM32F3DISCOVERY, later also using the STM32F4DISCOVERY.

The Good Parts

1. The Discovery Book - so great!

2. Rust itself, for its safety and correctness

3. The community!

4. Embedded on stable Rust (big win)

5. Smaller feature, but iprintln! is much easier to use on Rust than trying to get ITM working on C or C++

Gaps

1. There is no CAN support in embedded HAL. This was a show-stopper.

   • [WIP] CAN Interface take 2 embedded-hal#77
   • CAN/CAN-FD API? embedded-hal#21
   • CAN discovery#92

2. Edit: The community has already answered this one! At the time, we couldn't use (or couldn't find the right resource for) dynamically sized heap containers like Vec<T> (heapless is fixed size only). This was a clear drawback compared to C++11/14 in the gcc-arm-embedded toolchain.

   • How can dynamically sized Vec<T> be using on STM32? #335
   • RFC: Stabilize the alloc crate rust-lang/rfcs#2480 (comment)

3. Quality of less-popular chip support. The STM32F3DISCOVERY we were fairly confident in the support for, given the nice Discovery Book and that the crates were being maintained well. But we were a little concerned if we needed to move outside of that particular chip (to an F4, F1, different pinout) about the quality of the other HAL implementations. We sometimes found multiple crates doing the same thing (e.g. Consider collaboration with stm32-rs? ArcaneNibble/stm32-unified-crate#1). This was a more qualitative assessment (and was done several months ago).

External Gaps

These gaps I view as more outside the scope of the Rust community directly, but I wanted to mention them because they did affect our decision making.

1. STM32CubeMX support. This is an STM product that allows you to quickly generate C code using their C HAL. This C could then be wrapped in a C or C++ application. This GUI configuration tool was very helpful, especially combined with the numerous examples that come with their HAL. If STM were to support Rust in some way with this tool, it would be a huge boost to Rust usability.

2. No Rust debugging for embedded in intellij-rust / CLion. For C and C++, we could single step debug our STM32 code from within CLion and get all of the nice IDE features and debugger windows you would expect. CLion already supports debugging of desktop Rust (x86) applications. No doubt JetBrains will eventually support this in CLion with their latest push to support STM32 for C/C++, but at the time this was a drawback. The Discovery Book did have an excellent guide for Rust debugging from the command line, so that definitely mitigated this drawback some.
   • Support programming/debugging STM32 microcontrollers intellij-rust/intellij-rust#2748

[jamesmunns]

Hey @johnthagen, it sounds like it might be a bit late, but if you are looking for commercial support, or filling in gaps in the ecosystem for your project, my company Ferrous Systems is happy to discuss. Feel free to send me an email if you'd like to discuss further.

Either way, thank you for providing the report of what you found lacking, we (the embedded-wg) also have just started a resource to track issues like this in our Not Yet Awesome Embedded Rust list, it would be great if you could add these items there, or I can move them later this week when I have a chance.

[jdemilledt]

I'm currently working on the front of the lack of CAN support. The current blocker is determining an interface that can be implemented by all.

[jamesmunns]

Thanks again for the report @johnthagen, closing this as part of the 2024 triage effort.