Demonstrate GPIO interrupts on the LPC55S69-EVK board. #1919
Conversation
Pressing the USER button generates an interrupt to the button task.
A single press will increment the RGB pattern.
Quick (~1.5s) successive presses 2nd, 3rd, and subsequent will respecitvely
- turn off LEDs
- blink LEDs
- cycle through RBG pattern including all off.
Minor updates to other app.toml files:
- add `pint` and `inputmux` peripherals to their `gpio_driver` tasks.
- when compiling all targets, some needed slight allocation
adjustments not related to this PR.
| // Ensure that the pin is configured as an input during | ||
| // PINT setup. XXX remove if not needed. | ||
| let (tport, tpin) = gpio_port_pin_validate(pin); | ||
| self.set_pin_direction(tport, tpin, Direction::Input); |
There was a problem hiding this comment.
The data sheet says that the pin must be an input. But we are going to be turning the SP_RESET line back and forth between input and output. The minimal effective procedure needs to be worked out to avoid spurious interrupts when driving SP_RESET and not losing them when detecting SP_RESET.
| // Functions for managing GPIO interrupts: | ||
| // | ||
|
|
||
| fn clear_rising( |
There was a problem hiding this comment.
I'm not a fan of these discrete enable/disable/detect/status calls. Other environments (zephyr, NXP SDK) bundle these together at initial config time or run time.
There was a problem hiding this comment.
I agree. Can we make this part of the config?
| }; | ||
|
|
||
| // XXX for now at least, setting up a PINT pin will set dir to Input | ||
| server.gpio.disable_rising(BUTTON_PINT_MASK); |
There was a problem hiding this comment.
Some of these calls are redundant with the reset state of the PINT peripheral and can be removed.
|
Note: This implementation only implements edge-detection interrupts and ignores level-detection. |
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
| @@ -49,7 +49,7 @@ task-slots = ["sys", "user_leds"] | |||
|
|
|||
| [tasks.net] | |||
| name = "task-net" | |||
| stacksize = 3000 | |||
There was a problem hiding this comment.
Was this strictly necessary or can this be split out into a separate change?
| if pins.iter().any(|p| p.name.is_some()) { | ||
| writeln!(&mut buf, "use drv_lpc55_gpio_api::Pin;")?; | ||
| writeln!(&mut file, "use drv_lpc55_gpio_api::Pin;")?; |
There was a problem hiding this comment.
This doesn't look write, the goal was to write everything into the buf first and then write to the file at the end
| // Functions for managing GPIO interrupts: | ||
| // | ||
|
|
||
| fn clear_rising( |
There was a problem hiding this comment.
I agree. Can we make this part of the config?
| unsafe { | ||
| self.inputmux.pintsel[pint_slot as usize] | ||
| .write(|w| w.bits(pin as u32)); | ||
| } |
There was a problem hiding this comment.
Can we use the intpin API which would let us wrap the unsafe a bit tighter or does that not work with our hubris design?
| fn set_pin_direction(&self, port: usize, pin: usize, dir: Direction) { | ||
| match dir { | ||
| Direction::Input => self.gpio.dirclr[port] | ||
| .write(|w| unsafe { w.dirclrp().bits(1 << pin) }), |
There was a problem hiding this comment.
The unsafe is a quirk of how the lpc55-pac is generated. Adding a safety comment for this is unlikely to be useful.
Pressing the USER button generates an interrupt to the button task.
A single press will increment the RGB pattern.
Quick (~1.5s) successive presses 2nd, 3rd, and subsequent will respecitvely
Minor updates to other app.toml files:
pintandinputmuxperipherals to theirgpio_drivertasks.