Why is the interrupt queued?

[bittware]

I'm using the pyboard and my interrupt comes in every 3.3ms.
The interrupt source is connected to a GPIO input.

Code: Select all

pin_int.irq(trigger=Pin.IRQ_RISING, handler=tick)

The interrupt service route is plain.

Code: Select all

def tick(int_pin):
  loop_test1.high()
  # blahblahblah
  loop_test1.low()

loop_test1 is a GPIO output connected to an oscilloscope. By watching the loop_test1, interrupt latency and ISR running time can be measured.
But to my surprise, the captured waveform does not align the interrupt event (purple line) to the loop_test1 (yellow line), except for the very first one. The interrupt events seem to be queued and responsed in batch.
How could it be like this?

[bittware]

After a few trials, I found the ISR seems to be scheduled implicitly even though micropython.schedule() is never explicitly called.
This is a little werid. By what standard, this kind of auto schedule is invovled?

[Roberthh]

The IRQ handler schedules the callback. If you use the option hard=True in setting up the Pin.irq, zhen the call is made immediately and not scheduled.

[jim]

The IRQ handler schedules the callback. If you use the option hard=True in setting up the Pin.irq, zhen the call is made immediately and not scheduled.

What is the behavior of pyb.ExtInt(), which doesn't seem to use this option?

[Roberthh]

pyb.Extint() the the old PyBoard only method, which is replaced by machine.pin.irq(). The latter should be available on all ports. AFAIK, pyb.Extint() runs a hard interrupt, but I never tested that.

[pythoncoder]

... AFAIK, pyb.Extint() runs a hard interrupt, but I never tested that.

It does. But as you point out it is effectively obsolete.