-
I'm pretty new to Rust, so apologies in advance if this should be obvious. What's the right way to pass a generic pin to a function (or via a struct) such that the pin can be switched between input and output later? Background: I want to use the HD44780 lcd module and this requires filling out a context struct and implementing a trait that uses the hardware resources referenced in the context struct to read and write from the device. I can't figure out how to represent generic pins in the context struct in a way that will allow me to switch them between inputs and outputs. At the moment I have something like: // Hardware struct for HD44780 character LCD
pub struct LcdHw<'a> {
d4: &'a iomuxc::ErasedPad,
d5: &'a iomuxc::ErasedPad,
d6: &'a iomuxc::ErasedPad,
d7: &'a iomuxc::ErasedPad,
gpio: &'a gpio::Port<2>,
// ...
}
impl<'a> lcd::Hardware for LcdHw<'a> {
fn rw(&mut self, bit: bool) {
if bit {
// Configure d4..d8 as output
} else {
// Configure d4..d8 as input
}
}
// ...
} Any clues? |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
One issue is that the erased pads don't know how to become a GPIO input / output. So even though we have those erased pad references, we're still not equipped to tell the GPIO port our intended direction or output state. The GPIO port normally depends on the strong type information to understand how to configure an input / output. That adds type complexity. The solutions are definitely non-obvious. I'll provide two options that are possible in today's BSP. The commit message describes the options at a higher level. Haven't tested these beyond a type check, but I hope these can get you started. I'm happy to answer follow-ons here, and discuss other designs that may be simpler for Rust newcomers. |
Beta Was this translation helpful? Give feedback.
-
Thanks for the quick and comprehensive response (and sorry for my being slow to get back to it). This gives me heaps to go on! |
Beta Was this translation helpful? Give feedback.
One issue is that the erased pads don't know how to become a GPIO input / output. So even though we have those erased pad references, we're still not equipped to tell the GPIO port our intended direction or output state. The GPIO port normally depends on the strong type information to understand how to configure an input / output. That adds type complexity.
The solutions are definitely non-obvious. I'll provide two options that are possible in today's BSP. The commit message describes the options at a higher level. Haven't tested these beyond a type check, but I hope these can get you started.
I'm happy to answer follow-ons here, and discuss other designs that may be simpler for Rust newc…