Sustainable IRQ rate on Pi Pico

[gmrza]

I am looking at using an ISR for the first time with Micropython to read a Hall Effect flow sensor using a Pi Pico. One thing I wanted to check is what is a reasonable expectation in terms of sustained rate of interrupts which can be handled comfortably.
I don't expect to see anything higher than 50 interrupts per second at peak. The ISR will only increment a counter.
What I also want to try to do is to get the ISR to run on Core 1, leaving Core 0 to do data logging via the WLAN.

[robert-hh]

50Hz is no problem at all. Attached you see a timing diagram taken with a Pico at standard CPU clock of a timer interrupt running at 10kHz, where the callback just toggles a Pin. Toggling a Pin takes much longer than incrementing a counter. Using threading, you can run the ISR in one core and other code in the other core, but may not even that is needed.

[gmrza]

Thanks very much. One thing that isn't entirely clear to me is how I make sure that the ISR runs on a specific core. If I set up the ISR from a thread that is running on core 1, will that ensure that the ISR also runs on core 1?

[robert-hh]

I’m not sure. There was a discussion about it in either the forum or the repository. Either the result was, that interrupts are always executed in thread 0 and it stayed l8ke that, or it was considered as something that could be fixed and eventually was fixed.

[jimmo]

I just read the code for this... the way it's supposed to work on rp2 is that the IRQ is executed on the core that registers the IRQ handler.

However, the MicroPython GPIO driver for rp2 doesn't do this correctly -- if you try and register the IRQ handler on the second core you will never receive IRQs.

So @gmrza, for now, the answer is that IRQs run on the core that called pin.irq() to register it, but also that must be core 0.

Note that this only applies to "hard" IRQs (the default is "soft"). If you register a soft IRQ (again, you must do this from core 0), then the soft handler could be scheduled on either thread. (There's some context here, most recently in #8845, #8838, #8869. I think we need to make it possible to have per-thread scheduling... i.e. three options when scheduling: run-on-current, run-on-any, run-on-specific).

Edit: raised #9124

[gmrza]

Thanks @jimmo for checking that! I suspect you have saved me a lot of pain! So the answer, for now, is not to try to be fancy.