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

Rust for Embedded Systems: Current state, challenges and open problems

arxiv.org

Post reply on HN
Print view View original

11–20 of 159 posts

Re: Rust for Embedded Systems: Current state, challenges and open problems

#11

Post by the__alchemist »

fusslo wrote: post #5

my takeaways: 1. https://arewertosyet.com/ to track rust RTOSes and their status 2. there are tools to convert c to rust (I dont know if I'd trust this..) 3. "Out of 43 different MCU families, peripheral crates are currently available for only 16 (37%). Most of these crates are generated using svd2rust utility" 4. developers considered but rejected rust because: "Lack of Support for MCUs (36%) ; Difficulty Integratin…

> I would adopt rust if it were easy to get up and running just while(1) loop applications.

It is: Install the toolchain (eg `rustup target add thumbv7hibf`); install probe-rs; `cargo run`. I think getting applications up and running in embedded rust is one of its strengths.

Re: Rust for Embedded Systems: Current state, challenges and open problems

#12

Post by jcranmer »

fusslo wrote: post #5

my takeaways: 1. https://arewertosyet.com/ to track rust RTOSes and their status 2. there are tools to convert c to rust (I dont know if I'd trust this..) 3. "Out of 43 different MCU families, peripheral crates are currently available for only 16 (37%). Most of these crates are generated using svd2rust utility" 4. developers considered but rejected rust because: "Lack of Support for MCUs (36%) ; Difficulty Integratin…

> 2. there are tools to convert c to rust (I dont know if I'd trust this..)

The core C specification by itself isn't all that complicated of a language; a C-to-Rust transpiler is a pretty doable project.

The main issues here are that

a) a lot of the code you'd likely want to convert is likely to be reliant on non-standard extensions

b) there's a lot of undefined behavior which you probably want to have somewhat more defined behavior on, especially in embedded contexts

c) the real goal for a lot of this automated conversion is to do the conversion once and work well enough that you don't have to audit the result of the conversion, and because of especially the previous point, it's really hard to get that level of trust for C code.

The existing c2rust converter works by creating the clang AST and then lowering that to Rust source code, which I'm not sure is a path that would lead me to high confidence in the converted code due to the potential impedance mismatch in understanding the clang AST. A custom C frontend is probably a better match here for a long term project (C, unlike C++, is feasible to build your own compiler from scratch), or maybe another project idea is to convert LLVM IR to Rust and ditch the C frontend entirely.

Re: Rust for Embedded Systems: Current state, challenges and open problems

#13

Post by mikeInAlaska »

I spent a weekend with Rust, a Raspi4, and our buddy GPT about six months ago. In that weekend I was able to get the Raspi controlling a OLED display via SPI with an SSD1306 controller. I thought it was a fairly clean port from C++, and GPT was well educated on how to use the RASPI SPI and I2C busses from Rust.

I don't think I would be able to approach it on an ESP32 or AVR xMega or some other real microcontroller.

Re: Rust for Embedded Systems: Current state, challenges and open problems

#14

Post by monocasa »

mikeInAlaska wrote: post #13

I spent a weekend with Rust, a Raspi4, and our buddy GPT about six months ago. In that weekend I was able to get the Raspi controlling a OLED display via SPI with an SSD1306 controller. I thought it was a fairly clean port from C++, and GPT was well educated on how to use the RASPI SPI and I2C busses from Rust. I don't think I would be able to approach it on an ESP32 or AVR xMega or some other real microcontroller.

Bare metal or on linux?

Re: Rust for Embedded Systems: Current state, challenges and open problems

#15

Post by adameasterling »

AlotOfReading wrote: post #7

These are all real issues with Rust, though it's worth noting that many of the integration challenges mentioned also apply to external code written in C and C++. Some of the survey responses highlight one of the biggest hurdles to rust adoption I've experienced though: Rust has an education problem. People dramatically overestimate the correctness of their [C/C++] code and underestimate the potential severity of fail…

> I've found very few projects where a bit of poking can't turn up memory safety issues.

I'm working on a Rust project right now, and I'm probably one of those people who are overestimating the correctness of my code! I would love to know about what sorts of memory safety issues you often uncover.

