ISR speed query

[czarnikjak]

I am working on a piece of code where interrupts are triggered very frequently and its essential for the ISR handler to complete as quickly as possible.

Searching through internets, there is some measurements that Pico takes around 60us (ballpark figure) to respond and enter into ISR, and each Micropython "statement" takes around 10us to execute (on average, obviously it would vary by statement... btw what is considered a statement in Python? A line of code?)

With the above in mind, completing ISR handler with 10 statements should take around 160us (60+ 10x10)

My question is, is it permitted (and does it have any effect) to decorate ISR handler with @micropython.native or viper to speed up the execution?

[peterhinch]

When you specify handler=callback to Pin.irq() you are passing a reference to a function: this should work regardless of whether the function is implemented as bytecode, native code, or Viper optimised. Remember to use hard=True.

Rather than rely on estimates, you could measure the speed of your ISR with time.ticks_us() and time.ticks_diff().

[czarnikjak]

Thanks Peter, i thought it should work, just wanted to verify with someone who knows what they are talking about.

Regarding statement execution time, quick question, if I have a branch that is not taken, like below,

if foo == 1:
    print('Do this statements')
    print('in not taken branch')
    print('also take some interpreters time to skip through them?')
else:
    print('Or no time is wasted on above print statements at all?')

Sorry, what is hard=True? I don't recall coming across it.

[jimmo]

Sorry, what is hard=True? I don't recall coming across it.

See docs for e.g. Pin.irq https://docs.micropython.org/en/latest/library/machine.Pin.html#machine.Pin.irq and the linked document about writing interrupt handlers.

Not all ports support both hard=True and hard=False (i.e. "soft"). e.g. ESP32 only supports soft. rp2040 supports both. Hard interrupts run in the CPU's interrupt context and execute immediately (pre-empting running code). Soft interrupts are scheduled for later execution.

and each Micropython "statement" takes around 10us to execute (on average, obviously it would vary by statement... btw what is considered a statement in Python? A line of code?)

Time per line or statement is not a useful estimate of how long a function will take to execute. (e.g. a single line could be a list comprehension over thousands of elements, or it could be simply incrementing a number). Even individual bytecode instructions can take different amount of time. The only meaningful thing you can do is measure your function (e.g. using time.ticks_diff).

A line can contain multiple statements (e.g. separated by semicolons).

Regarding statement execution time, quick question, if I have a branch that is not taken, like below,

Not sure what your question is here :)

If the branch isn't taken, then no, the non-executed lines do not count. (MicroPython is not an "interpreter" in the strict sense of that word, it executes bytecode, the if statement will cause a jump).

[czarnikjak]

Thanks for your detailed response.
I did realise after doing some reading that Python actually compiles the code, therefore no runtime will be wasted on interpreting lines of not taken branch.

I should have mentioned that my interrupts are generated by PIO state machine not by Pin, therefore I don't think hard=True applies to me.

[robert-hh]

The hard keyword option is available as well for PIO interrupts.

[robert-hh]

In my tests of the RPI Pico, responding to a Pin.irq took ~26µ for a hard interrupt and ~34µ for a scheduled interrupt. The time to run a statement varies a lot. So saying it takes 10µs in average may not be a good estimation. You have to look at the code in question. And code execution speed can be improved a lot.

[peterhinch]

~34µ for a scheduled interrupt.

This is highly variable. If the interrupt happens to occur when a GC is in progress latency could be a few ms (on the Pico).

[robert-hh]

That's true. With hard=false and a test code that allocates memory, the largest response time I have seen is 2.87 ms, with 90% being at ~46µs. A fresh screen shot below.

[robert-hh]

Max now at 7 ms.

[shariltumin]

Hi Robert, if it is convenient, could you share your test code with us?

[rkompass]

Hi Sharil,

we have such code reoccurring every now and then :-) It's an interesting topic.

Last time e.g. here.

[shariltumin]

Thanks Raul, I'll read the thread and learn from it.

[robert-hh]

Hi Robert, if it is convenient, could you share your test code with us?

Sure. The code is dead simple. It just sets up the IRQ with the handler and a PWM for creating the trigger pulse. The delay is measured with an oscilloscope. But you can as well use a simple logic analyzer for that purpose.

from machine import Pin, PWM
from time import sleep_ms
# Link 12 to 13, time 13 to 15
pin15 = Pin(15, Pin.OUT)

def callback(_):
    global pin15
    pin15(1)  # Trigger
    pin15(0)

pin12 = Pin(12, Pin.IN)
_ = pin12.irq(callback, trigger=Pin.IRQ_RISING, hard=True)

pwm = PWM(Pin(13))
pwm.freq(1000)
pwm.duty_u16(30)

while True:
    sleep_ms(10)

And this is a fresh screenshot from the oscilloscope. The yellow track is the trigger pulse, the green the response by the IRQ handler. The average delay shown is 16.8 µs. Actually it is less since what you see is already the result of the first statement in the ISR. And you can see that a call to p15(x) takes about 3.3 µs.

[shariltumin]

Thanks Robert, very informative.

[robert-hh]

Letting the test run some longer time and increasing the time window, I've seen a single delay of 7ms using a hard=False set-up and a test loop which allocates memory and thus forces garbage collection to run sometimes.