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

51–60 of 64 posts

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

#51

Post by reynoldsbd »

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…

> rust solves the issue of finding competent engineers

That's a very cynical take, but I think there's a kernel of truth in there somewhere. Rust does indeed make it much harder for less experienced programmers to make certain classes of mistakes. Why on earth would that be a bad thing?

> you can't shortcut this by...

"Using Rust" and "understanding the hardware"/"good architecture" are not mutually exclusive, and Rust is not a shortcut. Embedded programming is still very hard. In some ways, Rust can make it even more difficult by forcing your code and architecture to follow additional rules.

> cannot get around C or C++

Speaking from experience, this is false. It's perfectly possible to write embedded applications using only Rust and assembly, without a single line of C/C++. I do it every day.

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

#53

Post by LaffertyDev »

I'm a rough beginner in the embedded space. Would love to use Rust, but in my experience it becomes more hassle than its worth for some of the more off-the-shelf controllers. Would love to find more knowledge / tutorials to help guide me in the right direction, though.

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

#55

Post by bsder »

cogman10 wrote: post #48
b20000 wrote: post #42

Earlier quoted context omitted.

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…

It's worse than that.

Something like your Bluetooth communication is dependent upon a C-based "communications stack" that demands to control the event loop and all the registers aren't even documented.

"Where is the LED?" is easy to work around. "How do I put my BLE system into low power advertising mode?" may not even be possible without accessing the C library.

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

#56

Post by cogman10 »

bsder wrote: post #55
cogman10 wrote: post #48

Earlier quoted context omitted.

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…

It's worse than that. Something like your Bluetooth communication is dependent upon a C-based "communications stack" that demands to control the event loop and all the registers aren't even documented . "Where is the LED?" is easy to work around. "How do I put my BLE system into low power advertising mode?" may not even be possible without accessing the C library.

Ah, good point. That would be rather tricky to solve.

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

#57

Post by felipellrocha »

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…

Lol. Talk about straw man argument.

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

#58

Post by mgsouth »

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.

Atomic ops only address a small part of the problem.* Sure, your internal queue pointers will be sane, and two-stage register settings won't be interrupted. But locks are very fine-grained, and aren't going to help you keep co-ordinated in-the-large. In fact, you could argue that each mutex is a warning about muddled coordination. "Who's going to be changing this queue?" "Everybody!" "Better put a lock around it."

Yes, it's all trade-offs. You aren't going to avoid all shared responsibility, and will always need micro-coordination. But safe Rust forces you to assign ownership to every structure, at every scale. Some similar effects to opaque data structures, or actors. But unlike those techniques, it allows you to dynamically transfer responsibility.

The most obvious issue is use-after-"free", use-before-"allocate". "Free" and "allocate" don't just refer to malloc--it's any situation where you pinky-swear you aren't going to be touching something.

But more problematic is this kind of code is easy, even natural, to write in C:

- Task A is waiting for a state changes on resources Q1 and Q2. When it sees a particular set, it will modify resource Q3's state.

- Task B is firing off events to Q1 and handling error responses. It might need to stop Q1.

- Since Q1 is no longer changing state, what happens to Q3? Who's responsible for keeping stuff straight? What's "stuff"? Do we need to worry about Q2?

Rust is going to very strongly push you to explicitly designate what owns and is responsible for Q1, Q2, Q3, at all times. "B's got Q1, so A can't even look at it. I'm @#!* going to have to make A tell B what it wants and let B handle it." That was painful, but a good thing.

* Note to self: Write a blog post titled "Atomics won't save you now!" Start a band named "Useless Atomics".

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

#59

Post by steveklabnik »

bsder wrote: post #55
cogman10 wrote: post #48

Earlier quoted context omitted.

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…

It's worse than that. Something like your Bluetooth communication is dependent upon a C-based "communications stack" that demands to control the event loop and all the registers aren't even documented . "Where is the LED?" is easy to work around. "How do I put my BLE system into low power advertising mode?" may not even be possible without accessing the C library.

That’s a fun example, because while you’re right, that may also be changing. Android’s new Bluetooth stack is in Rust, in my understanding. We’ll see if more vendors provide even more stuff in Rust in the future!

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

#60

Post by zen_1 »

ctrlmeta wrote: post #28
larve wrote: post #23

Earlier quoted context omitted.

I mostly allocate static areas in the BSS segment. That way, I know at compile time that I allocated my memory correctly, assuming that I have my stack under control. Then I follow my two rules of embedded development: - no recursion - everything has to be O(1) If I'm honest, I can't remember a project where I had to use even a pool allocator, which you would usually need if you were trying to do like, reorderable qu…

> I mostly allocate static areas in the BSS segment. How is this done from C code? Any code examples someone can point me to?

BSS is the section of your program's address space where all the un/zero-initialized memory lives, so just a global std::array foo{}; would be placed in BSS by the compiler. BSS is also usually not included in the actual executable size (as it's marked as NOLOAD in the linkerscript), and needs to be zero-initialized by the C runtime if you want to guarantee that .

https://en.wikipedia.org/wiki/.bss

Post reply on HN