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

This Year in Embedded Rust

blog.rust-embedded.org

Post reply on HN
Print view View original

11–20 of 64 posts

Re: This Year in Embedded Rust

#11

Post by stevefan1999 »

zibzab wrote: post #4

Two things have kept me away from embedded Rust before 1. A huge chain of dependencies. Security issues aside, I prefer my embedded code to be lean and clean. 2. A big departure from how things used to be done in this world. For example interrupt handlers almost look like AWS lambda code to me. Maybe that's the future, I don't know. But right now I am not comfortable with this way of doing low level coding. But I am…

Using Rust mods is exactly being lean and clean: would you rather take a bunch of include files, stupidly duplicates them in almost every translation units, and this would eventually blows up at some point of time, and is hard to reconfigure with some mysterious macro induced error, or, would you inter-depend on bunch of crates that might pull over 100mb of stuff at total that might have potential supply chain attack because it is too convenient to use modularized code?

I myself rather take the latter, at least the risk of not compiling successfully is lower and the chance of getting something done is higher. Security issue aside, there are crate scanners that exactly prevents this, and how can you do that with C?

Also, embedded code looking like Lambda code is a very good thing: both embedded system and Lambda are focused on doing one thing and do its best

Re: This Year in Embedded Rust

#12

Post by berkut »

AnyTimeTraveler wrote: post #9
berkut wrote: post #7

One of the things I really find limiting in Rust compared to C/C++ is conditional compilation, i.e. for different architectures: yes, the C/C++ pre-processor does suck in many ways and is masochistic if you're not careful, but it's also incredibly flexible. Conditional compilation in Rust can be done per module, so in theory you can have different archs in different .rs files, each imported conditionally, but that th…

I just checked. You can also add those same conditionals to functions and structs. So you don't have to in- or exclude whole modules. You can even use it in an if-statement, as seen in the example main function on the page I linked. See here: https://doc.rust-lang.org/rust-by-example/attribute/cfg.html

Yes, but now try nesting or chaining them...

It's do-able with cfg_if crate macro, but I really don't think much of the result in many complex situations, compared to what can be done in C/C++.

Also, using the cfg! macro (which you need to do to use it in logic) I think is stripped out at link time (I had all sorts of issues with this), so if you've got intrinsics which don't compile on the current platform, that's not helpful (maybe I did something wrong here, but I've googled it a lot, and asked for help several times on the Rust Discord server).

Re: This Year in Embedded Rust

#13

Post by maxwell86 »

berkut wrote: post #12
AnyTimeTraveler wrote: post #9

Earlier quoted context omitted.

I just checked. You can also add those same conditionals to functions and structs. So you don't have to in- or exclude whole modules. You can even use it in an if-statement, as seen in the example main function on the page I linked. See here: https://doc.rust-lang.org/rust-by-example/attribute/cfg.html

Yes, but now try nesting or chaining them... It's do-able with cfg_if crate macro, but I really don't think much of the result in many complex situations, compared to what can be done in C/C++. Also, using the cfg! macro (which you need to do to use it in logic) I think is stripped out at link time (I had all sorts of issues with this), so if you've got intrinsics which don't compile on the current platform, that's n…

That’s trivial to do with cfg-if and similar crates.

There are many Rust libraries that support dozen different hardware architectures using conditional compilation.

Rust has many pain points, but conditional compilation isn’t one.

What ever weird constraint or desire you have, a macro would solve it nicely for your case.

Re: This Year in Embedded Rust

#14

Post by howenterprisey »

DoingIsLearning wrote: post #2

It's great to see a community forming and the general enthusiasm. But are there any vendors actively participating in or supporting Embedded Rust? For example is any vendor porting drivers to native Rust?

There's at least a decent amount of interest from both industry (auto tier 1's, for example) and from vendors; I'd love to name names here but I'm pretty sure I can't. :)

Re: This Year in Embedded Rust

#15

Post by Farmadupe »

zibzab wrote: post #4

Two things have kept me away from embedded Rust before 1. A huge chain of dependencies. Security issues aside, I prefer my embedded code to be lean and clean. 2. A big departure from how things used to be done in this world. For example interrupt handlers almost look like AWS lambda code to me. Maybe that's the future, I don't know. But right now I am not comfortable with this way of doing low level coding. But I am…

> 1. A huge chain of dependencies.

I think there is another side to this coin though. IMO there are too many embedded shops that overlook reliable 3rd-party code in favour of spending man-hours growing their own code from seed instead. Or if not that you spend days debugging some greybeard coworker's "Oh I think I wrote something like that 25 years ago for a PDP-11, I'll just email it to you.."

But to be honest I don't really disagree all that much -- As much as the embedded world needs to keep up with the times, there's no way that the level of audit required for a reliable embedded project just can keep up with how quickly crates are being changed.

> 2. A big departure from how things used to be done in this world.

Sometimes I cringe too when takes a massive server board with 9999GB of RAM and a 4g modem and calls it "embedded" just because they screwed it to the side of a helicopter... But if the root question is "will rust be viable on a puny AVR" I hope that the answer is definitely yes.

Re: This Year in Embedded Rust

#16

Post by tialaramex »

zibzab wrote: post #4

