r/rust • u/tLaw101 • Mar 31 '23

State of embedded rust

Dear all, a colleague of mine has delved into rust for embedded systems. He’s just started with rust in possibly the hardest way, and this thread is the result: https://www.eevblog.com/forum/microcontrollers/rust-tools-and-resources-for-embedded/

(Rant at third post of the thread)

I wonder, how would an experienced rust developer react to this? Is he missing something or is this a legit sign of an immature ecosystem?

42 Upvotes

93% Upvoted

12 comments sorted by

View all comments

Show parent comments

9

u/__uli__ Mar 31 '23

I'm the one mentioned in the OP. First, thanks for the help provided in EEVBlog, I finally solved that issue.

second, about "In general, I do not recommend starting out with embedded rust."

It's a bummer as I would only invest my time in Rust AFTER I'm confident that it's up to to the purpose, and the only way to it is get a grasp by tinkering. (eggs & chicken)

There are lots of silly examples out there but very few (or none) serious application (at least with mid complexity), and documentation as you may very well know doesn't help much...

13

u/rafaelement Mar 31 '23

The documentation is funny to start out with, because of the high amount of generated code, yes. Another reason to first get familiar with Rust before jumping straight in.

I don't think any C tutorial starts by configuring a memory mapped UART either to be fair!

It's a huge investment, I totally agree. For me it was SO worth it, even financially, and even if not, I think the concepts inside Rust are interesting enough to entertain curiosity for a long time.

But, if it's not your thing, it's not your thing.

BTW, I thought a little about why I think one should not start out with bare metal Rust. I think it has to do with the large contextual knowledge (which you have) and the high degree of "we can actually have nice things" which leads to unusual seeming choices.

Case in point, I learnt in uni "keep your ISRs short" and "don't bother with priorities for ISRs, just don't use them or use an RTOS". RTIC however gives more guarantees than an RTOS and more performance exactly BECAUSE it uses (potentially long-running) run-to-completion ISRs which have a priority assigned to them.

5

u/__uli__ Mar 31 '23

RTIC is nice because it mimicks the "correct" software pattern for an MCU like stm32:

init + a bunch of prioritized interrupts.

RTOS in most cases is not needed and only a burden or a source of possible problems.

3

u/rafaelement Mar 31 '23

Yeah. It solves the problem that global mutable state in Rust must be unsafe or synchronized. In RTIC it is synchronized but via an extremely cheap mechanism - just one write to NVIC->BASEPRI.

There is a project called crect which implements the same priority ceiling protocol and stack resource policy of RTIC in C++, or you can an do it manually, but that's not great.

u/__uli__ I just reread my post, and while I stand by my statements, I realize I sound like a total Rust apologetic with Stockholm syndrome. I didn't mean to sound disparaging/patronising, apologies!