8 ms·

This Year in Embedded Rust

144 points by eldruin 5y ago

DoingIsLearning 5y ago
It's great to see a community forming and the general enthusiasm. But are there any vendors actively participating in or supporting Embedded Rust? For example is any vendor porting drivers to native Rust?
- eldruin 5y ago
  Espressif (the makers of the hugely popular ESP32/ESP8266/... microcontrollers) hired an embedded Rust community member to work full time on Rust support for their chips: https://mabez.dev/blog/posts/esp-rust-espressif/ https://mabez.dev/blog/posts/esp-rust-espressif/
  - stbtrax 5y ago
    Does Espressif have large marketshare outside of hobbyists?
    - keewee7 5y ago
      The ESP chips are in pretty much all cheap Chinese-made IoT and Smart Home devices.
- howenterprisey 5y ago
  There's at least a decent amount of interest from both industry (auto tier 1's, for example) and from vendors; I'd love to name names here but I'm pretty sure I can't. :)
- follower 5y ago
  > But are there any vendors actively participating in or supporting Embedded Rust? That's kind of an interesting question. While obviously vendor participation can lead to some positive outcomes; my impression is some part of the motivation for Rust targeting the embedded space (and not waiting on vendors) is to avoid reliance on hardware vendors. Due largely to the poor reputation hardware vendors have in regard to anything in the software tool/firmware space within the C ecosystem.
- steveklabnik 5y ago
  In addition to what others have said, ARM has participated in the RFC process, donated CI resources, and joined the Rust Foundation. There are also a large number of things going on in industry that aren’t yet truly public. Some of these are the “I know something I can’t say” variety and some are the variety of “wow another car manufacturer has posted an embedded Rust job?” Exiting times ahead.
AlexanderDhoore 5y ago
I really hope embedded rust can become the next rock-solid foundation. I need my code to build/run today and also in 10 years. We have code in our codebase from at least the early 90s but I suspect it's older than that. I went into embedded because I really despise the code churn of higher level frameworks/languages. "We just released Qt5! Good luck rewriting your code."
- OtomotO 5y ago
  For me, even in high level, an API should only be broken, when/if it gives a benefit over the old approach. Sadly quite often it's only new and shiny to sell something :/ I assume in embedded this is simply different, because the needs are others.
- zibzab 5y ago
  If that's your goal I think you should wait a few years before starting using Rust. We have already seen early Rust code not compiling with new compiler releases. Right now we are in a move fast and break things phase. Also, you need to be careful about what you implement yourself and what you import from crates. Otherwise it will be qt5 all over again.
  - CodesInChaos 5y ago
    > We have already seen early Rust code not compiling with new compiler releases. Are you talking about breaking changes in the compiler after Rust 1.0? That should be very rare, and generally easy to fix (e.g. by adding a few type annotations). Or did you use unstable features? (Not sure if embedded is usable without unstable nowadays)
    - eldruin 5y ago
      It depends on your target architecture. For example, embedded development on ARM with stable Rust has been possible since 2018 (Rust 1.31)
  - Lorkki 5y ago
    > We have already seen early Rust code not compiling with new compiler releases. I haven't really seen that happen with post-1.0 Rust, which is everything onwards of early 2015. I believe they've since tightened a couple of edge cases due to soundness issues, but nothing worse than that. Would be interesting to hear about your contrary experiences.
zibzab 5y ago
Two things have kept me away from embedded Rust before 1. A huge chain of dependencies. Security issues aside, I prefer my embedded code to be lean and clean. 2. A big departure from how things used to be done in this world. For example interrupt handlers almost look like AWS lambda code to me. Maybe that's the future, I don't know. But right now I am not comfortable with this way of doing low level coding. But I am keeping an open mind and will probably try it again soon. I can see myself using Rust instead of C in more projects, but maybe first after things calm down a bit. I want my development environment outdated and boring, a.k.a. "stable".
- stevefan1999 5y ago
  Using Rust mods is exactly being lean and clean: would you rather take a bunch of include files, stupidly duplicates them in almost every translation units, and this would eventually blows up at some point of time, and is hard to reconfigure with some mysterious macro induced error, or, would you inter-depend on bunch of crates that might pull over 100mb of stuff at total that might have potential supply chain attack because it is too convenient to use modularized code? I myself rather take the latter, at least the risk of not compiling successfully is lower and the chance of getting something done is higher. Security issue aside, there are crate scanners that exactly prevents this, and how can you do that with C? Also, embedded code looking like Lambda code is a very good thing: both embedded system and Lambda are focused on doing one thing and do its best
  - galangalalgol 5y ago
    Explain the crate scanner thing? Ignoring security issues due to crates is no better than ignoring security issues due to memory errors or undefined behavior. And if you are doing safety critical code, where rust would shine, all those dependencies need to be certified to the same level as your own code. Sometimes re-creating and testing and certifying exactly the code you need is faster than reuse. Heresy I know, but it has been my experience with both embedded c++, and rust at work. Edit: We have not deployed rust to safety critical yet, I am unaware of any certification that would allow that existing for any version of the rust compiler.
