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

Ask HN: Has any Rust developer moved to embedded device programming?

news.ycombinator.com

Post reply on HN
Print view View original

41–50 of 64 posts

Re: Ask HN: Has any Rust developer moved to embedded device programming?

#41

Post by thenewwazoo »

I had the pleasure of writing embedded Rust in the automotive space for a couple of years about 4 years ago, and it was an absolute game-changer even at that early stage. Being able to write generic drivers that I could easily test outside an embedded context sped development up an incredible amount. Writing the business logic wasn't necessarily any easier with Rust than C, but anything having to do with hardware (and especially concurrency) turned into a if-it-compiles-it's-correct affair.

At that time, I was pushing the cutting edge of what was possible alongside what's now the Embedded WG, but the job didn't work out. I am incredibly interested in finding another embedded Rust role, but have had nothing fall into my lap (my current FAANG handcuffs are quite golden). If you have the opportunity, you should absolutely take it.

C code is a liability, but sometimes liabilities are worth the risk if the payoff is good enough. If you want to move to Rust, you will need to show how the tradeoff changes in Rust's favor. Sometimes that's easy, sometimes that's hard. It depends entirely on your industry and product. For my part, I absolutely believe it is already a competitive differentiator.

Re: Ask HN: Has any Rust developer moved to embedded device programming?

#42

Post by b20000 »

reynoldsbd wrote: post #37

I'm fortunate enough to have just landed on a new team working with embedded Rust. Here are some of my takes, in no particular order. The language and ecosystem have come a long way in a very short time. It's easy to use safe `no_std` Rust on the stable toolchain for 98% of your code, and there are crates available for all kinds of things like memory management, register access, or even async runtimes. Compared with…

so what you are saying, is that rust solves the issue of finding competent engineers. you can use a language like rust such that engineers don’t need to be any good. it reminds me of microsoft frontpage and all the other scripting languages and tools that have been created to solve this issue. but here we are in 2022 and nothing has changed. people still hand code css and html to get what they want.

embedded software engineering is about understanding the hardware and leveraging its power through good architecture and smart thinking and understanding what the code you write will do. you can’t shortcut this by using a new programming language that does the work for you. you will still need to understand the low level details. so, learn C++ and familiarize yourself with the related embedded standards for reliability and safety.

adding rust into the mix will now require you to maintain code in not one but multiple languages as you cannot get around C or C++ and possibly assembly. it’s already complicated enough as it is, and you should focus on understanding the principles instead of learning another set of syntax and implicit logic.

Re: Ask HN: Has any Rust developer moved to embedded device programming?

#43

Post by crest »

b20000 wrote: post #42
reynoldsbd wrote: post #37

I'm fortunate enough to have just landed on a new team working with embedded Rust. Here are some of my takes, in no particular order. The language and ecosystem have come a long way in a very short time. It's easy to use safe `no_std` Rust on the stable toolchain for 98% of your code, and there are crates available for all kinds of things like memory management, register access, or even async runtimes. Compared with…

so what you are saying, is that rust solves the issue of finding competent engineers. you can use a language like rust such that engineers don’t need to be any good. it reminds me of microsoft frontpage and all the other scripting languages and tools that have been created to solve this issue. but here we are in 2022 and nothing has changed. people still hand code css and html to get what they want. embedded software…

I take something very different from the grand-parent post: the language requires you to get the design mostly correct to even compile. Unexperienced developers won't be able to come up any non-trivial new designs of their own, but can reuse existing code and even experienced developers have to fight the language to get a prototype stood up, but once they've working code it's more reliable. Not every line of code could accidentally reconfigure your PLL or voltage regulator just enough to drive you insane debugging a glitching chip.

Re: Ask HN: Has any Rust developer moved to embedded device programming?

#44

Post by crest »

zaarn wrote: post #38
jsmith45 wrote: post #30

Earlier quoted context omitted.

Ouch. Making you treat hardware registers as owned (or use unsafe to access them) feels like it would be unpleasant if writing single threaded firmware, where the only preemption is the interrupt handler. I’d much rather have them exposed as some form of atomic that is restricted to operations that are atomic on this specific hardware.

