To add on to what bri3d said, these Rust register definitions are being auto-generated using SVD* files published by the chip vendors. For stm32 for example there are the auto-generated register definitions** and then the HAL layers*** on top that try to build easy to use tools on top of the registers (e.g. an SPI or USART type with write and read functions).

* https://www.keil.com/pack/doc/CMSIS/SVD/html/index.html

** https://github.com/stm32-rs/stm32-rs

*** https://github.com/stm32-rs/stm32f4xx-hal for the stm32f4xx line

I am not terribly well versed in Rust MCU development, but I poked around with the teensy-rs and esp32-rs projects a couple years ago.

ARM seems to provide some XML register description files called SVDs[0]. They seem to do a decent job describing the registers and peripherals in a way that allows code generation tools to create a register access library, upon which higher level HALs can be built.

For an example, you might look at the esp-rs project on GitHub. The lowest level, if I recall correctly, is the Peripheral Access Crate [1]. The README for this project describes a bit about the SVD file, and svd2rs code generation tool. Sometimes the SVD file needs to be patched to produce high quality Rust bindings.

This PAC is then required as a dependency of the higher level HAL for the esp32 [2]. The higher level HAL also implements some traits from a shared Rust HAL effort [3].

I'm not really an expert in Rust so if I've described any of this wrong, someone please correct me.

[0] https://www.keil.com/pack/doc/CMSIS/SVD/html/index.html

[1] https://github.com/esp-rs/esp32

[2] https://github.com/esp-rs/esp32-hal

[3] https://docs.rs/embedded-hal/0.2.2/embedded_hal/

I have developed firmware for Atmel chips. AT90USB1286 for example. Their IDE is nice, libraries are great. Porting switching to Rust just for the heck of it I think is absolutely not worth it. And the type of safety Rust adds for that type of job I think is overvalued. My firmware for MCU works for years and no bugs reported. I can't formally prove that they do not exist but what do I care. I am a practical man. If customers complain and I loose revenue I would look for the reasons why did it happen to avoid repeating. If they don't - I have better things to do than waste my time on yet another language where it does not offer me tangible benefits. I am my own business and programming languages to me are just tools. I do not work to program in particular language. I work to make products I want and have clients pay for it.

C had years for tooling to be developed. Currently I still prefer C and find Rust to be too strict in parts. But I guess when better tools are available, it could be a decent choice.

But for processors this small I currently could not tell you any advantages to be honest.

>"But I guess when better tools are available, it could be a decent choice."

When / if then sure (assuming it would also be compatible with the megatons of very useful libraries written in C). I would have very little desire to replicate something like LUFA for example.

The embedded-hal project supplies these for a wide variety of controllers, for SAMD specifically, https://github.com/atsamd-rs/atsamd .

I'm an amateur doing Rust stuff on SAMD21 (Trinket M0) using the native bindings mentioned in sibling post. It's workable if you start from the examples and evolve from there. Things are still in shift, the ecosystem is very young, so there are areas of API instability, version conflicts or missing features when you try to integrate with other embedded projects (like defmt, cargo-embed or embassy). STM32 support definitely has less rough edges, I'd start there first (e.g. with a bluepill board) and then move to SAMD later.

> Can Rust import and use C header files?

Yes, after piping them through rust-bindgen, any binary can be statically of dynamically linked. I did this, it's nice that it's possible, but the PAC route others have described here is way better.