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 support for changing USART settings #266

Merged
merged 7 commits into from
Aug 3, 2020
Merged

Add support for changing USART settings #266

merged 7 commits into from
Aug 3, 2020

Conversation

hannobraun
Copy link
Member

This is mostly restricted to settings that don't require new modes (like synchronous or RS-485 mode) to be added.

Settings that require further API changes have been left out at this
point.
I think this is already nicer as-is, but it will become even better once
more modes (which require more enable methods) are added.
Default states have been remove from some other peripherals already, and
the same reasons, namely there no longer being a clear default, are soon
going to apply here too.
The general `init_state::Enabled` struct is flexible, but it can lead to
some unpleasantness, as seen with the whole clock configuration stuff in
the I2C API, that involves `PhantomData` in the type signature.

I am about to make some changes that would introduce the same kind of
ugliness in the USART API. Adding a bespoke `Enabled` type will make
this a bit nicer.
This required adding support for `u16` as another word type. Some code
(namely `write_str` and anything DMA-related) is still hardcoded to
`u8`, preventing the use of 9-bit data in those scenarios. This can be
rectified later, as required.
@hannobraun
Copy link
Member Author

There were conflicts with #263 that I was unaware of. Rebased.

Copy link
Member

@david-sawatzke david-sawatzke left a comment

Choose a reason for hiding this comment

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

I'm not too happy about the added complexity in the trivial case, but it's not too bad

@hannobraun
Copy link
Member Author

I'm not too happy about the added complexity in the trivial case, but it's not too bad

We can always make improvements later, if you have any ideas. This is the best I could come up with at this time. I don't think we can do much better without losing type safety.

@hannobraun hannobraun merged commit 275107a into lpc-rs:master Aug 3, 2020
@hannobraun hannobraun deleted the usart-settings branch August 3, 2020 18:12
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.

2 participants