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

51–60 of 64 posts

Re: This Year in Embedded Rust

#51

Post by follower »

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?

> But are there any vendors actively participating in or supporting Embedded Rust?

That's kind of an interesting question.

While obviously vendor participation can lead to some positive outcomes; my impression is some part of the motivation for Rust targeting the embedded space (and not waiting on vendors) is to avoid reliance on hardware vendors.

Due largely to the poor reputation hardware vendors have in regard to anything in the software tool/firmware space within the C ecosystem.

Re: This Year in Embedded Rust

#52

Post by zibzab »

eldruin wrote: post #42
zibzab wrote: post #31

Earlier quoted context omitted.

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/trai…

In my case it failed to build, maybe it was a different problem, maybe the compiler had at some point emitted errors instead of warnings.

I don't remember and it doesn't really matter other than we had build issues and it was unexpected.

Re: This Year in Embedded Rust

#53

Post by zozbot234 »

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…

The AVR codegen bug is discussed here: https://github.com/rust-lang/rust/issues/82242#issuecomment-... Seems to be due to the LLVM-AVR patchset somehow expecting gcc-compatible compiler intrinsics (for division), whereas Rust provides intrinsics derived from LLVM's compiler-rt, with different calling conventions.

Re: This Year in Embedded Rust

#54

Post by steveklabnik »

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?

In addition to what others have said, ARM has participated in the RFC process, donated CI resources, and joined the Rust Foundation.

There are also a large number of things going on in industry that aren’t yet truly public. Some of these are the “I know something I can’t say” variety and some are the variety of “wow another car manufacturer has posted an embedded Rust job?”

Exiting times ahead.

Re: This Year in Embedded Rust

#55

Post by steveklabnik »

zibzab wrote: post #52
eldruin wrote: post #42

Earlier quoted context omitted.

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/trai…

In my case it failed to build, maybe it was a different problem, maybe the compiler had at some point emitted errors instead of warnings. I don't remember and it doesn't really matter other than we had build issues and it was unexpected.

Deprecation should be the only change to Error in the last six years. It hasn’t moved. If you ever get a repro would love to hear about it! This kind of thing doesn’t happen at the scale we’re at anymore, if it did there would be an uproar.

Re: This Year in Embedded Rust

#56

Post by fwiffo »

I haven't checked Embedded Rust yet, but it is in my todo list. However, my two main embedded targets for C are Z80 and 8051, and my understanding is that these targets are not supported. I'd love to have Rust there.

Re: This Year in Embedded Rust

#57

Post by steveklabnik »

fwiffo wrote: post #56

I haven't checked Embedded Rust yet, but it is in my todo list. However, my two main embedded targets for C are Z80 and 8051, and my understanding is that these targets are not supported. I'd love to have Rust there.

I'm not aware of support for those in LLVM, let alone rustc. Does GCC even have support?

Re: This Year in Embedded Rust

#58

Post by steveklabnik »

couchand wrote: post #37
zibzab wrote: post #32

Earlier quoted context omitted.

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.

This is true for aarch64, but if you're not doing an embedded-linux style project, it's very likely you'll need nightly for inline assembly, though a significant chunk of that is being stabilized as we speak (though sadly not yet enough for my work...)

Re: This Year in Embedded Rust

#59

Post by couchand »

steveklabnik wrote: post #58
couchand wrote: post #37

Earlier quoted context omitted.

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

This is true for aarch64, but if you're not doing an embedded-linux style project, it's very likely you'll need nightly for inline assembly, though a significant chunk of that is being stabilized as we speak (though sadly not yet enough for my work...)

Good point. Though you can always link to .S for that last bit, right? I don't mean to tell you your business, I know you folks are doing much more intense stuff than I am. It doesn't surprise me that you'd know exactly what's keeping you from using stable.

Re: This Year in Embedded Rust

#60

Post by capitol_ »

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

No, it's on stable rust, maybe you got confused by the bug report talking about the nixos-unstable channel, that has nothing to do with the rust nightly builds, it's the version of nixos that is currently under development.

You can reproduce this yourself with:

  git clone https://github.com/cortex/ripasso.git
  cd ripasso
  git checkout release-0.5.1
  cargo build --locked
On my arch system this fails to build with the same errors as the bug report i got, and my rustc version is:

  $ rustc --version --verbose
  rustc 1.57.0 (f1edd0429 2021-11-29)
  binary: rustc
  commit-hash: f1edd0429582dd29cccacaf50fd134b05593bd9c
  commit-date: 2021-11-29
  host: x86_64-unknown-linux-gnu
  release: 1.57.0
  LLVM version: 13.0.0
Post reply on HN