berkut 5y ago
One of the things I really find limiting in Rust compared to C/C++ is conditional compilation, i.e. for different architectures: yes, the C/C++ pre-processor does suck in many ways and is masochistic if you're not careful, but it's also incredibly flexible. Conditional compilation in Rust can be done per module, so in theory you can have different archs in different .rs files, each imported conditionally, but that then seems to mean duplication of things like structs, method/function signatures in different implementations, which is pretty annoying in many cases (i.e. you'd just want the inner bits of functions to be different, or optionally call certain subsets for certain archs). You can abstract some of this to 'common' modules to a limited degree, but not much in my experience, and that comes with additional 'plumbing' complexity anyway. Rust has cfg attributes, and the cfg_if crate which in theory is a bit closer to the pre-processor functionality (and to a degree allows nesting/cascading like in C/C++), but in my experience these are just as annoying and limiting but in different ways: it's a macro, which is annoying in other ways (needs braces, has some issues with formatting, etc). cfgs also seem to be exclusive, so I've found it incredibly messy getting a balance right between code re-use for common parts (i.e. function/method signatures) which need to be shared by multiple cfgs, and duplication. Maybe I'm missing something?
- AnyTimeTraveler 5y ago
  I just checked. You can also add those same conditionals to functions and structs. So you don't have to in- or exclude whole modules. You can even use it in an if-statement, as seen in the example main function on the page I linked. See here: https://doc.rust-lang.org/rust-by-example/attribute/cfg.html https://doc.rust-lang.org/rust-by-example/attribute/cfg.html
  - berkut 5y ago
    Yes, but now try nesting or chaining them... It's do-able with cfg_if crate macro, but I really don't think much of the result in many complex situations, compared to what can be done in C/C++. Also, using the cfg! macro (which you need to do to use it in logic) I think is stripped out at link time (I had all sorts of issues with this), so if you've got intrinsics which don't compile on the current platform, that's not helpful (maybe I did something wrong here, but I've googled it a lot, and asked for help several times on the Rust Discord server).
goodpoint 5y ago
I prefer Nim because it runs on every architecture where a C compiler is available. Also it's way more productive.
- davidatbu 5y ago
  I'd be interested in reading the reasoning behind the conclusion that Nim is way more productive.
  - goodpoint 5y ago
    Nim is more expressive, has a powerful macro and templating mechanism comparable to Lisp and build times are a fraction of rust's.
megumax 5y ago
I would like to see that avr-unknown-gnu-atmega328 works with the latest compiler. Some bug in LLVM broke it[1], because it didn't work starting with versions after nightly-2021-01-07[2]. I know that rust team has nothing to do with this, but they should improve the gcc codegen[3] to be able to run rust on more embedded devices than LLVM has support for. Someone wanted to port his libc written in rust to ia64 and the gcc codegen broke and couldn't compile that. [1] https://reviews.llvm.org/D114611 https://reviews.llvm.org/D114611 [2] https://github.com/Rahix/avr-hal/issues/124 https://github.com/Rahix/avr-hal/issues/124 [3] https://github.com/rust-lang/rustc_codegen_gcc https://github.com/rust-lang/rustc_codegen_gcc
- couchand 5y ago
  Do you have experience with AVR assembly and calling conventions? There are only a handful of us looking at this issue, none of us have much bandwidth and we could definitely use your help!
- zozbot234 5y ago
  The AVR codegen bug is discussed here: https://github.com/rust-lang/rust/issues/82242#issuecomment-997400373 https://github.com/rust-lang/rust/issues/82242#issuecomment-... Seems to be due to the LLVM-AVR patchset somehow expecting gcc-compatible compiler intrinsics (for division), whereas Rust provides intrinsics derived from LLVM's compiler-rt, with different calling conventions.
qqumut 5y ago
Nice.
fwiffo 5y ago
I haven't checked Embedded Rust yet, but it is in my todo list. However, my two main embedded targets for C are Z80 and 8051, and my understanding is that these targets are not supported. I'd love to have Rust there.
- steveklabnik 5y ago
  I'm not aware of support for those in LLVM, let alone rustc. Does GCC even have support?

144 points by eldruin 5y ago

It's great to see a community forming and the general enthusiasm. But are there any vendors actively participating in or supporting Embedded Rust? For example is any vendor porting drivers to native Rust?

eldruin 5y ago
Espressif (the makers of the hugely popular ESP32/ESP8266/... microcontrollers) hired an embedded Rust community member to work full time on Rust support for their chips: https://mabez.dev/blog/posts/esp-rust-espressif/ https://mabez.dev/blog/posts/esp-rust-espressif/
- stbtrax 5y ago
  Does Espressif have large marketshare outside of hobbyists?
  - keewee7 5y ago
    The ESP chips are in pretty much all cheap Chinese-made IoT and Smart Home devices.
howenterprisey 5y ago
There's at least a decent amount of interest from both industry (auto tier 1's, for example) and from vendors; I'd love to name names here but I'm pretty sure I can't. :)
follower 5y ago
> But are there any vendors actively participating in or supporting Embedded Rust? That's kind of an interesting question. While obviously vendor participation can lead to some positive outcomes; my impression is some part of the motivation for Rust targeting the embedded space (and not waiting on vendors) is to avoid reliance on hardware vendors. Due largely to the poor reputation hardware vendors have in regard to anything in the software tool/firmware space within the C ecosystem.
steveklabnik 5y ago
In addition to what others have said, ARM has participated in the RFC process, donated CI resources, and joined the Rust Foundation. There are also a large number of things going on in industry that aren’t yet truly public. Some of these are the “I know something I can’t say” variety and some are the variety of “wow another car manufacturer has posted an embedded Rust job?” Exiting times ahead.

AlexanderDhoore 5y ago

I really hope embedded rust can become the next rock-solid foundation. I need my code to build/run today and also in 10 years. We have code in our codebase from at least the early 90s but I suspect it's older than that. I went into embedded because I really despise the code churn of higher level frameworks/languages. "We just released Qt5! Good luck rewriting your code."

OtomotO 5y ago
For me, even in high level, an API should only be broken, when/if it gives a benefit over the old approach. Sadly quite often it's only new and shiny to sell something :/ I assume in embedded this is simply different, because the needs are others.
zibzab 5y ago
If that's your goal I think you should wait a few years before starting using Rust. We have already seen early Rust code not compiling with new compiler releases. Right now we are in a move fast and break things phase. Also, you need to be careful about what you implement yourself and what you import from crates. Otherwise it will be qt5 all over again.
- CodesInChaos 5y ago
  > We have already seen early Rust code not compiling with new compiler releases. Are you talking about breaking changes in the compiler after Rust 1.0? That should be very rare, and generally easy to fix (e.g. by adding a few type annotations). Or did you use unstable features? (Not sure if embedded is usable without unstable nowadays)
  - eldruin 5y ago
    It depends on your target architecture. For example, embedded development on ARM with stable Rust has been possible since 2018 (Rust 1.31)
- Lorkki 5y ago
  > We have already seen early Rust code not compiling with new compiler releases. I haven't really seen that happen with post-1.0 Rust, which is everything onwards of early 2015. I believe they've since tightened a couple of edge cases due to soundness issues, but nothing worse than that. Would be interesting to hear about your contrary experiences.

zibzab 5y ago

Two things have kept me away from embedded Rust before 1. A huge chain of dependencies. Security issues aside, I prefer my embedded code to be lean and clean. 2. A big departure from how things used to be done in this world. For example interrupt handlers almost look like AWS lambda code to me. Maybe that's the future, I don't know. But right now I am not comfortable with this way of doing low level coding. But I am keeping an open mind and will probably try it again soon. I can see myself using Rust instead of C in more projects, but maybe first after things calm down a bit. I want my development environment outdated and boring, a.k.a. "stable".

stevefan1999 5y ago
Using Rust mods is exactly being lean and clean: would you rather take a bunch of include files, stupidly duplicates them in almost every translation units, and this would eventually blows up at some point of time, and is hard to reconfigure with some mysterious macro induced error, or, would you inter-depend on bunch of crates that might pull over 100mb of stuff at total that might have potential supply chain attack because it is too convenient to use modularized code? I myself rather take the latter, at least the risk of not compiling successfully is lower and the chance of getting something done is higher. Security issue aside, there are crate scanners that exactly prevents this, and how can you do that with C? Also, embedded code looking like Lambda code is a very good thing: both embedded system and Lambda are focused on doing one thing and do its best
- galangalalgol 5y ago
  Explain the crate scanner thing? Ignoring security issues due to crates is no better than ignoring security issues due to memory errors or undefined behavior. And if you are doing safety critical code, where rust would shine, all those dependencies need to be certified to the same level as your own code. Sometimes re-creating and testing and certifying exactly the code you need is faster than reuse. Heresy I know, but it has been my experience with both embedded c++, and rust at work. Edit: We have not deployed rust to safety critical yet, I am unaware of any certification that would allow that existing for any version of the rust compiler.

