Skip to content
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

Add filler types for unused pins in communication peripherals #28

Open
therealprof opened this issue Jan 1, 2019 · 4 comments
Open
Labels
good first issue Good for newcomers

Comments

@therealprof
Copy link
Member

For some communication peripherals it is typical that only partial functionality is used, e.g. only RX or TX for serial or only MOSI for SPI. For these situations we should have filler types which can be used in that case. https://github.com/stm32-rs/stm32f4xx-hal/ already has appropriate implementations which we should be able to reuse for our cause.

CC @david-sawatzke

@therealprof therealprof added the good first issue Good for newcomers label Jan 1, 2019
@david-sawatzke
Copy link
Member

david-sawatzke commented Jan 1, 2019

I've already started #27, which takes a bit different, but similar approach. I personally prefer the approach with an universal Unused pin implementing all the AF traits, but both approaches are (mostly) equivalent. It's doesn't seem hard to modify it.

@therealprof
Copy link
Member Author

@david-sawatzke

I personally prefer the approach with an universal Unused pin implementing all the AF traits, but both approaches are (mostly) equivalent.

Uhm, that's not what your implementation does. I basically just defines an empty shell without any functionality (not even sure why you're using a PhantomData).

@david-sawatzke
Copy link
Member

With AF traits i meant the traits that implement the link from af to peripheral, eg TxPin.

I used PhantomData because I wasn't sure if we maybe need to extend it in the future and without it it's constructable by user code (afaik).

@therealprof
Copy link
Member Author

I used PhantomData because I wasn't sure if we maybe need to extend it in the future

😲

and without it it's constructable by user code (afaik).

In that case you could use

pub struct Unused {
    _0: (),
}

However it doesn't really matter since it's really just an empty shell and there's exactly none functionality attached to it (and true to the meaning never should be...).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

2 participants