Two things have kept me away from embedded Rust before<p><pre><code> 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.
</code></pre>
But I am keeping an open mind and will probably try it again soon.<p>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".
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.<p>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."
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 <i>incredibly</i> flexible.<p>Conditional compilation in Rust <i>can</i> 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.<p>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).<p>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.<p>Maybe I'm missing something?
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.<p>[1] <a href="https://reviews.llvm.org/D114611" rel="nofollow">https://reviews.llvm.org/D114611</a><p>[2] <a href="https://github.com/Rahix/avr-hal/issues/124" rel="nofollow">https://github.com/Rahix/avr-hal/issues/124</a><p>[3] <a href="https://github.com/rust-lang/rustc_codegen_gcc" rel="nofollow">https://github.com/rust-lang/rustc_codegen_gcc</a>
It's great to see a community forming and the general enthusiasm.<p>But are there any vendors actively participating in or supporting Embedded Rust?<p>For example is any vendor porting drivers to native Rust?
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.