Problems with svd2rust

[phil-opp]

• The read/modify/write API takes only &self instead of &mut self for write and modify, which makes the register structs !Sync.
• The Peripherals API creates an empty type for each register block that derefs to a RegisterBlock type, which contains the actual struct. This makes it impossible to get a &'static mut reference to the register block without boxing and unsafe. Instead, the Peripherals struct could directly contain &'static mut RegisterBlock references.

[phil-opp]

The simplest way to fix these problems would be to update svd2rust in the following way:

• The write and modify methods of the individual registers take &mut self instead of &self.
  • This way the RegisterBlock structs (and the zero sized types) can be Sync.
• The zero-sized types contained in the peripherals struct additionally implement DerefMut and provide a as_static_mut(self) method that returns a &'static mut RegisterBlock.

To avoid breaking changes in svd2rust, these changes could be gated by a cargo feature (i.e. svd2rust would generate code that contains conditional compilation depending on a cargo feature).

cc @oli-obk

[phil-opp]

Some links that show the current API:

• Peripherals
• Zero-sized Peripherals field
• A RegisterBlock struct
• The read/modify/write methods

[phil-opp]

@oli-obk I just read https://github.com/rust-embedded/svd2rust/pull/270 and I think I understand the design decisions of svd2rust better now. I also had some new ideas how to create APIs on top of the zero sized singletons. For example, we can change our i2c type to take ownership of the ZST singleton instead of trying to store a &'static mut RegisterBlock. I implemented these changes in https://github.com/embed-rs/stm32f7-discovery/pull/76.

I try to find more svd2rust pain points in our current code. Maybe I can find better solutions for them too, otherwise I'll post them in the svd2rust issue.