Of course, "one interrupt" here just means "one hardware interrupt vector" - each pin has independent interrupt status, so nothing to stop you having shared interrupt handlers to take interrupts on any combination of GPIOs, just that they have to separate them in software.
If the reason for wanting two vectors is to allow the handler for one GPIO to have higher priority and be able to preempt the handler for another GPIO that runs for a long time, you can emulate that at relatively low cost using the spare IRQs 26-31: the single GPIO vector would point at a handler that simply clears the interrupt status and makes pending the appropriate one of the spare IRQs (which can each then have a dedicated handler). In practice, you'd probably put the logic for servicing the highest-priority GPIO into the main handler and only post to a spare IRQ for the lower priority ones. Also note that CortexM0 only has 4 priority levels, so you can only have that many levels of IRQ preemption.
If the reason for wanting two vectors is to allow the handler for one GPIO to have higher priority and be able to preempt the handler for another GPIO that runs for a long time, you can emulate that at relatively low cost using the spare IRQs 26-31: the single GPIO vector would point at a handler that simply clears the interrupt status and makes pending the appropriate one of the spare IRQs (which can each then have a dedicated handler). In practice, you'd probably put the logic for servicing the highest-priority GPIO into the main handler and only post to a spare IRQ for the lower priority ones. Also note that CortexM0 only has 4 priority levels, so you can only have that many levels of IRQ preemption.
Statistics: Posted by arg001 — Sat Oct 19, 2024 8:23 am