[m0lecules]

Why is it this way though - it seems to me like you could create a type that just works like the C code

  struct Uart {
    u8 CR2,
    // etc.
  }

Instantiate it as 'static with some macro that defines where it lives in memory:

  #[mcu::loc(0x1002010)] static UART1 = Uart::new();
  #[mcu::loc(0x1003010)] static UART2 = Uart::new();

And then have it bound directly to the memory locations on the MCU at compile time/link time.

Still learning rust, so apologies if this syntax doesn't make sense.

[steveklabnik]

Yes, the syntax doesn't have to be this way, it's just the way that the libraries in the ecosystem tend to do it. It works, but it does also have quite a few problems, imho. But since it's just a particular library, you can write your own or use a different one.

[oxidizedcutrace]

Good question! I'm also not a Rust expert, but maybe that syntax would be considered unsafe in some situations?

I think the 'peripheral access crates' try to auto-generate those sorts of struct objects from SVD files, but you still need to obey Rust's ownership rules to get the advantage of its built-in memory safety.

So if a function needs to modify a peripheral's memory, it needs to claim mutable ownership of the relevant peripheral registers. That's a feature of the language which makes it 'safer', but the cost/benefit calculation is a bit different on embedded platforms. They have less memory, and static allocation is usually preferred.

Still, microcontrollers are getting faster quickly. You can even run Linux on some cortex-M4/M7 chips. The verbose syntax might be worthwhile if you're collaborating on complicated firmware.

[m0lecules]

I'm not sure I agree on the safety aspect - if they only thing preventing unintentional peripheral access is verbosity, that's not really the kind of security that matters, is it?