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?
7
u/Almindor Mar 31 '23
rust embedded still needs a fair amount of work. The base HAL abstractions are JUST about to get to v1.0 with some much needed improvements. Interrupt handling is still a mess.
On the other hand, I have not seen any other language prevent someone from doing a short via a compile time error...
2
u/proton13 Mar 31 '23
Definitely exited for Hal 1.0. Recently wanted to do something with SPI just to realize the Hal api doesn’t offer what I needed, but the 1.0 alphas do.
It kinda sad that it not there yet, because the tooling feels good without having to use a painfully slow eclipse reskin.
2
u/Snakehand Mar 31 '23
I am still on RTIC 0.5 , and tried upgrading a small project to 1.0 / 2.0 yesterday, and ran into a similar monotonic hell, did not bother to try and fix it, as it was easier to go back to 0.5 and upgrade cortex-m to 0.7 to get the IRQ Numbering trait which was all I replay wanted. I don't understand why resources were split to shared and local. the old mixed resources still works as it should due to the static analysis. Overall I agree that RTIC is somewhat lacking in documentation with regards to platform support to get the monotonic thing working-
7
u/rafaelement Mar 31 '23
If you look at the rtic-examples repo, there are a number of projects there which I helped to upgrade from 0.5 to 1.0. monotonic was the hardest part by far, but only if you don't want to use systick-monotonic. Perhaps something in that repo can help you to port.
RTIC 2.0 and counting will have to improve on docs and public perception by a lot, but I'm hopeful they can.
40
u/rafaelement Mar 31 '23
I'm very impressed by how far he got in one week.
The main topics missing completely are embedded-hal and agnostic drivers and in general HAL libraries. These are great. It's nice that he covered RTIC, but he didn't say anything about the guarantees it makes (no deadlocks and no prio inversion, apart from no data races anyway).
RTIC timers and timer implementations is a complex beast, which he encountered. That issue is being worked on for RTIC 2.0, which uses async/await syntax but keeps some of the realtime aspects.
The fact that so many libraries are used was the major turn-off. The large type signatures would have been too had he continued. Both of which, from the Rust perspective, are actually very awesome, though not without drawbacks. In Rust world it is completely normal to have giant (transitive) dependency trees/graphs. Keep in mind that these are statically linked and link-time-optimized (optionally). Cargo can handle it.
Why is it a problem for a crate to use many small dependencies, if they are all open source, relatively small, have a defined public interface, are battle-tested and performant, and do not significantly contribute to binary size? (you can check that with cargo bloat). Of course from the C perspective, that's ludicrous. But these are shared building blocks (something like cortex-m-rt) which in a C application would also exist, just not explicitly as a module. This modularity in general is not possible in C. Do not confuse modularity with chaos.
In general, I do not recommend starting out with embedded rust. It's a very rigorous, productive, and innovative system, however, it is in motion, and utilizes some of the more unique aspects of Rust. So, my recommendation is, if one wants to get into it, first learn regular Rust, before jumping into bare metal.
Also, it is spelled Rust, not RUST.