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

i2c Deref #183

Merged
merged 1 commit into from
Jun 24, 2020
Merged

i2c Deref #183

merged 1 commit into from
Jun 24, 2020

Conversation

burrbull
Copy link
Member

@burrbull burrbull commented Feb 9, 2020

Same as #182

@burrbull
Copy link
Member Author

Rebased

@@ -203,7 +203,7 @@ impl<REMAP, PINS> Spi<SPI3, REMAP, PINS> {
}
}

type SpiRegisterBlock = crate::pac::spi1::RegisterBlock;
pub type SpiRegisterBlock = crate::pac::spi1::RegisterBlock;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason, this is part of this PR?

@burrbull
Copy link
Member Author

Rebased.
cc @TheZoq2

@TheZoq2
Copy link
Member

TheZoq2 commented Apr 26, 2020

Sorry for taking such a long time to review this.

I'm not sure how I feel about the change. To me it kind of makes the code harder to read, but that might be because I'm fairly used to reading macro code.

In addition, the related change to the spi made the documentation harder to read, Pins is now completely useless for example https://docs.rs/stm32f1xx-hal/0.5.3/stm32f1xx_hal/spi/trait.Pins.html Though I suppose that will not happen here since the pins struct remains the same.

In the SPI case, we got the advantage of being able to do partial mapping of the SPI peripherals, but I don't think we are able to do that here.

I guess my point is that I don't think the changes in this PR make much sense, but I'd love to be convinced otherwise

@burrbull
Copy link
Member Author

I can’t imagine how it can be more difficult to read than macros.

And this PR does not do anything with pin remap.
It just replaces hal macro with Deref.

@therealprof
Copy link
Member

I have to agree with @burrbull here. Not only is that code easier to read, it also receives full benefit of Rust infrastructure including proper formatting, rust-analyzer support and usable compiler error messages when working on the implementation.

I also agree with @TheZoq2 that the documentation needs some work and is less useful after the macro removal.

@TheZoq2
Copy link
Member

TheZoq2 commented Jun 21, 2020

I can’t imagine how it can be more difficult to read than macros.

Maybe it's because of how used I am to the macros. I think the thing I don't like about it is how many layers of function calls there are in the initialisation. Something about it makes it hard to read.

Not only is that code easier to read, it also receives full benefit of Rust infrastructure including proper formatting, rust-analyzer support and usable compiler error messages when working on the implementation.

That's a very good point. Coupled with both of you disagreeing with me about the readability, I think we should merge this.

@burrbull Would you mind making the same change I did in #232 which was one of the main things I disliked about this change?

@burrbull
Copy link
Member Author

Rebased

@TheZoq2
Copy link
Member

TheZoq2 commented Jun 21, 2020

Looks like you added the changelog entry to the 0.6.0 version instead of unreleased

@burrbull
Copy link
Member Author

Fixed

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 this pull request may close these issues.

4 participants