Two things have kept me away from embedded Rust before 1. A huge chain of dependencies. Security issues aside, I prefer my embedded code to be lean and clean. 2. A big departure from how things used to be done in this world. For example interrupt handlers almost look like AWS lambda code to me. Maybe that's the future, I don't know. But right now I am not comfortable with this way of doing low level coding. But I am…

I can definitely see the objection to running Nightly to build actual embedded systems. Two ex-colleagues built embedded devices that were intentionally injected into glaciers for measurement purposes, obviously "Oops, we need to upgrade them" isn't much more of a thing while they're working than for the Mars rovers - if you don't have a way to remotely upgrade the part that needs changing, or your radio upgrade fails and you brick the device you can't send a field technician to fix it.

And personally I never run Nightly, I did AoC for example entirely in stable because I don't feel like I need more excitement in my life.

The "it looks alien" thing (which is how I read your comment about "looks like AWS lambda code to me") I think is a place where Godbolt can help you if you're serious enough about low-level to be at least confident reading assembler even if you never write any. Matt Godbolt built Compiler Explorer's ancestors because he knew that nicer C++ iterators claimed to have the same performance characteristics as the good-old C style for loops he'd grown up with but he needed to be sure that was a fact before he moved vital performance critical software to them. Compiler Explorer shows that yup, you get equivalent assembler, the machine is doing the exact same work as before. I think you'll find Rust's "like AWS lambda code" for interrupt handlers is eventually doing the same low-level bit twiddling you're used to writing, but presented in a different (safer) way.

FWIW HN formats the space-prefixed paragraphs in your text as fixed pitch like code, which is annoying for people on small devices when you aren't actually showing code or diagrams where spacing is important to understanding.

Re: This Year in Embedded Rust

#17

Post by berkut »

maxwell86 wrote: post #13
berkut wrote: post #12

Earlier quoted context omitted.

Yes, but now try nesting or chaining them... It's do-able with cfg_if crate macro, but I really don't think much of the result in many complex situations, compared to what can be done in C/C++. Also, using the cfg! macro (which you need to do to use it in logic) I think is stripped out at link time (I had all sorts of issues with this), so if you've got intrinsics which don't compile on the current platform, that's n…

That’s trivial to do with cfg-if and similar crates. There are many Rust libraries that support dozen different hardware architectures using conditional compilation. Rust has many pain points, but conditional compilation isn’t one. What ever weird constraint or desire you have, a macro would solve it nicely for your case.

It's do-able, but you seem to have to go out of your way organise code or modules in sub-optimal ways to compensate in many cases.

Most of the crates which I've seen which do that kind of thing in my experience seem to use features or conditional modules, which as I've discussed above have other downsides. Others like Vek seem to just get LLVM to do the work.

I think that's a bit disingenuous: I've certainly found Rust's infrastructure in this area quite limiting and a pain point for myself.

Re: This Year in Embedded Rust

#18

Post by stbtrax »

eldruin wrote: post #8
DoingIsLearning wrote: post #2

It's great to see a community forming and the general enthusiasm. But are there any vendors actively participating in or supporting Embedded Rust? For example is any vendor porting drivers to native Rust?

Espressif (the makers of the hugely popular ESP32/ESP8266/... microcontrollers) hired an embedded Rust community member to work full time on Rust support for their chips: https://mabez.dev/blog/posts/esp-rust-espressif/

Does Espressif have large marketshare outside of hobbyists?

Re: This Year in Embedded Rust

#19

Post by Lorkki »

zibzab wrote: post #6
AlexanderDhoore wrote: post #3

I really hope embedded rust can become the next rock-solid foundation. I need my code to build/run today and also in 10 years. We have code in our codebase from at least the early 90s but I suspect it's older than that. I went into embedded because I really despise the code churn of higher level frameworks/languages. "We just released Qt5! Good luck rewriting your code."

If that's your goal I think you should wait a few years before starting using Rust. We have already seen early Rust code not compiling with new compiler releases. Right now we are in a move fast and break things phase. Also, you need to be careful about what you implement yourself and what you import from crates. Otherwise it will be qt5 all over again.

> We have already seen early Rust code not compiling with new compiler releases.

I haven't really seen that happen with post-1.0 Rust, which is everything onwards of early 2015. I believe they've since tightened a couple of edge cases due to soundness issues, but nothing worse than that.

Would be interesting to hear about your contrary experiences.

Re: This Year in Embedded Rust

#20

Post by algesten »

zibzab wrote: post #4

Two things have kept me away from embedded Rust before 1. A huge chain of dependencies. Security issues aside, I prefer my embedded code to be lean and clean. 2. A big departure from how things used to be done in this world. For example interrupt handlers almost look like AWS lambda code to me. Maybe that's the future, I don't know. But right now I am not comfortable with this way of doing low level coding. But I am…

> A huge chain of dependencies. Security issues aside, I prefer my embedded code to be lean and clean.

Where does your limit go for that? I wrote a eurorack modular embedded thing on Teensy 4.0 (imxrt) in Rust this year. I just inspected the dep tree, it's 38 crates, with 1 being my own.

https://gist.github.com/algesten/9617fc795f2fc94009f1ed311b1...

It was a joy to write this in Rust, I look forward to my next project. This was done with "stable" (not nightly).

Post reply on HN