This Year in Embedded Rust

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

> 1. A huge chain of dependencies.

I think there is another side to this coin though. IMO there are too many embedded shops that overlook reliable 3rd-party code in favour of spending man-hours growing their own code from seed instead. Or if not that you spend days debugging some greybeard coworker's "Oh I think I wrote something like that 25 years ago for a PDP-11, I'll just email it to you.."

But to be honest I don't really disagree all that much -- As much as the embedded world needs to keep up with the times, there's no way that the level of audit required for a reliable embedded project just can keep up with how quickly crates are being changed.

> 2. A big departure from how things used to be done in this world.

Sometimes I cringe too when takes a massive server board with 9999GB of RAM and a 4g modem and calls it "embedded" just because they screwed it to the side of a helicopter... But if the root question is "will rust be viable on a puny AVR" I hope that the answer is definitely yes.

I can definitely see the objection to running Nightly to build actual embedded systems. Two ex-colleagues built embedded devices that were intentionally injected into glaciers for measurement purposes, obviously "Oops, we need to upgrade them" isn't much more of a thing while they're working than for the Mars rovers - if you don't have a way to remotely upgrade the part that needs changing, or your radio upgrade fails and you brick the device you can't send a field technician to fix it.

And personally I never run Nightly, I did AoC for example entirely in stable because I don't feel like I need more excitement in my life.

The "it looks alien" thing (which is how I read your comment about "looks like AWS lambda code to me") I think is a place where Godbolt can help you if you're serious enough about low-level to be at least confident reading assembler even if you never write any. Matt Godbolt built Compiler Explorer's ancestors because he knew that nicer C++ iterators claimed to have the same performance characteristics as the good-old C style for loops he'd grown up with but he needed to be sure that was a fact before he moved vital performance critical software to them. Compiler Explorer shows that yup, you get equivalent assembler, the machine is doing the exact same work as before. I think you'll find Rust's "like AWS lambda code" for interrupt handlers is eventually doing the same low-level bit twiddling you're used to writing, but presented in a different (safer) way.

FWIW HN formats the space-prefixed paragraphs in your text as fixed pitch like code, which is annoying for people on small devices when you aren't actually showing code or diagrams where spacing is important to understanding.

> A huge chain of dependencies. Security issues aside, I prefer my embedded code to be lean and clean.

Where does your limit go for that? I wrote a eurorack modular embedded thing on Teensy 4.0 (imxrt) in Rust this year. I just inspected the dep tree, it's 38 crates, with 1 being my own.

https://gist.github.com/algesten/9617fc795f2fc94009f1ed311b1...

It was a joy to write this in Rust, I look forward to my next project. This was done with "stable" (not nightly).

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.

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.

> I need my code to build/run today and also in 10 years

I think you should stick with C if this is a hard goal. Let Rust settle for some years before going all in.

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

There are many examples out there of ways to deal with conditional compilation in Rust, and I find it much more straightforward and simple than my own personal experience with C.

Take a look at the socket2 crate as a nice way to deal with different platforms.

The rule of thumb I would use is encode logic as much as possible into traits, and then abstract out specific arch details like fields etc. You can combine conditional compilation units with trait based support as well to reduce the annotations and instead provide functionality only for types that implement certain traits.

> 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.

Why not just use it as-is for Rust ? There are plenty of non-C/C++ things which use cpp. X11 uses it for config files (.Xresources for instance afaik). I think that polkit or something like that uses it too for its config files. I've seen it used in Java.

Are you able to provide a barebones specific code example (either in C/C++ or Rust) of the issue(s) you're describing (e.g. nesting/chaining) where Rust conditional compilation is limiting?

A specific example is likely to lead to a more educational discussion in terms of learning about a solution to issues that you've observed or highlighting currently unsolved issues with Rust's implementation.

Either of which would be valuable.

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!

The AVR codegen bug is discussed here: 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.

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/

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. :)

> 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.

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.

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

I'd be interested in reading the reasoning behind the conclusion that Nim is way more productive.