Skip to content

save access to unions #230

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
burrbull opened this issue Jul 15, 2018 · 5 comments · Fixed by #318
Closed

save access to unions #230

burrbull opened this issue Jul 15, 2018 · 5 comments · Fixed by #318

Comments

@burrbull
Copy link
Member

With --nightly option svd2rust now can generate unions:

#[doc = "capture/compare mode register 1 (input\n          mode) capture/compare mode register (output\n          mode)"]
#[repr(C)]
pub union Ccmr1Union {
    #[doc = "0x18 - capture/compare mode register 1 (input mode)"]
    pub ccmr1_input: CCMR1_INPUT,
    #[doc = "0x18 - capture/compare mode register (output mode)"]
    pub ccmr1_output: CCMR1_OUTPUT,
}

I think it makes sense to add save access to contents.
Something like:

impl Ccmr1Union {
    #[doc = "ccmr1.input()"]
    pub fn input(&self) -> &CCMR1_INPUT {
        unsafe { &self.ccmr1_input }
    }
    #[doc = "ccmr1.ouput()"]
    pub fn output(&self) -> &CCMR1_OUTPUT {
        unsafe { &self.ccmr1_output }
    }
}
wez added a commit to wez/svd2rust that referenced this issue Jan 3, 2019
This removes any observable side effect of the --nightly switch by
removing the use of unions and the untagged_unions feature gate.
Unions are replaced with accessor functions that return the appropriate
register block reference.

Here's a playground link that shows that the pointer calculation looks
reasonable:

https://play.integer32.com/?version=stable&mode=debug&edition=2018&gist=cd56444abc03e6781e526bbddc7082bc

This commit is a breaking change.

This is based on this WIP PR branch:
rust-embedded#256

It implements the easiest standalone portion of this issue:
rust-embedded#218

and also makes accessing the unions "safe" too, which is requested here:
rust-embedded#230
@wez
Copy link
Contributor

wez commented Jan 4, 2019

I'm taking a stab at this in https://github.com/wez/svd2rust/tree/no_unions

@burrbull
Copy link
Member Author

burrbull commented Jan 4, 2019

You forgot to add _reserved_ccmr1_output: [u8; 4usize], in RegisterBlock in place of removed union registers.

@wez
Copy link
Contributor

wez commented Jan 4, 2019

@burrbull oh, that's bad. Can you point me to the svd file you're using? That doesn't happen with the ATSAMD files I'm using and I'd like to make sure this is working

@wez
Copy link
Contributor

wez commented Jan 4, 2019

ah, never mind, I can see that it is happening here

@wez
Copy link
Contributor

wez commented Jan 4, 2019

pushed a fix; thanks for catching that!

@burrbull burrbull mentioned this issue Jul 13, 2019
burrbull pushed a commit to burrbull/svd2rust that referenced this issue Jul 19, 2019
This removes any observable side effect of the --nightly switch by
removing the use of unions and the untagged_unions feature gate.
Unions are replaced with accessor functions that return the appropriate
register block reference.

Here's a playground link that shows that the pointer calculation looks
reasonable:

https://play.integer32.com/?version=stable&mode=debug&edition=2018&gist=cd56444abc03e6781e526bbddc7082bc

This commit is a breaking change.

This is based on this WIP PR branch:
rust-embedded#256

It implements the easiest standalone portion of this issue:
rust-embedded#218

and also makes accessing the unions "safe" too, which is requested here:
rust-embedded#230
@burrbull burrbull mentioned this issue Jul 19, 2019
bors bot added a commit that referenced this issue Jul 19, 2019
318: No unions3 r=therealprof a=burrbull

Implemented by @wez this PR replace untagged unions with functions for access to alternate registers.

Closes #230, #218, stm32-rs/stm32-rs#149 .

cc @therealprof

Co-authored-by: Wez Furlong <[email protected]>
@bors bors bot closed this as completed in #318 Jul 19, 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.

2 participants