Being owned and unsafe feels like the most natural fit. If multiple threads (or the interrupt handler) manipulate a register while you're already working on it could leave you in a very undefined state you have no idea about. In this case, rust makes you promise that you checked that this will be entirely safe. You could also write wrappers, for example one that automatically turns off interrupt when you do a write o…

On ARM v7m the "correct" way to would be to raise the current thread's BASEPRI the the highest exception priority you have to lock up. The M0+ cores on the RP2040 only support v6m and require masking those interrupts, but since M0+ cores are limited to the 16 internal exceptions and at most 32 external interrupts the code sequence to temporarily mask those interrupts isn't much longer. The annoying downside is that it forces a tighter coupling on programmers. The RP2040 specifically may offer a cleaner solution if you can afford to dedicate one of the hardware locks available in the single-cycle I/O block to each conflict that requires resolution. Such a solution should even work for both ARM cores.

Re: Ask HN: Has any Rust developer moved to embedded device programming?

#45

Post by quake »

jsmith45 wrote: post #30
quake wrote: post #18

I've done some small embedded Rust applications on various STM32 and RP2040 boards. I've been doing embedded dev in C professionally for 7 years and Rust full-time for 2.5, mix or system and bare metal. It's very hard to unlatch your brain from some of the common C/C++ embedded principles of static context variables and thinking of the hardware registers as "owned" memory, which you have to do in Rust. The auto-gener…

Ouch. Making you treat hardware registers as owned (or use unsafe to access them) feels like it would be unpleasant if writing single threaded firmware, where the only preemption is the interrupt handler. I’d much rather have them exposed as some form of atomic that is restricted to operations that are atomic on this specific hardware.

Unsafe is exactly what they are in C. They're essentially volatile memory that can change at any time, and woe befall anyone messing around with the same register without synchronization when using an RTOS.

Good HAL crates don't have the entire register set as one struct, thank goodness. And for something like printing a message to serial in a panic handler, there are still unsafe options to yank control of registers, same as C.

What I really like about some of the HAL crates is the usage of builder patterns while configuring a peripheral. Setting up timer parameters before starting it by design is chef’s kiss wonderful.

But if you want to put the whole peripheral set in a static global, you can do that with a RefCell> or something similar. Or just yolo it and use unsafe blocks to ditch the mutex.

Re: Ask HN: Has any Rust developer moved to embedded device programming?

#46

Post by cogman10 »

reynoldsbd wrote: post #37

I'm fortunate enough to have just landed on a new team working with embedded Rust. Here are some of my takes, in no particular order. The language and ecosystem have come a long way in a very short time. It's easy to use safe `no_std` Rust on the stable toolchain for 98% of your code, and there are crates available for all kinds of things like memory management, register access, or even async runtimes. Compared with…

> One major drawback is lack of support/engagement from hardware vendors. They pretty much assume you are using C, and all of their IDEs/SDKs/codegen tools/whatever are written with that assumption. This probably isn't going to change any time soon (ever?).

My assumption is that with the advent of rust getting into gcc, you will see at least some of these changes starting to make their way into toolchains. Probably not for the MSP430, but possibly for the next generation of embedded chips.

Re: Ask HN: Has any Rust developer moved to embedded device programming?

#47

Post by junon »

kibwen wrote: post #34
junon wrote: post #19

Earlier quoted context omitted.

Right now struggling to separate out architecture-agnostic code and architecture-specific stuff in a way that can be switched out with `--target` and still undergo LTO as though it were all inlined. Cargo recently got multi-target builds which is great, and makes this way less of a headache before (usually had to run cargo once per target, now it can do all of them at once). The next challenge is packaging things up.…

> Cargo recently got multi-target builds which is great, and makes this way less of a headache Are you referring to Cargo's unstable "bindeps" feature? I ask because my company's the one that sponsored that work, and for the purposes of eventually stabilizing that feature we'd like to get feedback from users who are using it. :)

Nope. Multi-Target is where you can specify an array for build.target in .cargo/config, or multiple --target options on the command line. It just got moved out of unstable into stable about a month ago.

Re: Ask HN: Has any Rust developer moved to embedded device programming?

#48

