-
Notifications
You must be signed in to change notification settings - Fork 177
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 reunite for Serial Tx/Rx #386
Comments
horazont
added a commit
to horazont/stm32f1xx-hal
that referenced
this issue
Jan 9, 2022
This becomes relevant as more functions like reconfigure are added to the Serial structs. Fixes stm32-rs#386.
horazont
added a commit
to horazont/stm32f1xx-hal
that referenced
this issue
Jan 9, 2022
This becomes relevant as more functions like reconfigure are added to the Serial structs. We use the Tx to stash away the usart instance used by the (Erased-)Serial struct, but this choice is arbitrary and irrelevant because it is zero-sized anyway. Fixes stm32-rs#386.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
With some functions (e.g. reconfiguration) only safely available when the peripherial is fully under control of the caller, it would make sense to be able to recombine the Tx and Rx parts after a split.
reunite
[1] was attempted in #36 (under the name "release"), however, it was closed because the ReleaseToken was deemed unnecessary. Upon attempting an implementation without the ReleaseToken, I came into a questionable situation:To avoid the release token:
PINS
type information must be carried on to theTx
andRx
instances somehow.USART
andPINS
instances need to be carried on to eitherTx
orRx
in order to be able to recover them when reunitingThese points can be addressed by moving the
PINS
andUSART
instances toTx
and adding a PINS PhantomData to theRx
(or vice versa).However: This has fallout to the
{T,R}x{Dma,}{1,2,3}
type aliases, which then become generic over PINS. That seemed somehow excessive and is for sure a breaking change for downstream code, so I wanted to run this by you folks before venturing further down this direction.Should the type aliases be generalized or should there be explicit aliases for the two options for each USART?
Edit: I just realized that there are many more than just two options: The pins can not just be remapped, but also in OpenDrain/PushPull and the different input modes, making for many many more than just two combinations.
Should we move ahead with the release-token-free way or does this caveat warrant keeping that token (which I personally also find a bit awkward)?
If not generalizing the type aliases, what would be good names?
Tx1
andTx1Alt
?[1]: The name
reunite
has prior art in the owned halves of oftokio::net::TcpStream
. There is alsounsplit
in tokio, but given the choice I'd preferreunite
.P.S.: If it wasn't clear: I'm happy to make an implementation if we can settle the discussion points :)
The text was updated successfully, but these errors were encountered: