svd2rust
svd2rust copied to clipboard
Ship a 1.0 release
Part of https://github.com/rust-embedded/wg/issues/383
Blockers:
- [ ] Add your blocking issues here
I'd like to nominate https://github.com/rust-embedded/svd2rust/issues/213. I don't have the bandwidth to work on it, so if the powers that be decide it's not worth their time, that's fine. But I think it should be considered.
Proposing a few things:
- Document the safety guarantees provided by svd2rust PACs
- Is
write_with_zerosafe regarding those guarantees? I think it can be used to write illegal values into registers with write constraints. - Consider using
links = "device-peripherals"in the generated crate's manifest - Implement
bare_metal::StaticResourceforPeripherals(once a new version ofbare-metalhas been released) - Improve build times of generated code to the point where i.MX RT PACs can be generated in a reasonable time frame (I'd say something like 30 seconds on a system with 8 GB of RAM) – also consider tracking this in a similar manner to https://perf.rust-lang.org/ to catch regressions
* Is `write_with_zero` safe regarding those guarantees? I think it can be used to write illegal values into registers with write constraints.
Good point. I missed this.
Does the 1.0 backcompat guarantees apply to the generated PAC crates as well as svd2rust itself? If so, do we only care about backcompat for ARM PACs or for all architectures (MSP430, RISCV)?