Leverage typelevel implementation in i2c, pwm (and a little bit in uart). #560
Conversation
ithinuel
force-pushed
the
experiment-with-typelevel
branch
2 times, most recently
from
985bae5 to
f1bfced
Compare
| TX::Id: ValidTxPin<UART>, | ||
| RX::Id: ValidRxPin<UART>, | ||
| CTS::Id: ValidCtsPin<UART>, | ||
| RTS::Id: ValidRtsPin<UART>, |
There was a problem hiding this comment.
I'm currently only reading this on my phone so it's quite likely that I'm missing the big picture, literally. But I wonder: does this still, somehow, guarantee that the combination of pins comprises a valid set of pins for the UART peripheral, as the name of the struct implies?
There was a problem hiding this comment.
(it probably does, because the restriction on the Id types implies that the TX/RX/... types are also valid for the UART, right?)
There was a problem hiding this comment.
Yes. At least that is how I understand it.
I tried to build a Pins with an invalid set of pins (Cts instead of Rx and mixed UART) and they appropriately failed saying the ValidUartPinout bound wasn't satisfied.
Edit: It was missing the validation of the function for the tuple styled pinouts.
ithinuel
force-pushed
the
experiment-with-typelevel
branch
3 times, most recently
from
ae59170 to
f75bdf6
Compare
…rt). This notably makes the documentation more readable.
ithinuel
force-pushed
the
experiment-with-typelevel
branch
from
f75bdf6 to
2aa932b
Compare
|
BTW, this is a breaking change as it removes some traits. |
|
Converting to draft as I'm progressing on GPIO overhaul and more breaking changes. |
|
Closing in favor of #585 |
This notably makes the documentation more readable.