Hello everyone, In order to solve this issue, I have opened a PR here: https://github.com/apache/nuttx/pull/16281
This allows multiple GPIO interrupt types to be selected once, since the RP2040 supports that. Now one GPIO pin can trigger up to 4 interrupt events. I would appreciate your review! Matteo On Tue, Mar 18, 2025 at 4:36 PM Kevin Witteveen <kevinwit1...@gmail.com> wrote: > Hey Matteo, > > It appears the RP2040 can support falling and rising interrupts at once > according to the RP2040 datasheet section 2.19.5.2 "Enable a GPIO > interrupt", which provides an example of how to do this. > Ofcourse this example is not NuttX, but can help for implementation. > https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.pdf > > Maybe this can help you find a solution. > > Best regards, > > Kevin > > > Op di 18 mrt 2025 om 21:25 schreef Alan C. Assis <acas...@gmail.com>: > > > Hi Matteo, > > > > I think RP2040 and new RP2350 are good MCUs, but Raspberry Pi Foundation > > did some terribles mistakes, like using a serial port control that > doesn't > > have indication of transmission done (useful for RS485 support) and GPIO > > INT with both edges support. > > > > When I created the ultrasound sensor driver (drivers/sensors/hc_sr04.c) I > > already considered that some "cheap" MCU will not have support for both > > edge detection, so initially I detect the raising signal and when that > > interrupt happens I change the GPIO to detect falling edge. Look at > > hcsr04_start_measuring() and hcsr04_int_handler(). > > > > BR, > > > > Alan > > > > On Tue, Mar 18, 2025 at 5:07 PM Matteo Golin <matteo.go...@gmail.com> > > wrote: > > > > > Thank you everyone for the suggestions. > > > > > > I don't have enough GPIO pins to dedicate two per switch unfortunately, > > nor > > > do I have a suitable hardware method for handling debouncing. I suppose > > > this is taken care of in the button driver framework via software, but > > not > > > for the bare GPIO framework. I don't believe the button framework will > > work > > > for this application because the switches are toggle switches, not > > buttons. > > > > > > I like Marco's solution of switching the interrupt type on the toggle, > > but > > > I am fearful of the race conditions you mentioned, Nathan. I suppose I > > > could take the interrupt type toggling approach but read the > interrupted > > > pin in software with a delay to ensure the correct value, which would > > > remedy the debouncing issue? I believe this can be done from > application > > > code at least. That still leaves the issue of the interrupt type not > > being > > > toggled in time for the next edge, which could miss an input. I was > > hoping > > > there would be a method to attach both a rising and falling edge > > interrupt > > > handler to the GPIO pin simultaneously but it appears the current > RP2040 > > > support doesn't allow that, although the chip itself does. Maybe that > > would > > > be a feature worth adding? > > > > > > Thanks again for the suggestions, I'll have to do some thinking but > maybe > > > the polling approach is the safest bet. > > > > > > Matteo > > > > > > On Tue, Mar 18, 2025 at 8:23 AM Nathan Hartman < > hartman.nat...@gmail.com > > > > > > wrote: > > > > > > > On Mon, Mar 17, 2025 at 5:18 PM Matteo Golin <matteo.go...@gmail.com > > > > > > wrote: > > > > > > > > > Hello everyone, > > > > > > > > > > I have an application wherein I am using a W5500-EVB Pico as the > MCU > > > for > > > > a > > > > > network controlled system. I need to connect > > > > > several switch inputs into this MCU. The switches are normally held > > > high > > > > > via the RP2040's internal pullups, and pulled > > > > > low when flipped. > > > > > > > > > > > > > > > > By switch inputs, do you mean physical switches, like toggle > switches? > > If > > > > so, then I hope you're handling switch debouncing somehow, either by > > > > software (multiple consecutive identical readings, spaced apart by > some > > > > constant time interval, must occur before reacting to the change in > > > switch > > > > state) or by hardware (at the very least a RC network with a schmitt > > > > trigger). Otherwise, if you interrupt on rising and falling edges, > > you'll > > > > likely see spurious interrupts and unwanted state changes. > > > > > > > > > > > > The problem I'm encountering is that it appears that the current > RP2040 > > > > > support only allows for one type of interrupt > > > > > per pin: either rising edge or falling edge. I need to trigger on > > both > > > > > rising and falling edge to accurately track the > > > > > state of the switch. I'm wondering if anyone else has had a similar > > > issue > > > > > or has suggestions about how I can resolve > > > > > this. > > > > > > > > > > > > > > > > Assuming that switch bounce is either handled or is not an issue (see > > > > above), you could either use 2 IO pins as suggested by William or > > > > reconfigure the interrupt edge as suggested by Marco. > > > > > > > > If you use Marco's idea, you must handle two issues that will cause > > > > problems if left unhandled: > > > > > > > > 1) You must determine the correct initial edge to configure, and > > > > > > > > 2) You must handle race conditions between changes in the hardware IO > > > state > > > > and reconfiguration of the interrupt edge, i.e., a scenario like: > > > > > > > > a) rising edge interrupt occurs > > > > b) some small amount of time passes > > > > c) interrupt handler runs > > > > d) in interrupt handler, you reconfigure to interrupt on falling edge > > > > > > > > but somewhere between a and d, falling edge already occurred, so > > falling > > > > edge interrupt will be missed. > > > > > > > > That's not the only scenario that could go wrong.,You have to ensure > > that > > > > all possible race conditions are handled in a reliable way or this > will > > > be > > > > a repeated source of headaches. > > > > > > > > For reasons like this, I prefer a timer-based polling and software > > > > debouncing for switches, but YMMV. > > > > > > > > Hope this helps, > > > > Nathan > > > > > > > > > >
