Hacker News Reader

Comment by syntaxing | Hacker News Reader

I was under the impression most low level firmware is still written in C? Is there a new preferred language? (Rust?)

Not really, C is pretty deeply entrenched in the embedded world. Unless you want to bitbang something like a USB host, you’ll be relying on vender libraries, and those libraries are overwhelmingly developed in C. Same is true for pretty much the entire build chain, debug tools, etc.

I guess we have to wait for libraries like USB stack written in Rust.... and not to mention LLVM support for embedded devices, yes?

Not really sure, though. I'm a mobile dev, and not an embedded dev :D

C and C++ still seem to be prevalent. At least in my experience, rust on a microcontroller is still mostly theoretical. There's plenty of obscure languages, though, both compiled and interpreted / virtual machine based.

For "embedded" linux grade CPUs, rust is starting to gain some practical traction. A few years ago the idea of writing application level glue code in it was still a bit silly, but these days it's starting to actually get linked into production systems. It all seems to be done in a way that's interoperable with existing C/C++ codebases, though.

Explaining my experience - I haven't done any hardware or firmware programming besides messing around with Ardunios. I have written a low amount of C (tiny VM for toy language) and a moderate amount of Rust (a couple thousand lines for various projects, mostly console apps that needed to run fast).

It sounds like you have some experience in this and I have been curious for a long time why Rust can't or doesn't run on almost every micro-controller? Is it based on the compiler? I thought that because Rust has no runtime/produces a binary which does not require a runtime that as long as the Rust compiler emits the right backend instructions it should just work?

Adding to my confusing, I think rustc uses LLVM which is a way of separating a language's frontend from the backend code emitted, so I thought any micro-controller supported by LLVM would work for Rust.

My day job is writing Rust code for microcontrollers.

What you're saying isn't wrong, it's just that... embedded development is incredibly diverse. LLVM doesn't support as many platforms as GCC does, and even once LLVM gets support for something, we need to do some work in Rust to get things working; support isn't automatic.

If you get to pick what your hardware is, Rust is fantastic. If you don't get to pick... it's a roll of the dice.

Thanks for the great and clear explanation, it makes more sense now! (a lot more sense)

I didn’t know that Rust support for a LLVM target isn’t free and didn’t realize micro-controller targets are so diverse. Very cool.

I'm only about a third of the way through the rust manual myself, so I can't say with confidence, but I suspect that rust's safe memory abstractions don't necessarily scale down to the lowest end of MCUs. The machine code instructions that make the code efficient simply may not exist on an 8-bit segmented memory CPU. That also touches on the gaps in LLVM support. I'll bet it's perfectly viable these days on any cortex-m MCU, though.

Also, a lot of embedded code consists of peripheral drivers, and in rust that likely means "unsafe" code. At that point, it's a bit of a wash which language you work in. That's especially true since rust can interoperate with the C ABI.

I haven't familiarized myself with all of rust's built-in data structures yet, and I'm not sure how much stuff necessitates allocating on a heap under the hood. That would be a compelling reason to carefully consider its use in some embedded systems. That's analogous to C++, where it's typical to avoid most of the STL data structures.

Most of Rust's memory safety comes from compile-time checks, not runtime code.

You do need some unsafe, but not as much as you may assume at first.

Rust doesn't really have any complex built-in data structures, and doesn't require a heap at all. That's a standard library thing, which you wouldn't be using in this context.

Rust on a micro is more than theoretical. You could start a commercial firmware project on it today. However it is an extremely slow-moving segment of the industry so I wouldn't expect to see much of it for a while.

Definitely still mostly C. Although currently tossing up whether we use some very limited C++ for a new project: some templated types to handle memory safety, and some strict encapsulation.

I'm quite intrigued by Zig and am hoping to get in and play with it, since it aims to be a "better C" (not C++) so it remains a small language. See this recent post which triggered my curiosity: https://kevinlynagh.com/rust-zig/

(edit: more thoughts on Zig) I am intrigued because I want out of a new embedded programming language aligns perfectly with their approach. comptime instead of the C preprocessor, generics, any allocation is explicit (any memory allocation is at initialisation time), etc.

Kind of. Rust seems to be becoming quite popular. It has features that allow low-level programming while maintaining as much type safety as possible. There's even talk of using it in the Linux kernel.

EDIT: I'm not sure why you ask that here though. Rust doesn't appear to be mentioned in this post.

Not OP, but probably this bit:

> I write our firmware using C. While some might gasp at using such an "old" language, it turns out that the combination of my familiarity with C, the maturity of its resources and tooling, and the low-level nature of writing firmware means that C happens to be a joyful language for me to write firmware in.

Which has the flavor of defending the choice of C as if it weren't the standard choice.

Realistically for most micro controllers it's the only choice other than machine code. Basically because it's the only one offered by the manufacturers.

C/C++ is the most common IME, but Rust is coming along nicely.

I'm working on a commercial firmware for ATSAMD21 using Rust, and have been finding it quite a nice experience. The tooling is great, PACs and HALs are at least as good as the last time I used the Atmel-provided ones, it's really nice being able to just add a line to Cargo.toml to bring in a library rather than cribbing from a prior project or writing my own.

That said, the Rust HAL for SAMD21 is certainly not complete; I'm working from a forked version of it, and have issued a few PRs to extend/fix it and other libraries. There are a few areas, DMA in particular, where the community hasn't quite decided on the right approach.

C is still by far the most dominant: even convincing embedded developers to use C++ can be a challenge. A subset of the rust community is focusing on it for embedded work, and it's very interesting for that in a few ways (relatively little technical reasons not to use it now: basically if it's an architecture LLVM can target you can write rust for it), but it's basically not even on the radar of most firmware designers (who as a group are fairly conservative and not likely to be looking for new languages anyway).

C owns this domain, even C++ never managed to win that much of the market.

While you might find some C++ compilers, most vendors don't have linker scripts that work properly with C++ code, or libraries without issues.

Reply on news.ycombinator.com