berkut 5y ago

One of the things I really find limiting in Rust compared to C/C++ is conditional compilation, i.e. for different architectures: yes, the C/C++ pre-processor does suck in many ways and is masochistic if you're not careful, but it's also incredibly flexible. Conditional compilation in Rust can be done per module, so in theory you can have different archs in different .rs files, each imported conditionally, but that then seems to mean duplication of things like structs, method/function signatures in different implementations, which is pretty annoying in many cases (i.e. you'd just want the inner bits of functions to be different, or optionally call certain subsets for certain archs). You can abstract some of this to 'common' modules to a limited degree, but not much in my experience, and that comes with additional 'plumbing' complexity anyway. Rust has cfg attributes, and the cfg_if crate which in theory is a bit closer to the pre-processor functionality (and to a degree allows nesting/cascading like in C/C++), but in my experience these are just as annoying and limiting but in different ways: it's a macro, which is annoying in other ways (needs braces, has some issues with formatting, etc). cfgs also seem to be exclusive, so I've found it incredibly messy getting a balance right between code re-use for common parts (i.e. function/method signatures) which need to be shared by multiple cfgs, and duplication. Maybe I'm missing something?

AnyTimeTraveler 5y ago
I just checked. You can also add those same conditionals to functions and structs. So you don't have to in- or exclude whole modules. You can even use it in an if-statement, as seen in the example main function on the page I linked. See here: https://doc.rust-lang.org/rust-by-example/attribute/cfg.html https://doc.rust-lang.org/rust-by-example/attribute/cfg.html
- berkut 5y ago
  Yes, but now try nesting or chaining them... It's do-able with cfg_if crate macro, but I really don't think much of the result in many complex situations, compared to what can be done in C/C++. Also, using the cfg! macro (which you need to do to use it in logic) I think is stripped out at link time (I had all sorts of issues with this), so if you've got intrinsics which don't compile on the current platform, that's not helpful (maybe I did something wrong here, but I've googled it a lot, and asked for help several times on the Rust Discord server).

goodpoint 5y ago

I prefer Nim because it runs on every architecture where a C compiler is available. Also it's way more productive.

davidatbu 5y ago
I'd be interested in reading the reasoning behind the conclusion that Nim is way more productive.
- goodpoint 5y ago
  Nim is more expressive, has a powerful macro and templating mechanism comparable to Lisp and build times are a fraction of rust's.

megumax 5y ago

I would like to see that avr-unknown-gnu-atmega328 works with the latest compiler. Some bug in LLVM broke it[1], because it didn't work starting with versions after nightly-2021-01-07[2]. I know that rust team has nothing to do with this, but they should improve the gcc codegen[3] to be able to run rust on more embedded devices than LLVM has support for. Someone wanted to port his libc written in rust to ia64 and the gcc codegen broke and couldn't compile that. [1] https://reviews.llvm.org/D114611 https://reviews.llvm.org/D114611 [2] https://github.com/Rahix/avr-hal/issues/124 https://github.com/Rahix/avr-hal/issues/124 [3] https://github.com/rust-lang/rustc_codegen_gcc https://github.com/rust-lang/rustc_codegen_gcc

couchand 5y ago
Do you have experience with AVR assembly and calling conventions? There are only a handful of us looking at this issue, none of us have much bandwidth and we could definitely use your help!
zozbot234 5y ago
The AVR codegen bug is discussed here: https://github.com/rust-lang/rust/issues/82242#issuecomment-997400373 https://github.com/rust-lang/rust/issues/82242#issuecomment-... Seems to be due to the LLVM-AVR patchset somehow expecting gcc-compatible compiler intrinsics (for division), whereas Rust provides intrinsics derived from LLVM's compiler-rt, with different calling conventions.

qqumut 5y ago

Nice.

fwiffo 5y ago

I haven't checked Embedded Rust yet, but it is in my todo list. However, my two main embedded targets for C are Z80 and 8051, and my understanding is that these targets are not supported. I'd love to have Rust there.

steveklabnik 5y ago
I'm not aware of support for those in LLVM, let alone rustc. Does GCC even have support?