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

41–50 of 64 posts

Re: This Year in Embedded Rust

#41

Post by Farmadupe »

charcircuit wrote: post #38
Farmadupe wrote: post #15

Earlier quoted context omitted.

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

Yes I agree such a system is definitely embedded.. I think I was deliberately constructing a straw man in a (bad) effort to poke fun at people such as myself who have 'opinions' on what embedded 'really is'... "640k is enough for anyone" "C compilers are for people who cant write good assembly" etc etc.. https://xkcd.com/378/

I think it's possible to accidentally use that straw man to justify fears when looking at embedded rust.. But as other people have pointed out in this thread, just because rusty interrupt handlers look weird doesn't work any better or worse than one written in C.

Re: This Year in Embedded Rust

#42

Post by eldruin »

zibzab wrote: post #31
Lorkki wrote: post #19

Earlier quoted context omitted.

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

You may have started getting deprecation warnings because some methods in the `Error` trait have been deprecated [1] in favor of a different mechanism.

Then, you may have configured warnings to result in compilation errors in your build/project, however, I would argue this situation is not what most people would understand as "code not compiling due to a compiler update".

[1]: https://doc.rust-lang.org/std/error/trait.Error.html

Re: This Year in Embedded Rust

#43

Post by stavros »

couchand wrote: post #34
Farmadupe wrote: post #15

Earlier quoted context omitted.

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

Do you have any tutorials for this? I'm an embedded newbie and all the things I've seen required more knowledge than I have to either get to hello world or move an iota past it.

Re: This Year in Embedded Rust

#44

Post by couchand »

stavros wrote: post #43
couchand wrote: post #34

Earlier quoted context omitted.

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

Do you have any tutorials for this? I'm an embedded newbie and all the things I've seen required more knowledge than I have to either get to hello world or move an iota past it.

For AVR specifically, no. The Embedded Book [0] (which uses the ARM-based Discovery board) is a great introduction.

I can envision a future where clean abstractions are written that can provide an Arduino-like experience in Rust, but we are still a long way from there.

You are making me want to write some Rust AVR tutorials. Once we get the latest compiler building AVR code again, that will be my next focus.

[0]: https://docs.rust-embedded.org/book/

Re: This Year in Embedded Rust

#45

Post by eldruin »

stavros wrote: post #43
couchand wrote: post #34

Earlier quoted context omitted.

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

Do you have any tutorials for this? I'm an embedded newbie and all the things I've seen required more knowledge than I have to either get to hello world or move an iota past it.

Are you looking specifically at AVR? ARM works out-of-the-box with stable Rust.

I can really recommend getting a micro:bit board and following the discovery book [1].

There are a few other books in the embedded Rust bookshelf [2].

Otherwise, I wrote a bunch of sensor drivers and simple examples for several boards: [3]

[1]: https://docs.rust-embedded.org/discovery/index.html

[2]: https://docs.rust-embedded.org/

[3]: https://github.com/eldruin/driver-examples

Re: This Year in Embedded Rust

#46

Post by stavros »

eldruin wrote: post #45
stavros wrote: post #43

Earlier quoted context omitted.

Do you have any tutorials for this? I'm an embedded newbie and all the things I've seen required more knowledge than I have to either get to hello world or move an iota past it.

Are you looking specifically at AVR? ARM works out-of-the-box with stable Rust. I can really recommend getting a micro:bit board and following the discovery book [1]. There are a few other books in the embedded Rust bookshelf [2]. Otherwise, I wrote a bunch of sensor drivers and simple examples for several boards: [3] [1]: https://docs.rust-embedded.org/discovery/index.html [2]: https://docs.rust-embedded.org/ [3]: h…

I mainly have ATTinys and ESPs, both of which kinda-maybe work but are hard to get started with. I'll look at your examples, thank you!

I might also play with ARM a bit, I have a few black pills that hopefully will be easier to get started with, now that I think about it.

Re: This Year in Embedded Rust

#47

Post by jcelerier »

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…

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

Why not just use it as-is for Rust ? There are plenty of non-C/C++ things which use cpp. X11 uses it for config files (.Xresources for instance afaik). I think that polkit or something like that uses it too for its config files. I've seen it used in Java.

Re: This Year in Embedded Rust

#48

Post by follower »

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…

> Explain the crate scanner thing?

I assume a reference to tools that help manage potential issues around dependencies, e.g.:

* https://github.com/rustsec/rustsec/tree/main/cargo-audit

* https://github.com/EmbarkStudios/cargo-deny

"[cargo-audit] Audit Cargo.lock files for crates with security vulnerabilities reported to the RustSec Advisory Database."

"cargo-deny is a cargo plugin that lets you lint your project's dependency graph to ensure all your dependencies conform to your expectations and requirements." e.g. license, security advisories, source.

Re: This Year in Embedded Rust

#49

Post by pjmlp »

tialaramex wrote: post #16
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 fail…

And now we can even do the same exercise across multiple compiled languages to prove point that C isn't special.

Re: This Year in Embedded Rust

#50

Post by follower »

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…

Are you able to provide a barebones specific code example (either in C/C++ or Rust) of the issue(s) you're describing (e.g. nesting/chaining) where Rust conditional compilation is limiting?

A specific example is likely to lead to a more educational discussion in terms of learning about a solution to issues that you've observed or highlighting currently unsolved issues with Rust's implementation.

Either of which would be valuable.

Post reply on HN