Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problems with svd2rust #72

Open
phil-opp opened this issue Dec 18, 2018 · 3 comments
Open

Problems with svd2rust #72

phil-opp opened this issue Dec 18, 2018 · 3 comments
Assignees

Comments

@phil-opp
Copy link
Contributor

  • 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
Copy link
Contributor Author

phil-opp commented Jan 21, 2019

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
Copy link
Contributor Author

@phil-opp
Copy link
Contributor Author

@oli-obk I just read rust-embedded/svd2rust#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 #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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants