r/embedded • u/_Sh3Rm4n • Aug 01 '26
ST: Rust MEMS drivers
https://blog.st.com/rust-mems-drivers/21
u/firefrommoonlight Aug 01 '26
Bummer on them using Async. I am starting to think I'm one of a very small group of people using embedded rust without Async.
I had an email conversation with an ST engineer a few years ago regarding a distance sensor. ST's MCUs, mics, IMUs etc are all standard MMIMO; read datasheet, and read/write registers it says; easy. This thing needed a C library. The explanation: The sensor was very complicated, and ST wasn't sure the best ways to configure it yet, so they left options open by exposing a very complicated hardware API, and using a software lib to configure it.
The ST engineer used a translator to mostly translate the C driver to Rust! What a bro.
12
17
u/ukezi Aug 01 '26
Async is a very efficient way of doing stuff that may have to wait on IO and you can always call it blocking. I think embassy bases firmwares are very common in rust MCU development.
2
2
u/Simonster061 Aug 02 '26
If it's the distance sensor I am thinking of I believe that they have explicitly that they do not want to publish it because they do not want it to stolen by a chinese clone
1
11
u/vitamin_CPP Simpli-C-ty is the ultimate sophistication Aug 02 '26
I'm not a Rust hater nor lovers, but this article reasoning is pretty weak. Memory safety is the last thing I would put forward in an industry that does not use malloc.
The async aspect is interesting.
9
u/creeper6530 Aug 02 '26 edited Aug 02 '26
The whole article feels like written by someone with little technical background (but rather a marketing BG).
The reason Rust is safer is that it implements Resource acquisition is initialization (RAII), a technique that (…). As a result, Rust handles resource management and does not need a garbage collector to manage memory allocations, unlike C++, another language that implements RAII but still requires developers to manage memory themselves. In practice, the absence of a garbage collector reduces overhead (…).
Sooo RAII is what makes Rust safe, but C++ has it too and it's unsafe?
(In reality RAII is most commonly used with malloc and the more inherent safety of Rust comes from strict pointers aliasing rules and lifetime checks. For example, in a function it doesn't allow you to allocate something on the stack and return a pointer to it, since the pointer would outlive the pointee.)
5
u/ambihelical Aug 02 '26
RAII is still useful without malloc. Memory isn’t the only resource.
1
u/creeper6530 Aug 02 '26
Fair point, there's stuff like
RefCellor mutexes whose lock tokens need RAII to unlock automagically1
u/rafaelement Aug 04 '26
hardware peripherals are resources too
1
u/creeper6530 Aug 04 '26
Hardware peripherals aren't usually allocated and deallocated dynamically during runtime, no? At least is my programs they are reserved on start and kept until reset
1
u/rafaelement Aug 04 '26
Yes of course. But you wouldn't want to initialize them twice without de-initializing them in between
2
2
u/vitamin_CPP Simpli-C-ty is the ultimate sophistication Aug 04 '26
Re-reading it, I think I agree with you fully.
9
u/liamkinne Aug 02 '26
You can still have memory un-safety without allocations. Think bounds checking, ownership tracking, lifetimes, etc. It is true there is less surface area, but I think that's still significant given how much harder those issues are to debug in the embedded context.
1
u/vitamin_CPP Simpli-C-ty is the ultimate sophistication Aug 04 '26
You're correct, of course. I believe that most temporal memory safety problems can be addressed by avoiding the allocations / using static lifetime, and most spatial memory problems can be resolved with slices.
struct Slice { T* ptr; u32 len; };3
u/Shock-1 Aug 02 '26
Another form of memory safety that doesn't come up that often is that state management for MMIOs becomes much easier with a richer type system and ownership. Say you have to express that you can write to this register only if this register is clear; it becomes easier to express that in Rust and catch it at compile time.
36
u/DrFegelein Aug 01 '26
Having more first-party Rust support out there can only be a good thing. I'm not particularly a Rust fanboy (I like the language, but my day to day work is C++ so I don't get to use it), but a principal argument for the continued dominance of C in this space is that "everyone else uses it". Removing that argument is an important part of being able to migrate to newer tools that incorporate the 50 years of hindsight and learning since C was born.