Other than Arduino, which of course has pretty good support for many devices and is likely to work out of the box.
I run an electronics workshop at an artschool, so the end result counts and how we get there is more or less arbitrary unless it happens in a finite timeframe. For my own private projects I tried Rust, but also there my goal is to get things done, not to fool around forever. I like fooling around with the interesting bits, not with rewriting a thing others have written before.
For some reason the rust community seems to love rewriting things others have done before and not do much new work.
At this point the biggest thing holding the language back are its users.
#1: You benefit from the nice tooling and language of rust #2: You are forced to learn how to use peripherals at a lower level than would otherwise be required. You will become adept at reading datasheets, and interacting with hardware, because you will write to registers directly while building your own abstractions.
The easy choice is to use C or C++.
At least for the ssd1306 and the sh1106 there is in fact a library for it that works well.
I recently started working on a rust-esp32 project because I'm far too lazy to properly deal with json in C. It was basic, some buttons, a display, an encoder, and a web api but it was a breeze. I'd really like to continue on more complex projects in the future. I've somehow avoided writing C++ in an embedded setting and now I'm afraid I might have to go back and learn that rather than continue with Rust.
There's a couple forward thinking companies like memfault, but it seems to be the minority.
My degree was in CE so I've always played around with embedded projects, but actual design skills have stagnated from being in my field, which trends towards only developing smaller purpose built tools for internal use over products.
The semantics as you cross the boundary are ill-defined. And you will pay dearly if the C library wants to own any of the resources (like an event loop).
And "unsafe" programming in Rust is really difficult to get right--possibly harder than C.
To be fair, these problems are not inherent to Rust--any language which tries to interface with C will have them.
Yes, including C.
Two C libraries interface just fine if library 1 handles ownership and library 2 (or your program) simply operates on the resulting things being passed around.
Rust, on the other hand, will go bananas and your life will be miserable. See: http://way-cooler.org/blog/2019/04/29/rewriting-way-cooler-i...
To me, it seems like they'd lost motivation years previously and were increasingly flailing around for something that would spark the same joy as initial work on an exciting new project, and Rust has little to do with that.
Lots of crates exist which wrap popular C libraries, and they don't seem to run into the sort of misery you describe.
I had a sense this a priority for the Rust Central Committee, so I had a quick look
https://docs.rust-embedded.org/book/interoperability/c-with-...
I have not had to use it yet, looking for a reason.
What? Are there really people out there relying on libraries for every peripheral? I've never seen anyone use a third party library for peripherals like that, short of some prototyping on an Arduino or the like. It's always just drivers implemented from scratch.
Maybe the mindset of the industry as well?
Not sure if things have changed (and if so, how) but 9-10 years ago when i was in university I had an interview with a company that did embedded systems stuff. While talking about my competencies I mentioned I was able to create cross-toolchain if they were interested and the guy (he was kinda like the CTO iirc) abruptly interrupted me and just said:
"no. just no. we always and only use the vendor's BSP (board support package). we don't care about anything else. should there be any kind of issue we want to be able to ring them and get them to fix the issue.".
How do you get people (or an industry?) with such a mindset to just use something because it's trendy?
My guess is that industry will wait another 10-15 years until some vendor big enough ships a rust toolchain as a BSP. Other vendors will follow. Then Rust on embedded systems will flourish.
You need to be in the right kind of company - the one where waiting for the external vendor to fix their shit is too slow.
So let's say I happen to work with a MCU that is well supported in Rust, what if I want to connect it to a popular OLED display? Is there a library for that? If so, does it work? If it works, does it have the needed features? Now maybe I am incredibly lucky and all of that works, what about a popular gyro IC?
Granted, there is probably some way to interface the Rust code with C code, but is that gonna work without turning it into a day of research?
I will certainly check back on the state of Rust on embedded every now and then, but as of now C++ is my goto.