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

151–160 of 172 posts

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

#151

Post by pjmlp »

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]

K&R C, C89, C90, C11, C17, C23, C2y.

Not counting compiler specific extensions from GCC, clang, Microsoft, Intel, NVidia, AMD, IBM, Oracle, Apple, Green Hills, TI, Microbit, Mikroe, and many more C compiler vendors that could have been used to compile a specific project during the last 50 years.

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

#152

Post by 3836293648 »

tialaramex wrote: post #147
3836293648 wrote: post #145

Earlier quoted context omitted.

Oh, wow. I am wrong. So much of the rust community must be wrong as this is commonly mentioned when discussing breakage. This is awful. But on the other hand, it could be a bug as the trait resolver is commonly mentioned as the buggiest part of the language. I'm scared of the breakage if they fix it though.

Probably a key thing you misunderstood is that &str wasn't from the prelude. It's a type in the actual Rust language, that's why it has the lowercase name like u16 or bool So we didn't bring str::strip_prefix from the prelude in preference to our custom trait, we made a string literal and those have type &'static str -- an immutable reference to a string which lives forever. So the "prelude doesn't win" rule does not…

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.

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

#153

Post by fluffybucktsnek »

staticassertion wrote: post #141
fluffybucktsnek wrote: post #122

Earlier quoted context omitted.

Why, given the existence of editions?

It's a very strong, plainly stated assertion that contradicts stated goals of the project so it seems like it deserves supporting evidence. Editions exist to avoid breaking code over time.

Ah, sorry. I got confused about your comment.

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

#154

Post by fluffybucktsnek »

whytevuhuni wrote: post #138
fluffybucktsnek wrote: post #122

Earlier quoted context omitted.

Why, given the existence of editions?

Very surprised to hear that, since editions are exactly the kind of mechanism Rust is using to make sure software will keep working unchanged for decades. The Rust compiler can build a 2024 edition application which depends on a 2015 edition library, which in turn depends on a 2018 edition library. Every crate can upgrade at their own pace, or even never at all.

Oh, I'm aware about the benefits of editions. For some reason, I've misread OP's comment.

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

#155

Post by imtringued »

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.

The project you've linked warns you that it is in its very early stage and that you should only use it as an early adopter.

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

#156

Post by SkiFire13 »

3836293648 wrote: post #133
tialaramex wrote: post #71

Earlier quoted context omitted.

To be very fair there are legitimate gripes here, they're small but they are worth covering, and then there's a huge nonsense L1: The edition system allows Rust to literally mutate the language. 2024 edition (if you begin a new Rust project today) has different rules from 2021 Edition, from 2018 edition and the Rust 1.0 "2015 edition". These changes aren't exactly huge, but they are real and at corporate scale you wo…

Strip_suffix won't break with new compiler versions. Anything explicitly imported takes precedence over the prelude, or else everything is a breaking change and would have to wait for an edition.

`strip_suffix` will indeed break with new compiler versions because inherent methods always have priority over trait methods.

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

#157

Post by SkiFire13 »

3836293648 wrote: post #152
tialaramex wrote: post #147

Earlier quoted context omitted.

Probably a key thing you misunderstood is that &str wasn't from the prelude. It's a type in the actual Rust language, that's why it has the lowercase name like u16 or bool So we didn't bring str::strip_prefix from the prelude in preference to our custom trait, we made a string literal and those have type &'static str -- an immutable reference to a string which lives forever. So the "prelude doesn't win" rule does not…

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

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

#158

Post by torginus »

blub wrote: post #146
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…

One of the authors commented below that the “teams” were actually persons and the Rust person was an intern. This is even less serious than the typical pattern of grabbing random students for experiments and then drawing conclusions about the general population.

Not sure about your life experiences, but every new, from-scratch project I have undertaken has looked like 1-2 or at most 3-4 people on good terms who really pulled their weight, with the rest being basically not dead weight, but the management overhead they caused ate up most of the productivity they brought to the table.

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

#159

Post by torginus »

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…

I've read (from one from one of the people that contribute to Rust afair), that they were involved building formal verification for Rust, and found that the control flow is just so complex that its very hard to use the language like this.

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

#160

Post by torginus »

Hhaving worked on quite complex embedded projects, my 2 cents is that dynamic allocation should be avoided as much as possible (and its been possible to avoid it 100% of the time for me).

Memory layouts are often pre planned, with hand-written linker files, which are sometimes even necessary, as there are quirks like DMA only being able to access certain addresses etc.

In embedded, engineers often want hard real time guarantees, very high (essentially unfailing) reliablity, at the lowest possible price points.

Dynamic memory allocation is often no good - embedded allocators either waste RAM, have large code sizes, have worse runtimes than their desktop-grade cousins - something like jemalloc generates 10x as much code as the rest of your app, and assumes your heap is at least megabytes in size.

On the other hand, embedded-grade allocators often use algorithms that are prone to fragmentation, unpredictable runtimes, and tend to be less tested in general, while still wasting RAM and Flash.

Having an allocator that has a bad runtime behavior can basically ruin your hard runtime guarantees, and if you prealloc all you memory you will never run out - on the other hand, even the paper states they measured not calculated the max memory usage, meaning we have no knowledge of what the actual max is.

Post reply on HN