Hello world! Any RP2040 users feedback is welcome on this change as Kevin tired it and reported some issues :-) Thanks! :-) Tomek
On Tue, Apr 29, 2025 at 2:24 AM Matteo Golin <matteo.go...@gmail.com> wrote: > > 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 > > > > > > > > > > > > > > -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
