Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



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.


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.


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?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: