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

71–80 of 159 posts

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

#71

Post by jcranmer »

Animats wrote: post #66
jcranmer wrote: post #62

Earlier quoted context omitted.

> It's been done, but what comes out is terrible Rust. Everything is unsafe types with C semantics. The idea behind the current c2rust tool is that you'd do a one-shot conversion to Rust and then gradually do refactoring passes over the barely-Rust code to convert it to correct C code. The focus is on preserving semantics of C over writing anything close to idiomatic (cue a + b being translated to a.wrapping_add(b) a…

> The idea behind the current c2rust tool is that you'd do a one-shot conversion to Rust and then gradually do refactoring passes over the barely-Rust code to convert it to correct C code. I've seen what comes out of the transpiler. Nobody should touch that code by hand. It's awful Rust, and uglier than the original C. Modifying that by hand is like modifying compiler-generated machine code. > This is actually why C2…

> I've seen what comes out of the transpiler. Nobody should touch that code by hand. It's awful Rust, and uglier than the original C.

I can't disagree here. I think the original idea was to rely on automated refactoring tools to try to make the generated Rust somewhat more palatable, but I never was able to get that working.

> C23 doesn't actually use that info.

True; the intent is to require it so that it can be leveraged by future extensions. The C committee tends to move glacially.

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

#72

Post by kibwen »

palata wrote: post #68
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…

> People dramatically overestimate the correctness of their [C/C++] code Genuinely interested: what do people think of their tons of third-party dependencies in Rust? My experience building Rust projects is that there are orders of magnitudes more dependencies than what would make me comfortable. At least in C/C++ it's much harder to get there.

I use embedded Rust for my day job. We keep our third-party dependencies purposefully minimal, but I adore that they're there when I need to reach for them. Like, we just needed a basic TCP stack to get our PoC up and running, so I can just grab smoltcp and be off to the races. Being written in C or C++ wouldn't obviate our need for a TCP stack, I'd still either need to get it from somewhere else or write it myself. And even if I can't use a third-party dependency for whatever reason (e.g. if it doesn't support no_std mode), I can still usually repurpose their existing test suite to give me confidence in my port or reimplementation.

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

#73

Post by xormapmap »

atoav wrote: post #23

As a rust programmer that programs C++ on embedded, the main thing preventing adoption is the ecosystem. So let's say I happen to work with a MCU that is well supported in Rust, what if I want to connect it to a popular OLED display? Is there a library for that? If so, does it work? If it works, does it have the needed features? Now maybe I am incredibly lucky and all of that works, what about a popular gyro IC? Gran…

> Is there a library for that?

What? Are there really people out there relying on libraries for every peripheral? I've never seen anyone use a third party library for peripherals like that, short of some prototyping on an Arduino or the like. It's always just drivers implemented from scratch.

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

#74

Post by tamimio »

the__alchemist wrote: post #37
tamimio wrote: post #26

Personally in the past ~2 years I have been trying to shift my code base to rust when it comes to robotics and drones software, the biggest issue is the integration part, most “addons” that you can integrate with the robots like Lidar and other sensors come with the usual SDKs in C/C++ or even python. Additionally, most of X-rust converters don’t really work so you end up rewriting it from scratch.

What sorts of parts? Most should have register-level APIs in the datasheet. That doesn't mean integrating is easy though, compared to the SDK.

> What sorts of parts?

A lot of parts I had to work with didn’t have it, last one a couple months ago for example was a guided parachute for a drone dropper, I ended up making the driver from scratch that interfaced with the serial io.

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

#75

Post by RealityVoid »

mips_r4300i wrote: post #24

How long before I can visually debug rust on MCUs with source level stepping in my IDE? Til then, no way to switch.

Like... zero days? You can just plop the .elf in gdb and then debug on target. I just did it on a riscv mcu just a couple hours ago.

Rust is there on the embedded, the only thing missing is people realising it's there.

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

#76

Post by tamimio »

xyst wrote: post #60
tamimio wrote: post #26

Personally in the past ~2 years I have been trying to shift my code base to rust when it comes to robotics and drones software, the biggest issue is the integration part, most “addons” that you can integrate with the robots like Lidar and other sensors come with the usual SDKs in C/C++ or even python. Additionally, most of X-rust converters don’t really work so you end up rewriting it from scratch.

What’s wrong with wrapping the C headers in rust? Seems possible to me, although a bit labor intensive depending on the C/C++ lib — https://docs.rust-embedded.org/book/interoperability/c-with-...

Nothing is wrong with that, it’s rather a workaround, ultimately I am trying to have one language only including the UI too (been playing with egui),so I don’t have to use JavaScript.

https://github.com/emilk/egui

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

#77

Post by navaati »

znpy wrote: post #33
atoav wrote: post #23

As a rust programmer that programs C++ on embedded, the main thing preventing adoption is the ecosystem. So let's say I happen to work with a MCU that is well supported in Rust, what if I want to connect it to a popular OLED display? Is there a library for that? If so, does it work? If it works, does it have the needed features? Now maybe I am incredibly lucky and all of that works, what about a popular gyro IC? Gran…

> As a rust programmer that programs C++ on embedded, the main thing preventing adoption is the ecosystem. Maybe the mindset of the industry as well? Not sure if things have changed (and if so, how) but 9-10 years ago when i was in university I had an interview with a company that did embedded systems stuff. While talking about my competencies I mentioned I was able to create cross-toolchain if they were interested a…

Well lucky us, Espressif is officially providing Rust packages for the ESP32 chips :) !

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

#78

Post by kevin_thibedeau »

jcelerier wrote: post #28
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…

> People dramatically overestimate the correctness of their [C/C++] code and underestimate the potential severity of failures to meet that expectation Really depends on the field. I heard more than once in my life now that it's better to reboot every night than spend even an afternoon of engineering trying to fix memory leaks.

MongoDB's BSON library calls abort() on malloc failure because they can't be bothered to handle OOM gracefully.

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

#79

Post by Animats »

jcranmer wrote: post #71
Animats wrote: post #66

Earlier quoted context omitted.

> The idea behind the current c2rust tool is that you'd do a one-shot conversion to Rust and then gradually do refactoring passes over the barely-Rust code to convert it to correct C code. I've seen what comes out of the transpiler. Nobody should touch that code by hand. It's awful Rust, and uglier than the original C. Modifying that by hand is like modifying compiler-generated machine code. > This is actually why C2…

> I've seen what comes out of the transpiler. Nobody should touch that code by hand. It's awful Rust, and uglier than the original C. I can't disagree here. I think the original idea was to rely on automated refactoring tools to try to make the generated Rust somewhat more palatable, but I never was able to get that working. > C23 doesn't actually use that info. True; the intent is to require it so that it can be lev…

The real problem is not translating code. It's translating data types. If you can determine that a "char *" in C can be a Vec in Rust, you're most of the way there. It's no longer ambiguous what to do with the accesses.

This is where I think LLMs could help. Ask an LLM "In this code, could variable "buf" be safely represented as a Rust "Vec", and if so, what is its length?. LLMs don't really know the languages, but they have access to many samples, which is probably good enough to get a correct guess most of the time. That's enough to provide annotation hints to a dumb translator. The problem here is translating C idioms to Rust idioms, which is an LLM kind of problem.

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

#80

Post by fuzztester »

tamimio wrote: post #26

Personally in the past ~2 years I have been trying to shift my code base to rust when it comes to robotics and drones software, the biggest issue is the integration part, most “addons” that you can integrate with the robots like Lidar and other sensors come with the usual SDKs in C/C++ or even python. Additionally, most of X-rust converters don’t really work so you end up rewriting it from scratch.

>that you can integrate with the robots like Lidar and other sensors come with the usual SDKs in C/C++ or even python.

Do the Python SDKs run fast enough? Genuine question. I've done a good amount of Python, but don't have any idea of how suitable it is for embedded stuff, other than knowing that MicroPython exists.

Post reply on HN