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

41–50 of 159 posts

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

#41

Post by MSFT_Edging »

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…

> connect it to a popular OLED display?

At least for the ssd1306 and the sh1106 there is in fact a library for it that works well.

I recently started working on a rust-esp32 project because I'm far too lazy to properly deal with json in C. It was basic, some buttons, a display, an encoder, and a web api but it was a breeze. I'd really like to continue on more complex projects in the future. I've somehow avoided writing C++ in an embedded setting and now I'm afraid I might have to go back and learn that rather than continue with Rust.

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

#42

Post by bobajeff »

throwaway17_17 wrote: post #25

The paper may be Rust specific, but I found the CVE break down chart on p. 25 interesting. When looking at the percentages of the CVE causes (focused on the 59 bugs classified as those Rust prevents) I got the following: Out of Bounds Reads => 18.6%; Out of Bounds Writes => 62.7%; Null-Ptr Deref => 8.5%; Use-After-Free => 5.1%; Type Confusion, Uninitialized Pointer Access, Memory Leak => EACH 1.5%; I have to wonder a…

I'm with you on that. In fact I think it's needed to use something less complex than rust in order to prevent other bugs from cropping up due to misunderstood parts of language.

C has some bad things it does by default that lead to terrible bugs. I imagine many of them can be addressed without complex move semantics added to it.

Some promising work I've seen in this area had been the adoption of language level allocators in zig and Odin. Many newer languages also have better arrays come with length information. And array languages like APL avoid out of bounds errors.

I don't think you have to go full ML style type checker (or borrow checker) to prevent bugs.

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

#43

Post by bsder »

adrianN wrote: post #36
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…

Interfacing C with Rust is actually a well supported use case.

Not really.

The semantics as you cross the boundary are ill-defined. And you will pay dearly if the C library wants to own any of the resources (like an event loop).

And "unsafe" programming in Rust is really difficult to get right--possibly harder than C.

To be fair, these problems are not inherent to Rust--any language which tries to interface with C will have them.

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

#44

Post by hajile »

outworlder wrote: post #34
jcelerier wrote: post #28

Earlier quoted context omitted.

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

That's good when it's just about memory leaks. Your missile guidance code can have leaks as long as the missile completes the mission, since it will all be... "garbage collected" anyway. It's not great when you have problems like use after free and pointers going to where they don't belong. Those can cause security vulnerabilities that rebooting won't fix.

Then they make a version that flies farther and it sometimes randomly fails to detonate.

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

#45

Post by marcosdumay »

logicchains wrote: post #39
marcosdumay wrote: post #31

Earlier quoted context omitted.

The C and C++ ecosystems are suffering from a selection effect, in that the people that have any concern about their code being correct are trying to drop them, while the people comfortable with the language are all the ones that don't know about the problems. I expect the careless unaware culture to get worse with time as more and more aware people manage to leave it.

>the people comfortable with the language are all the ones that don't know about the problems. Or the ones writing code where security doesn't matter, like HFT and video games (the former have no users, and the latter are basically impossible to make crack-resistant even if they're written entirely in Rust).

It's not only security, it's correctness. It's about your software staying running and doing the right thing.

I can believe HFT developers think they don't need it.

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

#46

Post by sheepybloke »

Honestly, the biggest thing that concerns me with using Rust for embedded is the size of the crates. We were looking to do some packages for a product, and the Rust packages were huge compared to the C++ ones. Granted, this was mostly because the C++ ones could use .so's, while Rust had to compile those into the crate, but this is a huge issue when doing OTA updates.

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

#47

Post by svnt »

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.

Beginning by using the register listings in the datasheet is what parent meant by “from scratch.” Anything more would have been reverse engineering.

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

#48

Post by pornel »

throwaway17_17 wrote: post #25

The paper may be Rust specific, but I found the CVE break down chart on p. 25 interesting. When looking at the percentages of the CVE causes (focused on the 59 bugs classified as those Rust prevents) I got the following: Out of Bounds Reads => 18.6%; Out of Bounds Writes => 62.7%; Null-Ptr Deref => 8.5%; Use-After-Free => 5.1%; Type Confusion, Uninitialized Pointer Access, Memory Leak => EACH 1.5%; I have to wonder a…

A bounds-checked slice type would be a relatively small addition to C, and if adopted, it would make size tracking and bounds checking easier.

However, there's generally a strong pushback from C developers against features that have an unnecessary performance overhead.

Having reliable bounds checking without run-time cost if a much more complicated problem. Rust uses iterators for this, but that requires generics and specialization, and compared to C, these are big and complex features.

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

#49

Post by steveklabnik »

sheepybloke wrote: post #46

Honestly, the biggest thing that concerns me with using Rust for embedded is the size of the crates. We were looking to do some packages for a product, and the Rust packages were huge compared to the C++ ones. Granted, this was mostly because the C++ ones could use .so's, while Rust had to compile those into the crate, but this is a huge issue when doing OTA updates.

It's just something you have to care about, but it's not a show-stopper. We use a bunch of crates in our projects at work, I left some example sizes in a comment a while back https://news.ycombinator.com/item?id=34032824

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

#50

Post by adrianN »

bsder wrote: post #43
adrianN wrote: post #36

Earlier quoted context omitted.

Interfacing C with Rust is actually a well supported use case.

Not really. The semantics as you cross the boundary are ill-defined. And you will pay dearly if the C library wants to own any of the resources (like an event loop). And "unsafe" programming in Rust is really difficult to get right--possibly harder than C. To be fair, these problems are not inherent to Rust--any language which tries to interface with C will have them.

>To be fair, these problems are not inherent to Rust--any language which tries to interface with C will have them.

Yes, including C.

Post reply on HN