Skip to content

[RFC] one type per register block #65

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

Closed
japaric opened this issue Mar 14, 2017 · 1 comment · Fixed by #66
Closed

[RFC] one type per register block #65

japaric opened this issue Mar 14, 2017 · 1 comment · Fixed by #66

Comments

@japaric
Copy link
Member

japaric commented Mar 14, 2017

Right now, when dealing with derived peripherals, svd2rust uses type aliases:

pub mod tim2 {
    pub struct RegisterBlock { .. }
}

pub use tim2::RegisterBlock as Tim2;
pub type Tim3 = Tim2;
pub type Tim4 = Tim2;
pub type Tim5 = Tim2;

Thus all both the base peripheral and the derived peripherals have the same
type.

I propose we change svd2rust to generate a different type for each peripheral.

pub mod tim2 {
    pub struct RegisterBlock { .. }
}

pub struct Tim2 { register_block: tim2::RegisterBlock }
impl Deref for Tim2 { type Target = tim2::RegisterBlock; .. }

pub struct Tim3 { register_block: tim2::RegisterBlock }
impl Deref for Tim3 { type Target = tim2::RegisterBlock; .. }

pub struct Tim4 { register_block: tim2::RegisterBlock }
impl Deref for Tim4 { type Target = tim2::RegisterBlock; .. }

pub struct Tim5 { register_block: tim2::RegisterBlock }
impl Deref for Tim5 { type Target = tim2::RegisterBlock; .. }

The rationale is that you may want to have API that works for one peripheral,
e.g. TIM2, but not for the others. You can only enforce that if you have
different types for the peripherals. Another similar use case is APIs that
depend on some specific combinations of peripherals: PWM1 = GPIOA + TIM2, PWM2 =
GPIOB + TIM3, etc.

@japaric
Copy link
Member Author

japaric commented Mar 14, 2017

Implementation in #66

wez added a commit to wez/svd2rust that referenced this issue Jan 3, 2019
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

Successfully merging a pull request may close this issue.

1 participant