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