GPIO in the kernel: an introduction [LWN.net]

GPIO in the kernel: an introduction

Posted Dec 13, 2016 14:20 UTC (Tue) by bla (guest, #112986)
In reply to: GPIO in the kernel: an introduction by nybble41
Parent article: GPIO in the kernel: an introduction

Anything speaking against using gpio_get_value in the isr to discern between rising and falling?

to post comments

GPIO in the kernel: an introduction

Posted Dec 13, 2016 14:56 UTC (Tue) by nybble41 (subscriber, #55106) [Link] (7 responses)

> Anything speaking against using gpio_get_value in the isr to discern between rising and falling?

The ISR will only run on the rising edge _or_ the falling edge, not both, so gpio_get_value will generally return a known result: either high for a rising-edge-triggered interrupt, or low for falling-edge.

GPIO in the kernel: an introduction

Posted Dec 13, 2016 16:46 UTC (Tue) by bla (guest, #112986) [Link] (6 responses)

Why wouldn't IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING with request_irq work?

GPIO in the kernel: an introduction

Posted Dec 13, 2016 18:28 UTC (Tue) by nybble41 (subscriber, #55106) [Link] (5 responses)

> Why wouldn't IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING with request_irq work?

Things may be different on ARM or x86, but in my work on embedded PowerPC targets I have yet to see an interrupt controller than can be configured to trigger on both rising and falling edges for the same signal. Typically there are four possible trigger modes, of which only one can be active at a time: rising edge, falling edge, high level, or low level.

GPIO in the kernel: an introduction

Posted Dec 13, 2016 19:11 UTC (Tue) by bla (guest, #112986) [Link]

Ah, probably a gpio-controller/IRQ line limitation. I'll check if it works on a Raspberry (should, as Wiring has a BOTH option).

GPIO in the kernel: an introduction

Posted Dec 15, 2016 11:07 UTC (Thu) by bla (guest, #112986) [Link] (3 responses)

Ok, you c a n set a combined interrupt mask and query the pin state in the ISR on an RPi, but gpio_get_value seems to have latency, which makes this approach pretty much useless in conjunction with switch bounce and the ISR time constraints.
For implementing long button presses, detecting the first flank and reading the level with a thread after some delay seems to be the better approach, it also doesn't require a state change to trigger the long press signal.

GPIO in the kernel: an introduction

Posted Dec 15, 2016 20:05 UTC (Thu) by BlueLightning (subscriber, #38978) [Link] (2 responses)

Surely the answer to switch bounce is to do the debouncing in hardware?

GPIO in the kernel: an introduction

Posted Dec 15, 2016 20:32 UTC (Thu) by pizza (subscriber, #46) [Link] (1 responses)

But hardware debounce would require adding extra $0.02 worth of components and growing your board size by 2 square millimeters.

Why spent that money on every unit when it can be done once, "for free" in software?

GPIO in the kernel: an introduction

Posted Dec 17, 2016 6:44 UTC (Sat) by flussence (guest, #85566) [Link]

Fun trivia: this is exactly what the NES Classic does. In their GPL code dump there's a kernel driver for the controller - it has the same wire protocol the Wiimote uses (internally!), but leaves the kernel to deal with all that hardware-related insanity and more.