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

81–90 of 159 posts

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

#81

Post by yeeeloit »

MSFT_Edging wrote: post #41
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 writi…

Why do you think you might have to go back and to C++?

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

#82

Post by [deleted] »

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.

[deleted]

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

#83

Post by von_lohengramm »

steveklabnik wrote: post #70
bigyikes wrote: post #61

Earlier quoted context omitted.

Is video game security an entire subfield of its own? I imagine there are categories of exploits in video games which simply don’t exist in other areas of software

The latest in FPS cheating (that I'm aware of, not like I'm super plugged into the underground) involves buying a second PC to run the cheats, a card for your main PC to grab a copy of memory over DMA, ship it off to the second PC, then joining the two video feeds together. Apparently you can also hook your mouse up to a connection where it will edit the data flowing from the mouse to give you better aim as well. A l…

You would only ever do all that if you had no clue what you are doing (and most don't). It's rather trivial to bypass modern kernel anticheats, especially with a hacked up KVM or custom hypervisor. So much of anti-cheat nowadays is based off of automated (delayed) detection and user reports that you can easily ragehack to the the top ranks without ban if you just use silentaim (aimbot that doesn't need to change your view angles) and common sense.

In fact, I'd go so far as to say that a majority of players in the top ranks of most popular FPSs are cheaters or queue with cheaters. There's nothing quite like watching the enemy stare right at you through every wall across the map and then carelessly run in a straight line towards you. Even more concerning is how many streamers queue up with blatant cheaters and then use their connections with game moderators to manually ban other cheaters.

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

#84

Post by tialaramex »

kevin_thibedeau wrote: post #78
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.

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

That seems completely reasonable. The only interesting case is "There was far too little storage, so we gave up early" e.g. you need 14GB, there is 186MB available, give up. I probably don't want my photo viewer to crash because I tried to open a JPEG that wouldn't fit in RAM, better it just says that's too big and I can pick a different file.

Whenever people are imagining they're going to recover despite OOM in low level components they are tripping. Their recovery strategy is going to blow up too, and then they're going to be in a huge mess - just abort when this happens.

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

#85

Post by iknowstuff »

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.

Long story short is that I trust their quality. The community is great about vetting unnecessary uses of unsafe code.

That’s more than can be said about hand rolled equivalents in C/C++.

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

#86

Post by atoav »

jdiez17 wrote: post #40
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…

From my experience in the embedded world, the ecosystem doesn't seem super relevant. You may depend on certain libraries for encryption, compression, etc. but you're more likely than not to be writing drivers for all of your devices more or less from scratch. Other than Arduino, which of course has pretty good support for many devices and is likely to work out of the box.

It probably depends on what you do with embedded, I can certainly imagine situations/jobs where you are correct, but I am not in that situation, unfortunately. I can't afford the time to write my own drivers unless I really need/want to.

I run an electronics workshop at an artschool, so the end result counts and how we get there is more or less arbitrary unless it happens in a finite timeframe. For my own private projects I tried Rust, but also there my goal is to get things done, not to fool around forever. I like fooling around with the interesting bits, not with rewriting a thing others have written before.

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

#87

Post by mips_r4300i »

the__alchemist wrote: post #38
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.

What do you mean by visually debug? If you install `probe-rs` and do `cargo run`, you can print whatever you want to console; not related to the IDE. (Not sure if this is what you're looking for, or something else)

Visual Studio-type ide debugging, viewing structs, run to cursor, etc.

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

#88

Post by mips_r4300i »

explodingwaffle wrote: post #30
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.

You mean, like this? https://probe.rs/docs/tools/debugger/

Thanks, that's more what I was looking for. Looks like it is still pretty early stuff but could be useful in the future.

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

#89

Post by SomeoneFromCA »

"Embedded" is a diverse concept. No need for Rust on ATtiny with all variables static and Harvard architecture. In fact, even C often is overkill, and Assembler is a better choice for a simple LED flasher or really tight high performance loop.

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

#90

Post by atoav »

xormapmap wrote: post #73
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.

Jup. This is my field of work. I am ot a full time embedded developer, I run an electronics workshop at an artschool. So a lot of arduino-ish things, and aometimes more sophisticated stuff. But I ain't got no time to write drivers.
Post reply on HN