Peripheral interconnect redo, vol 2 (split())
#2418
Conversation
bugadani
force-pushed
the
interconnect
branch
from
24efde3 to
3ad9b69
Compare
bugadani
force-pushed
the
interconnect
branch
5 times, most recently
from
8b14709 to
71d9427
Compare
|
|
||
| /// Returns a peripheral [input][interconnect::InputSignal] connected to | ||
| /// this pin. | ||
| impl<P> Input<'_, P> |
There was a problem hiding this comment.
See comment on spi_slave test.
hil-test/tests/spi_slave.rs
Outdated
| let cs = cs_gpio.peripheral_input(); | ||
| let sclk = sclk_gpio.peripheral_input(); | ||
| let mosi = mosi_gpio.peripheral_input(); | ||
| // let miso = unsafe { miso_gpio.clone_unchecked() }.into_peripheral_output(); |
There was a problem hiding this comment.
I'm considering my options here. This unsafe clone can be replaced by a Flex::split_peripheral_output() -> (interconnect::OutputSignal, Input) (and same method on Output and OutputOpenDrain), but then we can't have split and into_peripheral_output on Input. I'm not sure which one is better, working with Flex is somewhat low level - but so is splitting off an output signal and keeping a GPIO input.
This comment was marked as resolved.
This comment was marked as resolved.
bugadani
force-pushed
the
interconnect
branch
3 times, most recently
from
52f4fb0 to
71d9427
Compare
bugadani
force-pushed
the
interconnect
branch
3 times, most recently
from
4d59d75 to
16b376a
Compare
bugadani
changed the title
split())
|
Perhaps a naive question, what's the point of the owned |
|
What is "owned split"? |
|
Ah this PR is a preparation for #2419. After #2419 there will be a difference between passing a pin to a peripheral (may bypass the GPIO matrix) and passing a signal to a peripheral (forces use of the GPIO matrix). We can't provide a non-splitting way to obtain signals, because GPIO matrix usage won't be unambiguous. |
|
Ah okay I think I answered my own question actually. This PR stops someone using a GPIO pin's signal for something and then doing something with the pin itself which might end up overwriting some signal-related operations? |
|
The only intended change is that peripherals won't try to force their specific alternate function on a GPIO, but instead always go through the GPIO matrix. The side-effect is that "split-then-create-a-gpio-driver" use cases will need to be flipped to "create-driver-then-split-off-signal". There shouldn't be any reduction in flexibility I hope. |
bugadani
force-pushed
the
interconnect
branch
from
16b376a to
d6cf19a
Compare
bugadani
force-pushed
the
interconnect
branch
from
8754f5d to
0d605cb
Compare
|
Not really related but I'm wondering if we should briefly explain things like signals and alternate functions in the GPIO module docs |
|
Definitely, although I'd leave it to upcoming documentation work (or just the next PR) |
bugadani
force-pushed
the
interconnect
branch
from
0d605cb to
c6ce9f3
Compare
bugadani
force-pushed
the
interconnect
branch
from
c6ce9f3 to
6c3f051
Compare
I've tweaked the docs in #2419 a bit but as we don't exactly advertise alternate functions I think it's fine to keep their docs where they are. |
This PR replaces the previous getters with a
splitfunction. This will allow eventually resolving #2273 by introducing different variants for when the GPIO is split, vs when the GPIO is passed wholly to a peripheral. This also allows us to remove a few hacks around input/output initialization - if a pin was split,enable_outputshouldn't disable input, for example.Pin drivers retain their getters and instead convert into signals that (will) force GPIO matrix use.