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

Embedded Rust or C firmware? Lessons from an industrial microcontroller use case

arxiv.org

Post reply on HN
Print view View original

161–170 of 172 posts

Re: Embedded Rust or C firmware? Lessons from an industrial microcontroller use case

#161

Post by torginus »

edderly wrote: post #119
torginus wrote: post #41

Earlier quoted context omitted.

Why? In IoT stuff, its very useful if you can talk to your devices via standard internet protocols, otherwise you have to introduce some pointless 'gateway' node for that. I mean sometimes efficiency matters a lot, but a lot of other times, interoperability is more important. Text based IO with microcontrollers over tty has been quite a standard thing even decades ago.

Interoperability would mean you have a meaningful protocol encoded within JSON. JSON itself offers little value.

From the paper:

> The command-response protocol and binary data format are described in device models generated using DTDLv2 [10], a JSON-based language for describing digital twins. These models are used within the Azure IoT Plug and Play (PnP) framework [11], which STAIoTCraft adopts for datalogging

Re: Embedded Rust or C firmware? Lessons from an industrial microcontroller use case

#162

Post by 3836293648 »

SkiFire13 wrote: post #157
3836293648 wrote: post #152

Earlier quoted context omitted.

Oh, yes of course. Switching to String and it works as I expected. I thought the builtins were defined in core and reexported by the prelude (they are defined in core, they're just implicitly in scope anyway). But I still think expected behaviour is that builtins should have the same precedence as the prelude.

The reason it works with `String` is because trait methods get priority over applying autoderef (which is needed to go from `&String` to `&str` and select `str::strip_suffix`). If you however already have a `&str` then autoderef won't be needed and the inherent method will win over the trait method. At no point does the prelude come into play

Not technically. But that's not the issue. The issue is that trait resolution and imports are treated inconsistently and that is a mistake.

Compare to [this](https://play.rust-lang.org/?version=stable&mode=debug&editio...)

Re: Embedded Rust or C firmware? Lessons from an industrial microcontroller use case

#163

Post by orochimaaru »

megous wrote: post #96
orochimaaru wrote: post #78

Earlier quoted context omitted.

You have the same issue with C, no? C is upgrading versions, compilers have changed, hardware evolves and somethings in the past aren't supported as well anymore.

Not really. Not in the scale of my C dev life, which has been 20 years so far.

I did C and C++ till about 2010 or so. The major platform which I did dev for (hp ux) is no longer supported.

Re: Embedded Rust or C firmware? Lessons from an industrial microcontroller use case

#164

Post by IshKebab »

sshine wrote: post #149
IshKebab wrote: post #129

Earlier quoted context omitted.

> I know I’d rather be trying get a load of c99 rebuilt for some mips or other after 20 years that some random version of rust. Rust 1.0 is 11 years old and it's still trivial to compile Rust code from then. I doubt that will change in the next 9 years. C is an absolute nightmare in comparison. I tried to compile some old C code I had for Nordic nRF51 chips, only a few years after the chips became available. I gave u…

I tried to compile and run some C code from 1991 using a modern C compiler: https://github.com/sshine/dikumud/commits/master/ It wasn't plug-and-play. My guess is that when Rust code gets 30 years old, the problem would more likely be that you can't find an already compiled compiler that will work for that old code, and that the compilers themselves need bootstrapping. So you'll just fast-forward the code to work on…

> you can't find an already compiled compiler that will work for that old code

If it's pure Rust code then the latest Rust compiler will almost certainly work.

The issue will be if some of the crates wrap C code... but that kind of proves the point.

Re: Embedded Rust or C firmware? Lessons from an industrial microcontroller use case

#165

Post by i_don_t_know »

IshKebab wrote: post #129
cyberpunk wrote: post #87

Earlier quoted context omitted.

I know a defence company that has a bunch of vaxes stored in low oxygen environments because they legally have to be able to provide software updates to firmware they’ve written for the next 20 or so years and it was written on a vax. They had some great stories trying to get something or other running again where they had to fly one of the original designers over to hand solder a board back into action. How we do th…

> I know I’d rather be trying get a load of c99 rebuilt for some mips or other after 20 years that some random version of rust. Rust 1.0 is 11 years old and it's still trivial to compile Rust code from then. I doubt that will change in the next 9 years. C is an absolute nightmare in comparison. I tried to compile some old C code I had for Nordic nRF51 chips, only a few years after the chips became available. I gave u…

> Rust 1.0 is 11 years old and it's still trivial to compile Rust code from then. I doubt that will change in the next 9 years.

Maybe it's trivial to compile Rust code but it's not trivial to build a project with dependencies. I'm trying to get my feet wet with an official USB example project from Embassy on my RP2040. It doesn't work in the latest git repo for some unknown reason (might be my fault, probably is, but it's not obvious to me).

I'm assuming it worked at some point, maybe something changed and someone forgot to update something somewhere (there are lots of example projects). So I thought I'd "git bisect" until I find a working version and go from there. Well, I cannot get it to build against anything older than a year ago and that version also isn't working for me. It's dependency and Rust edition hell.

Re: Embedded Rust or C firmware? Lessons from an industrial microcontroller use case

#166

Post by acstapleton »

the__alchemist wrote: post #118
acstapleton wrote: post #116

Earlier quoted context omitted.

As a professional in the space, this echoes my experiences. I’m far more productive in Rust than C, despite having many more years programming embedded software in C. Cargo and the crate ecosystem are a dream compared to the lack of any easy-to-use build tooling and the difficulty of integrating third party libraries in C. Furthermore, the code I’ve produced in Rust is generally as fast (or faster) than the code I’ve…

Very cool! Which one? I have been using mostly G4 and H7 on my personal and work projects, but the HAL (`stm32-hal2` is the crate name) works for most of the one s in a certain time band; i.e. not any that were obsolte when I started it, and spotty or no support on some of the newer ones like U series and H5. And weaker / non-vetted support on MCU variants I haven't used, or haven't used a MCU/feature combo on. I thi…

I’ve been developing https://github.com/stm32-rs/stm32h5xx-hal. It’s been a slow process adding functionality because I’ve focused on what we need from it, so it’s missing a lot of functionality. Making progress bit by bit though.

Re: Embedded Rust or C firmware? Lessons from an industrial microcontroller use case

#167

Post by QuiEgo »

cozzyd wrote: post #136

Do linker scripts look the same in the rust tool chain? (E.g. for implementing a bootloader?)

Yes. It uses the same linker as a C/llvm toolchain, by the time you link the object files from Rust are in the same format as the object files from C would be. You use the exact same linker script format too.

Re: Embedded Rust or C firmware? Lessons from an industrial microcontroller use case

#168

Post by TheMagicHorsey »

My biggest gripe with Rust, which certainly reflects my own shortcomings, is that when I go back and revisit simple Rust programs I wrote more than a year ago, it takes me a long time to understand what I was even doing in a particular part of the program. This is my weakness ... I'm not great with Rust and I don't use it enough to get better. But it is what it is.

In contrast, when I go back and read Go or C code I wrote years ago, I have no trouble at all quickly figuring out what I was doing in the small programs I write.

The way these issues manifest themselves, as it recently did, was I went back to add a simple addition to a CLI tool I wrote for myself a year ago, and I was having trouble doing it because I couldn't quickly understand what I had been doing a year ago ... so I just had an AI agent do it for me. This was the kind of change that if it was a Go program, I would've done manually myself in about 5 or 10 mins.

Re: Embedded Rust or C firmware? Lessons from an industrial microcontroller use case

#169

Post by the__alchemist »

acstapleton wrote: post #166
the__alchemist wrote: post #118

Earlier quoted context omitted.

Very cool! Which one? I have been using mostly G4 and H7 on my personal and work projects, but the HAL (`stm32-hal2` is the crate name) works for most of the one s in a certain time band; i.e. not any that were obsolte when I started it, and spotty or no support on some of the newer ones like U series and H5. And weaker / non-vetted support on MCU variants I haven't used, or haven't used a MCU/feature combo on. I thi…

I’ve been developing https://github.com/stm32-rs/stm32h5xx-hal . It’s been a slow process adding functionality because I’ve focused on what we need from it, so it’s missing a lot of functionality. Making progress bit by bit though.

V cool! I think I got the RCC and basics working on that but I think my impl is missing and or broken for many periphs. Similar to H7 in a lot of ways though!

Re: Embedded Rust or C firmware? Lessons from an industrial microcontroller use case

#170

Post by mariuolo »

cyberpunk wrote: post #87
whiatp wrote: post #47

Earlier quoted context omitted.

I remember a coworker having to fight with an old platform's build not working because our user/group IDs were bigger than 2^16. I can't remember which utility was causing the problem, I'd have to guess tar. This is when we learned to play the archive a VM game.

I know a defence company that has a bunch of vaxes stored in low oxygen environments because they legally have to be able to provide software updates to firmware they’ve written for the next 20 or so years and it was written on a vax. They had some great stories trying to get something or other running again where they had to fly one of the original designers over to hand solder a board back into action. How we do th…

Isn't Charon VAX officially supported by HP/Compaq/DEC these days?
Post reply on HN