How to add support for gpio interrupts on rp2040?

[cocasema]

I'm trying to port some code from pico-sdk to modm. The main functionality I'm missing now is interrupts.
I managed to hack it, but I could imagine that's a functionality many other devs would also need to use.

I found a few discussions here about the generic interrupt support and a few attempts to do so.
But maybe I could try to implement something non-generic and pico specific as a stopgap solution?
Something similar to Exti class for stm32?

Please let me know what your thoughts on this is. Or maybe you already have some prototypes / plans for supporting interrupts?

[salkinium]

We don't really have a platform-independent interface for GPIO interrupts yet, due to the differences in hardware, so adding a PICO specific module seems like the way to go.
That gives you the maximum freedom to adapt the implementation close to the hardware.

[cocasema]

Could you please take a look at this prototype and provide your feedback?
cocasema@683baed

[salkinium]

It looks pretty good! Perhaps the double loop inside the IRQ handler could be improved somehow, but the driver is for convenience and if you need speed, you can implement the IRQ yourself.

[cocasema]

Thanks for looking! I tried a few different options for that double-loop function, results are in this commit: cocasema@cf046ce
Seems to work fine in the most cases (except for n4, when 0 bits are set, but that's a very strange scenario - an interrupt callback for no reason).

[salkinium]

Ohhhh, that's awesome, I love benchmark-driven development!

[cocasema]

Is there a way in the build() function of one module.lb get info if some other module is included/enabled in the project's xml file?
In my case, I want to generate some code based on the multicore module being enabled (src/modm/platform/core/rp/multicore.lb).
It seems that I can do this by defining some macro in the multicore and adding #ifdefs in the template code, but I'd rather generate a cleaner file, if this is possible...

[cocasema]

I think I found what I was looking for in the lbuild's rtfm:

    # You can query for options
    if env.has_option("repo:module:option") or env.has_module("repo:module"):
        env.log.info("Module option: '{}'".format(env["repo:module:option"]))

[cocasema]

Implemented in #848