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

101–110 of 172 posts

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

#101

Post by megous »

fjfaase wrote: post #75

Really strange the the C JSON parser has to use malloc where the RUST version does not. As if it is not possible to write a JSON parser in C that does use malloc. I presume that the syntax of the commands that the device will accept is known, and than there is no reason why you have to build a DOM of the JSON before you can process it. Apparently, the RUST version can do it. I really begin to question the abilities o…

Yeah, you can comfortably work with JSON in C directly on top of the string buffer containing it. Your representation for any JSON entity will just be const char pointer. It's possible to implement JSON path on top of this, and all kinds of niceties, and it's not slow.

Megatools is an example of such a code https://xff.cz/megatools/ / https://xff.cz/git/megatools/tree/lib/sjson.c

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

#102

Post by JoshTriplett »

irishcoffee wrote: post #72
IshKebab wrote: post #31

Earlier quoted context omitted.

Rust is much more stable than C in my experience. Try compiling a decade old C code and see how that goes...

How do you figure? I do that weekly.

I've often found that trying to compile decade-old C code with a current toolchain and current libraries will have issues. It isn't always clear what versions the code is expecting (no equivalent to a lockfile), newer C compilers or standards can break old code, and newer libraries especially can break old code. It might still build if you could recreate exactly what it expects, but it becomes decreasingly possible to do that if you weren't compiling it a decade ago and archived off exactly what worked then.

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

#103

Post by MarsIronPI »

throw848tjfj wrote: post #69
eggy wrote: post #54

We passed on Rust for Ada/SPARK2014 to write to bare metal on Cortex-M processor for real-time, high-integrity, and verifiable mission-critical software. Rust is making strides to be a future competitor, but it's new to the formal verification tooling and lacks any real world legacy in our domain. Ada's latest spec. is 2022. Other than AdaCore's verified Rust compiler, Rust still does not have a stable language speci…

Rust is not really memory safe if you combine it with external libraries. Too many "unsafe" keywords, and lack of tooling for code analysis and verification. Edit: With c, you can do memory safety analysis on all system libraries and entire Linux kernel. Some OS kernels, libs and languages do not have dynamic memory allocation at all! Some languages are memory safe! Learn more about embedded programming!

To me Rust is just a nicer language than C. I don't care too much about how easy the language makes memory safety, provided it doesn't make it difficult. But Rust's type system, higher-order functions, polymorphism, macros, etc. make it more pleasant to write than C for complicated programs.

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

#104

Post by adrianN »

LtWorf wrote: post #67
Aurornis wrote: post #32

Earlier quoted context omitted.

> Rust is evolving far too fast to be used in code which needs to run for years to decades down the line. Code doesn’t stop running on existing hardware when the language changes in a future compiler. You can still use the same old toolchain. I’ve done a lot of embedded development in a past life. Keeping old tool chains around for each old platform was standard. I would much rather go through the easy process of swi…

> You can still use the same old toolchain. Unless you find out the compiler was buggy and was producing faulty binaries, but the new compiler can no longer compile the old code.

Coding around compiler bugs is pretty standard practice in usecases where you have some random vendor compiler that is based on some ancient gcc if you’re lucky or completely in-house if you’re not.

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

#105

Post by ThrowawayR2 »

nine_k wrote: post #66
fluidcruft wrote: post #44

Earlier quoted context omitted.

I think people don't like the JavaScript treadmill. People want to think about using tools and getting proficient with them rather than relearning tools. I'm not saying rust is like that, but I do feel that way about python and JavaScript. Those are dynamic languages but it is what all this editions stuff evokes. It's an if it were stable, it wouldn't be changing sort of thing.

> using tools and getting proficient with them rather than relearning tools This attitude works in carpentry, but not in software. You need to get proficient, but your tools will keep evolving, like everything else in the software world.

That's a webdev mindset. Tools in embedded systems and systems programming are very mature and evolve much more slowly.

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

#106

Post by adrianN »

dlahoda wrote: post #45
vmg12 wrote: post #40

Earlier quoted context omitted.

> Rust is evolving far too fast I'm curious why I've seen this sentiment repeated in so many places, I learned Rust once 5 years ago and I haven't had to learn any new idioms and there have been no backwards incompatible changes to it that required migrating any of my code.

- https://github.com/contextgeneric/cgp - a lot of code now uses mix of witness types and const generics - with new borrow checker release they will do new iterators 2.0 Seems like coding on 5 year old Rust is like C++ 98.

C++98 (and older) is still widely used in embedded systems.

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

#107

Post by kaspar030 »

fjfaase wrote: post #75

Really strange the the C JSON parser has to use malloc where the RUST version does not. As if it is not possible to write a JSON parser in C that does use malloc. I presume that the syntax of the commands that the device will accept is known, and than there is no reason why you have to build a DOM of the JSON before you can process it. Apparently, the RUST version can do it. I really begin to question the abilities o…

Part of the C protocol implementation is generated, and that generator chose the JSON parser. As it worked and there was plenty of memory left on the MCU, it was kept.

We're mentioning this in the paper: "The heap is entirely attributable to Parson's dynamic allocation of JSON tree nodes; as memory usage minimization was not a key goal, we kept Parson (the JSON parser used by the PNPL code generator by default), noting that there are less memory heavy options that do not require a heap at all."

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

#108

Post by pitched »

jacquesm wrote: post #26
pitched wrote: post #18

Earlier quoted context omitted.

I think there’s another hidden issue of testing how new devs use the language vs. those seasoned devs. I expect someone with a few months of experience would prefer Rust (fewer footguns) but someone with more experience would prefer C (the sharper knife). The flavour of the thing changes as we age.

The problem with C - and I'm saying this as a life-long C programmer and not exactly a fan of Rust - is that C is indeed very sharp but it will cut other people just as easily even though they are far downstream of the original programmer, as well as the users of those programs. And it is extremely hard to not accidentally fall for one of the many pitfalls of C. I've got my own set of restrictions for when I'm coding…

Fil-C says it doing runtime checks which is fantastic for debug builds (like valgrind) but I worry a bit about performance with that for release builds. Valgrind can be pretty rough!

My personal view is that good C code looks a lot like Rust where ownership is clear and a borrow checker would approve. The mindset that Rust forces you into is the same one you should be using when writing C.

The longer-term concern is that, if you’re spending late nights learning Rust, it’s probably with the borrow checker. Late nights with C, it’s probably with memory management. One of those two is a bit more applicable to understanding computing at a deeper level.

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

#109

Post by [deleted] »

Aurornis wrote: post #32
noosphr wrote: post #16

Earlier quoted context omitted.

[flagged]

> Rust is evolving far too fast to be used in code which needs to run for years to decades down the line. Code doesn’t stop running on existing hardware when the language changes in a future compiler. You can still use the same old toolchain. I’ve done a lot of embedded development in a past life. Keeping old tool chains around for each old platform was standard. I would much rather go through the easy process of swi…

[deleted]

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

#110

Post by Lvl999Noob »

noosphr wrote: post #16
dgacmu wrote: post #2

Authors are from STMicro, polytechnic Turin, Freie universitat Berlin, and Inria. Examined writing firmware for an IOT sensor platform. From the abstract: > Two teams concurrently developing the same functionality (one in C, one in Rust) are analyzed over a period of several months. A comparative analysis of their approaches, results, and iterative efforts is provided. The analysis and measurements on hardware indica…

[flagged]

Aren't there companies that still use C89 for their production systems? I don't know any in particular but I have read comments here on HN implying that. Just do the same for Rust. Stick to the one major version you started with instead of trying to update the toolchain regularly.
Post reply on HN