You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
the PINS type information must be carried on to the Tx and Rx instances somehow.
the USART and PINS instances need to be carried on to either Tx or Rx in order to be able to recover them when reuniting
These points can be addressed by moving the PINS and USART instances to Tx and adding a PINS PhantomData to the Rx (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 and Tx1Alt?
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.
Fixesstm32-rs#386.
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: