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

111–120 of 172 posts

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

#111

Post by kibwen »

dlahoda wrote: post #45
vmg12 wrote: post #40

Earlier quoted context omitted.

> Rust is evolving far too fast I'm curious why I've seen this sentiment repeated in so many places, I learned Rust once 5 years ago and I haven't had to learn any new idioms and there have been no backwards incompatible changes to it that required migrating any of my code.

- https://github.com/contextgeneric/cgp - a lot of code now uses mix of witness types and const generics - with new borrow checker release they will do new iterators 2.0 Seems like coding on 5 year old Rust is like C++ 98.

I have never even heard of the linked repo, and it does not appear to be overly popular. Nor have I ever heard of "witness types" or seen code that attempts to make use of them. And no, any new borrow checker would not require some new approach to iterators. This entire comment reads like a non sequitur. Where on Earth did you get any of this from?

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

#112

Post by kibwen »

tredre3 wrote: post #91
estebank wrote: post #48

Earlier quoted context omitted.

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…

> I'm sure you have ways to entirely purge a crate.

No, the lesson from left-pad that every centralized package manager learned was that you cannot allow users to remove uploaded packages at their leisure. All outright code removal can only be done manually by the admins themselves, and it's unlikely to happen outside of some legal compulsion.

> Vendoring is the only solution to this but it's really discouraged in rust-land and there is no first-party support for it.

This is completely incorrect. Cargo ships with `cargo vendor` out of the box, it's neither discouraged nor unsupported by first-party tools: https://doc.rust-lang.org/cargo/commands/cargo-vendor.html

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

#113

Post by oytis »

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

Well, ease is one incentive, yes :)

Another is the complexity of the language when it comes to low-level programming. E.g. bytemuck I've mentioned before solves a problem that is hard to even explain to a C developer.

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

#114

Post by SkiFire13 »

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…

> 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

In my opinion what matters is the functionality. If it's provided by a nightly-only crate or as a nightly-only feature of an otherwise non-nightly-only crate it doesn't really matter.

But I agree that this is become more and more rare.

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

#115

Post by nine_k »

estebank wrote: post #80
nine_k wrote: post #66

Earlier quoted context omitted.

> using tools and getting proficient with them rather than relearning tools This attitude works in carpentry, but not in software. You need to get proficient, but your tools will keep evolving, like everything else in the software world.

This attitude doesn't even work in carpentry, depending on the timeframe you look at, tools have changed over time. You can still use a hand saw, where a table saw would be just as suitable, or have a SawStop(tm) and reduce the likelihood of losing a finger.

In carpentry, you still do a lot of work with a hammer which did not change materially for last 70 years. Programming tools did change very, very much since 1956, even though some still retain the recognizable shape (e.g. Lisp or Fortran).

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

#116

Post by acstapleton »

the__alchemist wrote: post #81

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

As a professional in the space, this echoes my experiences. I’m far more productive in Rust than C, despite having many more years programming embedded software in C. Cargo and the crate ecosystem are a dream compared to the lack of any easy-to-use build tooling and the difficulty of integrating third party libraries in C.

Furthermore, the code I’ve produced in Rust is generally as fast (or faster) than the code I’ve written in C for the same task, and it’s easier and faster to write.

And I also maintain an open source HAL for an STM32 family! Previously those have just been in house HALs in C because there were no such community efforts.

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

#117

Post by ezekiel68 »

Lots of handwaving about fear of rust changing too often and even MORE downvoting of this as if there is no concern whatever. Neither of these extremes are valid.

For me it comes down to the old standby: just vendor the .cargo build chain into your repo and be done with it. There you go. Lock in the year edition, the version, the features, the quirks, and the bugs. Just like game devs did with game engines or OpenGL or Direct X versions.

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

#118

Post by the__alchemist »

acstapleton wrote: post #116
the__alchemist wrote: post #81

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

As a professional in the space, this echoes my experiences. I’m far more productive in Rust than C, despite having many more years programming embedded software in C. Cargo and the crate ecosystem are a dream compared to the lack of any easy-to-use build tooling and the difficulty of integrating third party libraries in C. Furthermore, the code I’ve produced in Rust is generally as fast (or faster) than the code I’ve…

Very cool! Which one? I have been using mostly G4 and H7 on my personal and work projects, but the HAL (`stm32-hal2` is the crate name) works for most of the one s in a certain time band; i.e. not any that were obsolte when I started it, and spotty or no support on some of the newer ones like U series and H5. And weaker / non-vetted support on MCU variants I haven't used, or haven't used a MCU/feature combo on.

I think in the future if I do an embedded rust project on a new MCU where there isn't an existing HAL, or one that is more work to repair than start over, I would just implement the subset needed for a project's reqs. Easier to keep track of scope that way. Currently the challenge is "X periph on Y variant of Z STM-32 family doesn't work under A condition" or "Doesn't work after this PAC update changed the syntax".

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

#119

Post by edderly »

torginus wrote: post #41
edderly wrote: post #30

Earlier quoted context omitted.

Yeah, a common stupid requirement. Perhaps a selling point for any solution would be to deploy a common serialization/de-serialization package that can be used on both the cloud and end point side.

Why? In IoT stuff, its very useful if you can talk to your devices via standard internet protocols, otherwise you have to introduce some pointless 'gateway' node for that. I mean sometimes efficiency matters a lot, but a lot of other times, interoperability is more important. Text based IO with microcontrollers over tty has been quite a standard thing even decades ago.

Interoperability would mean you have a meaningful protocol encoded within JSON. JSON itself offers little value.

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

#120

Post by fluffybucktsnek »

megous wrote: post #96
orochimaaru wrote: post #78

Earlier quoted context omitted.

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.

Neither have we with Rust.
Post reply on HN