Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Embedded Rust or C firmware? Lessons from an industrial microcontroller use case

arxiv.org

Post reply on HN
Print view View original

81–90 of 172 posts

Re: Embedded Rust or C firmware? Lessons from an industrial microcontroller use case

#81

Post by the__alchemist »

Good article! I will give you my 2c, as someone in this space mostly for hobbies, but with one active work project:

Rust is fantastic for embedded. There are no hard obstacles. The reason to do it IMO is not memory safety, but because holistically the language and tools are (to me) nicer. Enums, namespacing, no headers, `cargo run --release` "just works". (I have found, at least in OSS, compiling C embedded project is a mess. Linker errors, you need to have a certain OS with certain dependencies, there are many scripts etc). Good error messages, easy to structure your programs in a reliable way etc. Overall, I just find it to be a better designed language.

I have found the most fundamental tooling for rust on Espressif's RiscV, and Cortex-M ARM for various STM-32 variants to be great. The cortex-m crate, defmt, and probe-rs, and the PAC project is fantastic.

On the down side, I have have to build my own tooling. I wrote and maintain my own HAL for STM32, and have had to write my own libraries for every piece of hardware. This comes with the territory of a new language, and suspect this will gradually improve this time - especially with vendor support. Because the fundamental libraries are around, this is just reading datasheets and making rust functions/structs etc that do the MMIO as described in the datasheets. Can be tedious (Especially if building a complete library instead of implementing what you need for a given project), but is not an obstacle.

My most complicated rust embedded firmware was a FPV-style UAS. I did it without an RTOS, using interrupt-based control flow.

Re: Embedded Rust or C firmware? Lessons from an industrial microcontroller use case

#82

Post by estebank »

throw848tjfj wrote: post #69
eggy wrote: post #54

We passed on Rust for Ada/SPARK2014 to write to bare metal on Cortex-M processor for real-time, high-integrity, and verifiable mission-critical software. Rust is making strides to be a future competitor, but it's new to the formal verification tooling and lacks any real world legacy in our domain. Ada's latest spec. is 2022. Other than AdaCore's verified Rust compiler, Rust still does not have a stable language speci…

Rust is not really memory safe if you combine it with external libraries. Too many "unsafe" keywords, and lack of tooling for code analysis and verification. Edit: With c, you can do memory safety analysis on all system libraries and entire Linux kernel. Some OS kernels, libs and languages do not have dynamic memory allocation at all! Some languages are memory safe! Learn more about embedded programming!

Under that rubric, no language is memory safe.

Re: Embedded Rust or C firmware? Lessons from an industrial microcontroller use case

#83

Post by eggy »

irishcoffee wrote: post #74
Filligree wrote: post #56

Earlier quoted context omitted.

Presumably, if you use formal verification then that includes memory safety anyway? Would seem strange if it does not.

Formal verification requires a spec and a very large, very expensive amount of tooling to be developed. My understand is that both these things are in work, and that neither of these things exist yet.

Yes, and AdaCore's tooling is formally verified and produces reports already familiar to aerospace, railway, and auto auditors for verifying certifications making it attractive to this industry segment of high-integrity apps. Memory safety is taken care of mainly through the features Ada/SPARK2014 offer in creating safe, high-integrity programs, correct.

Re: Embedded Rust or C firmware? Lessons from an industrial microcontroller use case

#84

Post by tredre3 »

LtWorf wrote: post #67
Aurornis wrote: post #32

Earlier quoted context omitted.

> Rust is evolving far too fast to be used in code which needs to run for years to decades down the line. Code doesn’t stop running on existing hardware when the language changes in a future compiler. You can still use the same old toolchain. I’ve done a lot of embedded development in a past life. Keeping old tool chains around for each old platform was standard. I would much rather go through the easy process of swi…

> You can still use the same old toolchain. Unless you find out the compiler was buggy and was producing faulty binaries, but the new compiler can no longer compile the old code.

What you are describing happens all the time. Usually the toolchain provider will continue updating a list of known issues for some time after EOL. Beyond that you have third parties that do it for decades, if the platform is big enough. They collect bug reports from the industry, investigate them, then create lists that you subscribe to. Those lists include detailed examples, explanations, and usually linter rules to detect code that could trigger the bug.

The truth is: If the toolchain was good enough to ship your product, has time to go EOL, and then you do a patch that surfaces an esoteric toolchain bug, then the odds are that you'll know exactly what triggered the bug and you can work around it by writing different code.

Because even if the newer shinier compiler/toolchain had the issue fixed, most companies wouldn't upgrade to it at that point. It's almost never desirable to change your toolchain for a shipping product, you're just introducing more unknowns.

Re: Embedded Rust or C firmware? Lessons from an industrial microcontroller use case

#85

Post by iknowstuff »

noosphr wrote: post #16
dgacmu wrote: post #2

Authors are from STMicro, polytechnic Turin, Freie universitat Berlin, and Inria. Examined writing firmware for an IOT sensor platform. From the abstract: > Two teams concurrently developing the same functionality (one in C, one in Rust) are analyzed over a period of several months. A comparative analysis of their approaches, results, and iterative efforts is provided. The analysis and measurements on hardware indica…

[flagged]

Rust is stable. If you don’t plan on changing crates, newer compilers will compile your 5yo code.

Re: Embedded Rust or C firmware? Lessons from an industrial microcontroller use case

#86

Post by hulitu »

Aurornis wrote: post #32
noosphr wrote: post #16

Earlier quoted context omitted.

[flagged]

> Rust is evolving far too fast to be used in code which needs to run for years to decades down the line. Code doesn’t stop running on existing hardware when the language changes in a future compiler. You can still use the same old toolchain. I’ve done a lot of embedded development in a past life. Keeping old tool chains around for each old platform was standard. I would much rather go through the easy process of swi…

> You can still use the same old toolchain.

If you keep your old computer around, yes.

The good news is that C seems also contaminated with "move fast, break things " phylosophy. The modern code writer is not able to make things that last more than a couple of months.

Re: Embedded Rust or C firmware? Lessons from an industrial microcontroller use case

#87

Post by cyberpunk »

whiatp wrote: post #47
Aurornis wrote: post #32

Earlier quoted context omitted.

> Rust is evolving far too fast to be used in code which needs to run for years to decades down the line. Code doesn’t stop running on existing hardware when the language changes in a future compiler. You can still use the same old toolchain. I’ve done a lot of embedded development in a past life. Keeping old tool chains around for each old platform was standard. I would much rather go through the easy process of swi…

I remember a coworker having to fight with an old platform's build not working because our user/group IDs were bigger than 2^16. I can't remember which utility was causing the problem, I'd have to guess tar. This is when we learned to play the archive a VM game.

I know a defence company that has a bunch of vaxes stored in low oxygen environments because they legally have to be able to provide software updates to firmware they’ve written for the next 20 or so years and it was written on a vax.

They had some great stories trying to get something or other running again where they had to fly one of the original designers over to hand solder a board back into action.

How we do that today is a bit of an interesting problem I don’t think they’ve convincingly solved; basically maintaining nightly builds forever — a couple 1U’s of kubernetes in deep storage ain’t gonna do it, you’re not gonna be able to solder a xeon back to life..

I know I’d rather be trying get a load of c99 rebuilt for some mips or other after 20 years that some random version of rust.

Re: Embedded Rust or C firmware? Lessons from an industrial microcontroller use case

#88

Post by hulitu »

estebank wrote: post #22
noosphr wrote: post #16

Earlier quoted context omitted.

[flagged]

Can you point at any piece of code from 5 years ago that doesn't work today?

Firefox. I gave up compiling it because either the rust version is wrong or the code.

Re: Embedded Rust or C firmware? Lessons from an industrial microcontroller use case

#89

Post by jitler »

cyberpunk wrote: post #87
whiatp wrote: post #47

Earlier quoted context omitted.

I remember a coworker having to fight with an old platform's build not working because our user/group IDs were bigger than 2^16. I can't remember which utility was causing the problem, I'd have to guess tar. This is when we learned to play the archive a VM game.

I know a defence company that has a bunch of vaxes stored in low oxygen environments because they legally have to be able to provide software updates to firmware they’ve written for the next 20 or so years and it was written on a vax. They had some great stories trying to get something or other running again where they had to fly one of the original designers over to hand solder a board back into action. How we do th…

> I know a defence company that has a bunch of vaxes stored in low oxygen environments because they legally have to be able to provide software updates to firmware they’ve written for the next 20 or so years and it was written on a vax.

So uh, will these ever make it to an auction site you think?

Re: Embedded Rust or C firmware? Lessons from an industrial microcontroller use case

#90

Post by kibwen »

SkiFire13 wrote: post #73
estebank wrote: post #65

Earlier quoted context omitted.

Do you recall which libraries? Use of nightly fell of a cliff after 2018. Looking at the bottom of https://lib.rs/stats#rustc-usage , ~8% of all crates.io requests came from a nightly newer than that corresponding to 1.86. That's am upper bound, as using a nightly compiler doesn't mean that a nightly compiler was needed . The prevalence of nightly is also niche specific. If you're in embedded it is likely you need to…

> That's am upper bound, as using a nightly compiler doesn't mean that a nightly compiler was needed. To be fair it's not even a lower bound, as using a stable compiler doesn't imply the absence of nightly only feature (as in Cargo features, the ones you can enable on crates you depend on).

For the purposes of this discussion the question is not whether or not a crate exposes optional features that require a nightly compiler, but whether or not a crate makes use of the nightly compiler mandatory, which has become extremely rare in my experience. Perhaps it's more common in some embedded use cases, but if people want to make that assertion, I would ask that they either mention which libraries they're specifically talking about or which nightly features they're specifically referring to.
Post reply on HN