[RFC] API tailored for specific microcontrollers about svd2rust HOT 5 OPEN

If we were able to implement #96, then the solution to this problem would be greatly simplified. Then third-party crates could use not "stm32f103c8::TIM2" but something like "stm32::GPTimer" or "stm32::DAC". This should work very well for
STM32 microcontrollers because their peripherals are very unified. But now svd2rust starts to support other types of microcontrollers so I do not know whether this will be a good solution, for example, for MSP430.

from svd2rust.

I think MSP430 is not affected by this issue yet, because we generate a separate SVD file for each specific MCU.

But we can highly benefit from grouping devices into families and grouping peripherals across devices or even families.
For example, for 596 devices in dslite database, we have only 4 kinds of watchdog timer, 12 kinds of rtc clock, 3 kinds of AES accelerator, etc. In theory we can put the most popular peripherals in one big crate, and have device crates to pull only ones they need.

from svd2rust.

For example, for 596 devices in dslite database, we have only 4 kinds of watchdog timer, 12 kinds of rtc clock, 3 kinds of AES accelerator, etc. In theory we can put the most popular peripherals in one big crate, and have device crates to pull only ones they need.

This is much more diverse than in STM32 devices (in them there are only two types of RTC). But not so bad as I was afraid. Benefits could still outweigh the need to write custom SVD files for this to work.

from svd2rust.

@protomors

If we were able to implement #96, then the solution to this problem would be greatly simplified.

Could you elaborate? I see #96 as the "dual" of this issue. #96 is about reducing the number of types to share them across different device crates. This issue is about restricting the use of instances (not types; i.e. const TIM2 not struct TIM2) when developing for specific devices and it's more tied to conditional compilation, not code reuse.

from svd2rust.

@japaric I was referring to "re-exports" solution.

If there was some way to tell svd2rust that peripherals in different devices are the same (like proposed in #96) then common crate could be not for stm32f103 but for the whole stm32f1 family or even more generic. Like @pftbest said

In theory we can put the most popular peripherals in one big crate, and have device crates to pull only ones they need.

And #96 would allow to automate this process (if SVD files were modified to include such information).

from svd2rust.