Sorry for not being specific and clear enough. I didn't mean to criticize at any degree. 2 years ago when we tried to port part of an esp32 project from C++ to Rust as an experiment, our overall experience was that Rust for embedded was more experimental than production-ready, for the many "glitches" we were getting regarding IDE support, C interop, low-level memory operations, etc.
With enough efforts and good knowledge of Rust's internal working, we could probably have adopted Rust even 2 years ago. I created this thread hoping to hear about how the community feel about the "production-readiness" as a product marketed to non-rust-expert embedded programmers (i.e. take into consideration of how easy things could be done without resorting to advanced hacks).
The Rust-on-ARM story is now pretty solid from what I can tell, so all in all I'd definitely give it a go.
This is the type of answers I was hoping for. We will definitely give it a try if you are saying so.
To elaborate what you have asked:
What, specifically, do you mean by "C interop not being ready"?
I remember we ran into at least the following difficulties, most of which were workable but many of them hinder productivity:
- the lack of "official" [bit fields] support (GitHub - dzamlo/rust-bitfield: This crate provides macros to generate bitfield-like struct. could probably be used instead)
- we need to manually write converters for tagged union types and rust's enum types (though probably there won't exist any systematic solution to this..)
- having to wrap board/OS APIs that is provided as C macros in C functions first (though this is probably rather a library issue)
- special macros (e.g. the esp-idf's
ESP_INTR_FLAG_IRAM macro which specify code placement and is required for interrupt handlers) understandably cannot be used in Rust. We ended up spending a lot of time on this and may/may not have got it to work by hacking linker scripts
easiness of low-level memory operations
It is conventional and sometimes required to write to specific memory addresses (most of the time memory mapped device/io registers) in specific orders where the memory addresses are provided as predefined macros in header files provided by the hardware vendors.
These are probably minor problems since there are usually (sometime dirty) quick hacks to get around but still make the whole experience less palatable. Good HALs definitely would help here.
Also you cannot do something like the below easily:
int port_id = 1;
SOME_MEM_PAGE[SOME_REGISTER_CLASS + port_id*SOME_REG_SIZE] |= 0xff & SOME_MASK
Although it is fair to argue that a function should be created for these kind of accesses, nevertheless it is still a demonstration of the opposite of easiness for doing low-level memory operations.