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 > > > > > >
