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

91–100 of 172 posts

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

#91

Post by tredre3 »

estebank wrote: post #48
Aurornis wrote: post #34

Earlier quoted context omitted.

> Might have something to do with how Cargo manages dependencies Build against the lockfile to use the same versions. Unless they were pulled from upstream, they won’t suddenly stop building against the same compiler version. Rustup makes it easy to switch compiler versions to get back to the same one you used, too.

Even if a crate is yanked, if you have the version in a lock file it will still download and build. (This was done precisely after seeing the left-pad incident.)

I'm sure you have ways to entirely purge a crate. And the situation will arise that you need to do so. In which case all the old code will, indeed, break.

Vendoring is the only solution to this but it's really discouraged in rust-land and there is no first-party support for it. You can kind of manually vendor your deps with cargo, and there are third party tools. But compare that to go-land where `go mod vendor` gets you 95-100% of the way there.

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

#92

Post by ShyCodeGardener »

jagged-chisel wrote: post #19
noosphr wrote: post #16

Earlier quoted context omitted.

[flagged]

The code won't magically stop running because the Rust community continued evolving the language. The old toolchains will be available if there's a compatibility change. Where's the problem exactly?

Probably just depends on what you are doing. Library support could move forward and new features / security updates for libraries that are not part of core Rust could possibly be an issue if they don't work on older versions.

Might not matter for a lot of embedded, but if you are doing something like exposing functionality via a webserver or something that would be network-connected, then security updates in third-party libraries may be important.

For example, it would be really easy for me to run old code that's pinned to something like Python 3.7, but if libraries have updated to Python 3.x without backwards compatibility, then I'm stuck using the out of date versions or just backporting myself.

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

#93

Post by fjfaase »

kaspar030 wrote: post #11
serhack_ wrote: post #8

off topic question: why is there no source attached to this paper?

"The open source code will be published on https://github.com/stm32-hotspot/ for the final version of the paper." -> paper is not final. And IIUC ST will be releasing the code at some point.

I find this a bit disappointing. Why not publish it with the preprint. Now we have no way to establish the quality of the two solutions or whether it is even possible to improve one of the solutions. I wonder why the C variant could not implement a JSON parser without malloc and free, while the RUST variant could.

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

#94

Post by the__alchemist »

kaspar030 wrote: post #9
Galanwe wrote: post #7

Earlier quoted context omitted.

Isn't there a nasty selection/volunteer bias at play with the developers?

You mean with the "two teams" that were tasked to develop the C / Rust versions? Yeah of course. Then again - they were one person teams, where the C "team" had years of experience in stm32 / embedded C / stm32 cube development and churned out that handwritten state machine in just days. The Rust "team" was a pre-masters intern with only minimal embedded Rust experience. They ran into all the pitfalls with (async) em…

I hit those pitfalls with async and moved on. It's popular in open source rust embedded circles, but not my cup of tea.

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

#95

Post by estebank »

kibwen wrote: post #90
SkiFire13 wrote: post #73

Earlier quoted context omitted.

> 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 spe…

I think the divide is apps vs libraries: a library that requires their dependants to set an environment variable opting out of stability guarantees is unlikely to gain adoption, but applications that do so are more common, like Firefox.

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

#96

Post by megous »

orochimaaru wrote: post #78
jonathanstrange wrote: post #62

Earlier quoted context omitted.

That invariably leads to bitrot and low maintainability. It's one among many reasons why I don't use Rust.

You have the same issue with C, no? C is upgrading versions, compilers have changed, hardware evolves and somethings in the past aren't supported as well anymore.

Not really. Not in the scale of my C dev life, which has been 20 years so far.

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

#97

Post by the__alchemist »

MeteorMarc wrote: post #10
kaspar030 wrote: post #3

One of the author's here, if there are any questions!

Nice to see serial comms supported. Are I2S and CAN on the roadmap? Do you see any sensor module suppliers support ArielOS?

Note: I'm not using the same tooling, but CAN and I2S have worked well for years on STM-32/rust. You just need to interface with STM32's SAI (ditital audio peripheral) and CAN. There are high-quality portable libs for both the legacy "BX" CAN and FD-CAN, which will work on any STM-32 variant. The SAI will have to be HAL-specific, but I have used it on both G4 and H7 variants for PDM mic arrays.

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

#98

Post by davemp »

I'll start of by saying I really hate C (also love it), and welcome improvements; but I have a few criticisms:

- Sensor agent is such a rancid name for a remote sensor that I feel a need to public say so. Please don't use marketing names for things that already have more descriptive names.

- Rust uses a full RTOS and C uses the mediocre ST HAL (vendor specific). Immediately apples to oranges. Also I've never heard of the C JSON library and it looks sketchy at a glance so that will also hurt the comparison.

- Streaming slow sensor data with a 160MHz 786KB/2MB MCU is not a good test in the slightest. You could probably use something like micro python here and be done. No one is reaching for bare metal C here. Also no one serious about performance is using JSON serdes. If you're using bare metal C, you're likely trying to push the limits of your hardware or doing something so simple that you won't be tempted to reach for terrible third party libraries.

- Does the Rust code base use the 'unsafe' keyword anywhere, including the RTOS? If so, it's not memory safe without additional formal verification.

Overall I'd say this paper has approximately zero value wrt its stated goal of comparison.

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

#99

Post by estebank »

hulitu wrote: post #88
estebank wrote: post #22

Earlier quoted context omitted.

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.

Firefox explicitly opts out of stability guarantees by using nightly features on a stable compiler in an unsupported manner, not dissimilar to using an unstable GNU extension in C. But good example of the caveat that if you're not using stable, then yes, you have no stability guarantees.
Post reply on HN