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
