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

31–40 of 64 posts

Re: This Year in Embedded Rust

#31

Post by zibzab »

Lorkki wrote: post #19
zibzab wrote: post #6

Earlier quoted context omitted.

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.

IIRC last time we had issues it was something in the core libraries, not the compiler.

I think it was something as fundamental as Error being changed or moved around.

Re: This Year in Embedded Rust

#32

Post by zibzab »

eldruin wrote: post #27
capitol_ wrote: post #24

Earlier quoted context omitted.

It happened in the lexical-core crate somewhere in 1.5X. Here is a bug report I got about it with compiler errors listed: https://github.com/cortex/ripasso/issues/219

This issue is on nightly Rust, not stable. A stable Rust compiler update should never break code. See: https://doc.rust-lang.org/book/appendix-07-nightly-rust.html

A lot of embedded stuff needs nightly. Or at least, it was like this a year or two ago.

A related issue is that for many companies "stable" means the version shipped with Ubuntu LTS.

Re: This Year in Embedded Rust

#33

Post by Unklejoe »

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

> I need my code to build/run today and also in 10 years

I think you should stick with C if this is a hard goal. Let Rust settle for some years before going all in.

Re: This Year in Embedded Rust

#34

Post by couchand »

Farmadupe wrote: post #15
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…

> will rust be viable on a puny AVR

There's still plenty of lingering issues (to name just the most glaring, you can't use a compiler since nightly-2021-01-07), but you certainly can use Rust for AVR. I've been writing all my ATtiny projects in Rust for the past year. I've been very satisfied with the ability to write high-level code (zero-sized types are a wonder!) that compiles to assembly more minimal than I'd write by hand.

Re: This Year in Embedded Rust

#35

Post by pornel »

formerly_proven wrote: post #25
algesten wrote: post #20

Earlier quoted context omitted.

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

How does cortex-m v0.6.7 manage to depend on cortex-m v0.7.3?

Cargo has its own interpretation of semver: first non-zero number is the major version, so v0.6 is like v6.0.0 and v0.7 is like v7.0.0. Then each major version is treated as a separate crate, as if it was cortex-m-v6 and cortex-m-v7.

Re: This Year in Embedded Rust

#36

Post by couchand »

megumax wrote: post #22

I would like to see that avr-unknown-gnu-atmega328 works with the latest compiler. Some bug in LLVM broke it[1], because it didn't work starting with versions after nightly-2021-01-07[2]. I know that rust team has nothing to do with this, but they should improve the gcc codegen[3] to be able to run rust on more embedded devices than LLVM has support for. Someone wanted to port his libc written in rust to ia64 and the…

Do you have experience with AVR assembly and calling conventions? There are only a handful of us looking at this issue, none of us have much bandwidth and we could definitely use your help!

Re: This Year in Embedded Rust

#37

Post by couchand »

zibzab wrote: post #32
eldruin wrote: post #27

Earlier quoted context omitted.

This issue is on nightly Rust, not stable. A stable Rust compiler update should never break code. See: https://doc.rust-lang.org/book/appendix-07-nightly-rust.html

A lot of embedded stuff needs nightly. Or at least, it was like this a year or two ago. A related issue is that for many companies "stable" means the version shipped with Ubuntu LTS.

Depends on the architecture: ARM for instance is a tier 1 target and you can use stable.

Re: This Year in Embedded Rust

#38

Post by charcircuit »

Farmadupe wrote: post #15
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…

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

Why should the processing power matter for whether something is embedded or not? To me that just seems like cost optimization for an embedded project.

Re: This Year in Embedded Rust

#39

Post by Icathian »

galangalalgol wrote: post #30
stevefan1999 wrote: post #11

Earlier quoted context omitted.

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…

Explain the crate scanner thing? Ignoring security issues due to crates is no better than ignoring security issues due to memory errors or undefined behavior. And if you are doing safety critical code, where rust would shine, all those dependencies need to be certified to the same level as your own code. Sometimes re-creating and testing and certifying exactly the code you need is faster than reuse. Heresy I know, bu…

I believe that's what the ferrocene project [0] is aiming for. It doesn't seem to be ready yet, but sounds like it might be of interest to you!

0. https://ferrous-systems.com/ferrocene/

Re: This Year in Embedded Rust

#40

Post by bluejekyll »

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…

There are many examples out there of ways to deal with conditional compilation in Rust, and I find it much more straightforward and simple than my own personal experience with C.

Take a look at the socket2 crate as a nice way to deal with different platforms.

The rule of thumb I would use is encode logic as much as possible into traits, and then abstract out specific arch details like fields etc. You can combine conditional compilation units with trait based support as well to reduce the annotations and instead provide functionality only for types that implement certain traits.

Post reply on HN