Post by cogman10 »

b20000 wrote: post #42
reynoldsbd wrote: post #37

I'm fortunate enough to have just landed on a new team working with embedded Rust. Here are some of my takes, in no particular order. The language and ecosystem have come a long way in a very short time. It's easy to use safe `no_std` Rust on the stable toolchain for 98% of your code, and there are crates available for all kinds of things like memory management, register access, or even async runtimes. Compared with…

so what you are saying, is that rust solves the issue of finding competent engineers. you can use a language like rust such that engineers don’t need to be any good. it reminds me of microsoft frontpage and all the other scripting languages and tools that have been created to solve this issue. but here we are in 2022 and nothing has changed. people still hand code css and html to get what they want. embedded software…

I don't think that's what GP was saying at all.

The issue they bring up in more that hardware manufactures will have things like

    #define BLINKY_LIGHT_ADDR 0xDEADBEEF
in a standard set of headers distributed with their toolkit. That magic address is where you write to turn a light on or off.

Now, they will almost certainly also define that sort of thing in a datasheet, somewhere, but for the average embedded dev it's far simpler to pull in the SDK and use that.

This isn't some sort of "good programmer bad programmer" filter. This is a "I don't want to read a 40 page pdf of a datasheet to find out what you named light 1 and where that address is"

Re: Ask HN: Has any Rust developer moved to embedded device programming?

#49

Post by Thiez »

b20000 wrote: post #42
reynoldsbd wrote: post #37

I'm fortunate enough to have just landed on a new team working with embedded Rust. Here are some of my takes, in no particular order. The language and ecosystem have come a long way in a very short time. It's easy to use safe `no_std` Rust on the stable toolchain for 98% of your code, and there are crates available for all kinds of things like memory management, register access, or even async runtimes. Compared with…

so what you are saying, is that rust solves the issue of finding competent engineers. you can use a language like rust such that engineers don’t need to be any good. it reminds me of microsoft frontpage and all the other scripting languages and tools that have been created to solve this issue. but here we are in 2022 and nothing has changed. people still hand code css and html to get what they want. embedded software…

Nice gatekeeping. Perhaps you could provide some concrete examples of how Rust is worse than C++ for embedded programming, when it comes to "understanding the hardware and leveraging its power through good architecture and smart thinking and understanding what the code you write will do"?

To me it is very strange that you would act as if Rust is some dumbed down toy language (not your literal words, but I conclude this from your MS frontpage example), while it is considered (not entirely deserved, in my opinion) difficult to learn with a very steep learning curve.

Personally I find programming in C quite annoying because of all the sharp edges (e.g. implicit integer promotion, the various types of UB) that you have to keep in mind. To me this distracts from thinking about good architecture, rather than promoting it.

Re: Ask HN: Has any Rust developer moved to embedded device programming?

#50

Post by adolph »

b20000 wrote: post #42
reynoldsbd wrote: post #37

I'm fortunate enough to have just landed on a new team working with embedded Rust. Here are some of my takes, in no particular order. The language and ecosystem have come a long way in a very short time. It's easy to use safe `no_std` Rust on the stable toolchain for 98% of your code, and there are crates available for all kinds of things like memory management, register access, or even async runtimes. Compared with…

so what you are saying, is that rust solves the issue of finding competent engineers. you can use a language like rust such that engineers don’t need to be any good. it reminds me of microsoft frontpage and all the other scripting languages and tools that have been created to solve this issue. but here we are in 2022 and nothing has changed. people still hand code css and html to get what they want. embedded software…

> so what you are saying, is that rust solves the issue of finding competent engineers.

It’ll be a depressing time when the demand for engineering is lower than supply. Until then people with needs larger than resources will find alternatives to “finding competent engineers.”

That said, Espressif seems to be moving past pure embedded and positioning themselves in IoT, for example the latter part of ESP-IDF stands for IoT Dev Framework. This allows them to provide a single way of doing things regardless of implementation within the broad ESP32 family.

Will the results be the equivalent of Frontpage websites? Sure, and as any of those start getting the resources to need and use “competent engineers” they will unlike the efforts that would never have gotten off the ground.

Post reply on HN