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

Should you Rust in embedded yet?

kazlauskas.me

Post reply on HN
Print view View original

71–80 of 119 posts

Re: Should you Rust in embedded yet?

#71

Post by throwaway84742 »

unwind wrote: post #68
throwaway84742 wrote: post #58

Earlier quoted context omitted.

Null pointer is actually perfectly fine on bare metal. There’s no memory protection, so it just points to address 0x0, and if you deref it nothing bad will happen.

This is not true at all. First, of course, there is no requirement for NULL to map to address zero. Second even if you do en uo there, many architectures don't even have memory at 0x0. Spurious writes are spurious writes regardless of whether or not you get a fault. You are still not doing what you want to be doing.

Ones I worked with did nothing on when reading from 0x0. I mentioned this because for someone who spends all their time well above bare metal this is not intuitive at all. And null is de-facto 0 on all C compilers, even though it’s not required to be. So let’s not engage in hyperbole here.

Re: Should you Rust in embedded yet?

#72

Post by ratmice »

unwind wrote: post #68
throwaway84742 wrote: post #58

Earlier quoted context omitted.

Null pointer is actually perfectly fine on bare metal. There’s no memory protection, so it just points to address 0x0, and if you deref it nothing bad will happen.

This is not true at all. First, of course, there is no requirement for NULL to map to address zero. Second even if you do en uo there, many architectures don't even have memory at 0x0. Spurious writes are spurious writes regardless of whether or not you get a fault. You are still not doing what you want to be doing.

even worse, there might be something there like the exception vector table, in which case spurious writes become an attack vector.

https://cansecwest.com/slides07/Vector-Rewrite-Attack.pdf

Re: Should you Rust in embedded yet?

#73

Post by rvense »

throwaway84742 wrote: post #58
pcwalton wrote: post #44

Earlier quoted context omitted.

Just that Rust is known for its borrow checker doesn't mean that the borrow checker is the only type of safety that Rust offers. The old standbys are still valuable: bounds checks, null pointers, compile-time data race detection. > Pragmatism reigns: time-to-market and a cheap BoM are the main metrics, programming language a distant 10th. I find that I can develop software faster with Rust than with C, simply because…

Null pointer is actually perfectly fine on bare metal. There’s no memory protection, so it just points to address 0x0, and if you deref it nothing bad will happen.

But it is never what you want. So even if there are no immediate explosions, your LED's not going to blink the way you expected it. I'd say a clear, stern sign that something was wrong is better than limping along after dereferencing null.

Re: Should you Rust in embedded yet?

#74

Post by jononor »

_sh wrote: post #9

Embedded developer here, ARM Cortex-M4 microcontrollers. I've been keeping an eye on Rust for the embedded space and although there has been a lot of movement in that area--particularly in the last couple of months--I'm not sure the value proposition fits the microcontroller market, where of course C is king. While Rust has much to offer as a programming paradigm in general, the main value is in the borrow-checker (t…

The type system is orders of magnitude better than C, which can be used to reduce bugs.

Re: Should you Rust in embedded yet?

#75

Post by sureaboutthis »

I hate, hate, HATE papers or talks or anything of this nature that begin by justifying the obvious to the knowledgeable! In this case, "Why does embedded matter?" Sheesh.

Then there is that law of titles with a question where the answer is always, "no".

>Yes. As long as it supports your hardware and you are willing to put up with a less stable toolchain and less nature ecosystem in exchange for the safety guarantees.

Re: Should you Rust in embedded yet?

#76

Post by jononor »

_sh wrote: post #9

Embedded developer here, ARM Cortex-M4 microcontrollers. I've been keeping an eye on Rust for the embedded space and although there has been a lot of movement in that area--particularly in the last couple of months--I'm not sure the value proposition fits the microcontroller market, where of course C is king. While Rust has much to offer as a programming paradigm in general, the main value is in the borrow-checker (t…

The borrow checker should be quite useful when using tasks and shared resources in an RTOS. Just closures alone is a benefit.

Re: Should you Rust in embedded yet?

#77

Post by emilfihlman »

_sh wrote: post #9

Embedded developer here, ARM Cortex-M4 microcontrollers. I've been keeping an eye on Rust for the embedded space and although there has been a lot of movement in that area--particularly in the last couple of months--I'm not sure the value proposition fits the microcontroller market, where of course C is king. While Rust has much to offer as a programming paradigm in general, the main value is in the borrow-checker (t…

>As wiremine points out, it will require vendor support--moving away from your vendor's toolchain is a world of hurt that seasoned embedded developers just won't even consider.

I wont consider a chip/microcontroller if it doesn't support open source command line tools.

Vendor support is technological debt that hinders every bit of testing and automation.

Re: Should you Rust in embedded yet?

#78

Post by emilfihlman »

wiremine wrote: post #2

Having Rust support embedded is only half the story: we need to lobby/advocate for chip makers to support Rust. The article doesn't directly call this out, but I think it's important for Rust to truly succeed in this space. Most embedded systems are fairly closed ecosystems built on vendor-specific stacks, and most professional embedded engineers wouldn't want to use Rust until the vendors support it. This isn't to s…

"Vendor support" for programming tools is cancerous and hurts development. We need to actively push away from such idiocy.

Re: Should you Rust in embedded yet?

#80

Post by pjc50 »

pknopf wrote: post #11
_sh wrote: post #9

Embedded developer here, ARM Cortex-M4 microcontrollers. I've been keeping an eye on Rust for the embedded space and although there has been a lot of movement in that area--particularly in the last couple of months--I'm not sure the value proposition fits the microcontroller market, where of course C is king. While Rust has much to offer as a programming paradigm in general, the main value is in the borrow-checker (t…

Why is C king? Why not C++? The difference is just a compiler, and you can use C in C++.

About 15 years ago I did some PIC16 programming immediately after a lot of C++, so I tried working in a C++ style.

The first obstacle was that there was no C++ compiler.

So I wrote some very C++ style C: nice little structs with associated functions for mainpulating them, which took a pointer to struct as first argument.

The code did not fit in the PIC.

It turns out that the PIC16 lacks certain indirect addressing modes, so every access to a structure member from a pointer turns into a long sequence of instructions to do the arithmetic.

Oh, and this particular chip only allows you a maximum stack depth of 8, so you have to ration your use of utility functions. The compiler is bad at inlining so macros are prefereable.

By the time I had finished it was an extremely C program with no trace of C++ style at all.

The situation has got a lot better but there are still limitations which will trip up the unwary. And one day someone's going to point out that they can save $0.50 on every one of a million devices if you use one of these tiny chips with no indirect addressing and limited stack.

Post reply on HN