rmsyn

@romancardenas fixed the lints in #301

> as soon as we decide to go with edition 2024 After the discussion in today's meeting about updating `svd2rust` to edition 2024, I think the same arguments apply to...

> creating many new types overloads compiler and it much slower (3 times and bigger). Wow, that is definitely the opposite of the goal of this proposal. Thank you for...

> No registers block. But derivedFrom attribute. > Also I recommend to add groupName for all peripherals which specifies peripheral type. So, I followed your advice, and applied the `derivedFrom`...

Reposting a comment I left in the `rust-embedded` Matrix channel for tracking purposes: So, I tried a bit of an experiment manually splitting out the peripheral modules into crates. From...

> Have you tried to implement it? That is the question. Yes, but only had success with a manual implementation of a single small peripheral (`Clint`). I tried some additional...

> If you are saying about declarative macros that is what [stm32ral](https://crates.io/crates/stm32ral) exactly does. > If you are saying about procedural macros I'll keep looking at `stm32ral`, but I don't...

> Maybe this would also be a viable new issue, but I think this is super interesting for a project I am currently planning. I was thinking the same thing,...

> What kind of extension do you mean? How should it look like? In code, it could look something like: ```rust pub struct Uart { _marker: PhantomData, } impl Uart...

@burrbull looks like we have another example in a similar context (Rust codegen from SQL), of using separate crates drastically decreasing compile time: https://www.feldera.com/blog/cutting-down-rust-compile-times-from-30-to-2-minutes-with-one-thousand-crates