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 >