Re: Rust for Embedded Systems: Current state, challenges and open problems

#16

Post by dboreham »

AlotOfReading wrote: post #7

These are all real issues with Rust, though it's worth noting that many of the integration challenges mentioned also apply to external code written in C and C++. Some of the survey responses highlight one of the biggest hurdles to rust adoption I've experienced though: Rust has an education problem. People dramatically overestimate the correctness of their [C/C++] code and underestimate the potential severity of fail…

I had to read this a couple of times, but I suspect this is about non-rust code, when you cite correctness of code, yes? People don't want to use rust because they think their janky C/C++ is just fine.

Re: Rust for Embedded Systems: Current state, challenges and open problems

#17

Post by rcxdude »

fusslo wrote: post #5

my takeaways: 1. https://arewertosyet.com/ to track rust RTOSes and their status 2. there are tools to convert c to rust (I dont know if I'd trust this..) 3. "Out of 43 different MCU families, peripheral crates are currently available for only 16 (37%). Most of these crates are generated using svd2rust utility" 4. developers considered but rejected rust because: "Lack of Support for MCUs (36%) ; Difficulty Integratin…

In general I get the impression that embedded rust is fairly good for while(1) loop applications: the kind of thing you can do with arduino is also usually fairly easy to do in rust, modulo maybe not so good library support for random bits of hardware. What I generally see lacking is support for multitasking: the various HALs generally only support synchronous, usually only busy-loop blocking implementations, which is really limiting for a lot of embedded applications. This kind of thing is hard to get right, though.

(in fact, while I like the theory of generic embedded HALs, I have yet to see a good implementation of the concept. Most effective HALs I have seen are specialised to one area or another, usually to one particular application)

Re: Rust for Embedded Systems: Current state, challenges and open problems

#18

Post by Aurornis »

fusslo wrote: post #5

my takeaways: 1. https://arewertosyet.com/ to track rust RTOSes and their status 2. there are tools to convert c to rust (I dont know if I'd trust this..) 3. "Out of 43 different MCU families, peripheral crates are currently available for only 16 (37%). Most of these crates are generated using svd2rust utility" 4. developers considered but rejected rust because: "Lack of Support for MCUs (36%) ; Difficulty Integratin…

> 3. "Out of 43 different MCU families, peripheral crates are currently available for only 16 (37%).

There are a lot of obscure MCU families out there. Most engineers or shops specialize in a couple, become familiar with those, and stick to it. Using and learning a brand new MCU family is a lot of work.

As long as I can find Rust support for common MCUs that I use, I don’t care how broadly the rest of the market is covered.

Re: Rust for Embedded Systems: Current state, challenges and open problems

#19

Post by AlotOfReading »

adameasterling wrote: post #15
AlotOfReading wrote: post #7

These are all real issues with Rust, though it's worth noting that many of the integration challenges mentioned also apply to external code written in C and C++. Some of the survey responses highlight one of the biggest hurdles to rust adoption I've experienced though: Rust has an education problem. People dramatically overestimate the correctness of their [C/C++] code and underestimate the potential severity of fail…

> I've found very few projects where a bit of poking can't turn up memory safety issues. I'm working on a Rust project right now, and I'm probably one of those people who are overestimating the correctness of my code! I would love to know about what sorts of memory safety issues you often uncover.

Made it more clear in the original post that I was talking about the correctness of C and C++ code. I haven't observed any notable issues with this in Rust compared to similar languages, but I also don't have the same depth of experience building large systems in it to show me the error of my ways yet.

Re: Rust for Embedded Systems: Current state, challenges and open problems

#20

Post by mikeInAlaska »

monocasa wrote: post #14
mikeInAlaska wrote: post #13

I spent a weekend with Rust, a Raspi4, and our buddy GPT about six months ago. In that weekend I was able to get the Raspi controlling a OLED display via SPI with an SSD1306 controller. I thought it was a fairly clean port from C++, and GPT was well educated on how to use the RASPI SPI and I2C busses from Rust. I don't think I would be able to approach it on an ESP32 or AVR xMega or some other real microcontroller.

Bare metal or on linux?

Linux
Post reply on HN