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
If you want to configure peripherals that require processor pads, you need to set the pad into the correct 'alternative,' or mode. Pads have multiple alternatives, depending on their usage. (This is also called pin muxing.) The current approach puts the responsibility on users to know what alternative is necessary for a given peripheral. Although this could be identified from the method signatures, it's more overhead, and the user's code isn't as clean. We should be able to simplify this API.
Consider the initialization of a UART peripheral, using Teensy pins 14 and 15. The snippet below describes how it happens today.
If we follow that through, we see that GPIO_AD_B1_02 can only be the TX pin for UART 2 when it's in the second alternative. Same applies for GPIO_AD_B1_03 as an RX pin. The only way to get a pad in that state is to call alt2().
I want to remove the requirement for users to set the alternative. Remove the calls to alt2() so that the snippet simplifies to
letmut uart = uarts
.uart2.init(
peripherals.pins.p14,// no more alt2() call
peripherals.pins.p15,// no more alt2() callBAUD,).unwrap();
A solution should not sacrifice compile-time checking for a convenient API. You cannot provide the wrong pin to the UART module; if you tried to pass in p13, rather than p14, for the TX pin, it fails to compile. You also cannot put the pin into the wrong alternative; a call of alt3(), rather than alt2(), fails to compile. We should keep these kinds of guarantees in a new approach.
This will probably require changes throughout the HAL, including in the IOMUXC modules, and all peripheral modules that depend on processor pins.
The text was updated successfully, but these errors were encountered:
If you want to configure peripherals that require processor pads, you need to set the pad into the correct 'alternative,' or mode. Pads have multiple alternatives, depending on their usage. (This is also called pin muxing.) The current approach puts the responsibility on users to know what alternative is necessary for a given peripheral. Although this could be identified from the method signatures, it's more overhead, and the user's code isn't as clean. We should be able to simplify this API.
Consider the initialization of a UART peripheral, using Teensy pins 14 and 15. The snippet below describes how it happens today.
See those calls to
alt2()
? Those set the pins into the correct alternative for UART. They're required because the signature ifinit()
looks likeand the
uart::Pin
implementations resembleIf we follow that through, we see that
GPIO_AD_B1_02
can only be the TX pin for UART 2 when it's in the second alternative. Same applies forGPIO_AD_B1_03
as an RX pin. The only way to get a pad in that state is to callalt2()
.I want to remove the requirement for users to set the alternative. Remove the calls to
alt2()
so that the snippet simplifies toA solution should not sacrifice compile-time checking for a convenient API. You cannot provide the wrong pin to the UART module; if you tried to pass in
p13
, rather thanp14
, for the TX pin, it fails to compile. You also cannot put the pin into the wrong alternative; a call ofalt3()
, rather thanalt2()
, fails to compile. We should keep these kinds of guarantees in a new approach.This will probably require changes throughout the HAL, including in the IOMUXC modules, and all peripheral modules that depend on processor pins.
The text was updated successfully, but these errors were encountered: