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

121–130 of 172 posts

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

#121

Post by shrubble »

jitler wrote: post #89
cyberpunk wrote: post #87

Earlier quoted context omitted.

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?

I have an Acer Chromebook with Celeron N3060 CPU and it runs the SIMH VAX emulator with 64MB for the VAX at the same speed as a Vaxstation 4000/60 and likely the disk is much faster.

I like OpenVMS and am slowly learning more about it; no reason to wait until you see those hit eBay :-)

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

#122

Post by fluffybucktsnek »

staticassertion wrote: post #17
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. That statement deserves support.

Why, given the existence of editions?

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

#123

Post by fl0ki »

tcfhgj wrote: post #53
oytis wrote: post #46

Earlier quoted context omitted.

There is a difference in C and Rust culture. Embedded C projects rarely have external dependencies, and in rare cases when there are dependencies (e.g. most projects use vendor SDKs nowadays), they are pinned and there is an expectation of API compatibility anyway Rust on the contrary incentivises using dependencies, and especially embedded software is hard to write without using external packages (e.g. cortex-m-rt,…

in what way is it incentivized by Rust? imo it's just so much easier

I think a big difference is that the less unsafe you want in your own code, the more you rely on crates to provide a safe abstraction for unsafe code in a centralized place where soundness holes are likely to be found.

Of course it was always understood that you could have bugs in C libraries and some of them may include memory unsafety, but the culture is very different when there's no explicit way to demarcate the parts of the code most deserving of scrutiny.

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

#124

Post by irishcoffee »

eggy wrote: post #83
irishcoffee wrote: post #74

Earlier quoted context omitted.

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.

Yeah right now it’s usually C, but if I had a choice I’d use Ada. I’ve never done a graphical interface with Ada, and I have with OpenGLSC using C.

I’m sure at some point there will be an accepted formal verification toolchain for rust, I hope to never use it.

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

#125

Post by sli »

hulitu wrote: post #86
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. 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.

Previous versions of the Rust compiler don't just up and disappear just because I moved to a new workstation or setup a new build server. I understand it's not optimal to rely on a download always being available, but even then, that is not at all exclusive to any single language. Why would earlier versions of Rust be susceptible to this but not something like gcc? I don't see it.

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

#126

Post by Aurornis »

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.

Fortunately there are more than two compiler versions in the world.

It's easy to install different rust toolchains. You could increment the toolchain version forward and find the next toolchain to include the fix, or even backport the fix to a custom toolchain if you want.

The comments acting like Rust is breaking code all the time are also pretty lost. I've been developing Rust since +/- the 1.0 days and this isn't a common occurrence. When something does need to change it's usually a tightening up of something that was incorrect in the past, and it's easy to fix.

Some of these comments act like everything is going to collapse at any moment and the old code will be unusable, which is pretty ridiculous

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

#127

Post by dundarious »

kaspar030 wrote: post #107
fjfaase wrote: post #75

Really strange the the C JSON parser has to use malloc where the RUST version does not. As if it is not possible to write a JSON parser in C that does use malloc. I presume that the syntax of the commands that the device will accept is known, and than there is no reason why you have to build a DOM of the JSON before you can process it. Apparently, the RUST version can do it. I really begin to question the abilities o…

Part of the C protocol implementation is generated, and that generator chose the JSON parser. As it worked and there was plenty of memory left on the MCU, it was kept. We're mentioning this in the paper: "The heap is entirely attributable to Parson's dynamic allocation of JSON tree nodes; as memory usage minimization was not a key goal, we kept Parson (the JSON parser used by the PNPL code generator by default), noti…

Wasn't memory one of the key indicators looked at?

> The analysis and measurements on hardware indicate no strong reason to prefer C over Rust for microcontroller firmware on the basis of memory footprint or execution speed.

I admit I have not carefully read the paper, and am collating info from comments here, so I may be fully mistaken. The word "strong" also allows for much interpretation, that I'm not a priori critical of, but am skeptical of.

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

#128

Post by IshKebab »

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…

There's this: https://rust-lang.github.io/fls/

But I think the lack of a formal specification is really not as big a deal as it's made out to be. It's one of those "think of a technical reason to justify a decision I've already made" excuses.

Obviously it would be great if Rust does get a full formal specification but I think avoiding it because it doesn't is just silly. C++ has a formal specification... which frequently has bugs and ambiguities. They aren't magically right and either way you're going to need to do a lot of non-formal testing as well as formal verification if you want confidence in a design.

This is true even for domains where formal verification is routine like SystemVerilog. I've seen designs pass formal but fail in simulation or vice versa due to subtle differences in the semantics. (Hopefully that can't happen for Rust but you get the point.)

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

#129

Post by IshKebab »

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

Rust 1.0 is 11 years old and it's still trivial to compile Rust code from then. I doubt that will change in the next 9 years.

C is an absolute nightmare in comparison. I tried to compile some old C code I had for Nordic nRF51 chips, only a few years after the chips became available. I gave up. Broken links, missing documentation, etc. etc. I can see why other people here are saying it's standard practice to archive a VM. Not really necessary for Rust.

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

#130

Post by AlotOfReading »

tormeh wrote: post #79
throw848tjfj wrote: post #69

Earlier quoted context omitted.

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!

This is correct. Some widespread libraries leak memory, for example. I love Rust, but I don't think this happens much in Java land.

Rust's definition of memory safety doesn't consider leaks unsafe, which isn't to say your system requirements can't .
Post reply on HN