Functions to verify if a function/method is viper, asm_thumb or native?

[cve2022]

Question is basically in the title.

Say I pass a callback to be processed at the C level, how can I identify if the object is callable and a Viper, native or asm_thumb function (IOW, not using bytecodes)?

[stinos]

Why would you want to know this? It's a generic function object and it can be called, that's usually all that is needed in C?

[cve2022]

@rkompass , thanks a lot.

I have learned yet another trick, this use of id is a neat one. So many things to learn and only 24h in the day. 😃

It's worth to have a look at the types module.

I certainly will.

Once again, thanks very much.

[cve2022]

On second thought, in my particular case, the distinction between viper, native and asm_thumb is not that important, as long as the callback is in native machine code. In pseudo pseudo code:

if not callable(fn) or mp_byte_code(fn):
    raise TypeError ("OOPS! only native code allowed")
else
    install_the_callback(fn)

My idea is coding this callback to do the very minimum that requires low latency and then schedule a micropython callback that can do more extensive stuff, but may take longer to start if the scheduler queue is crowded.

[rkompass]

If you find some trick to circumvent the python handling of the interrupt, which takes some microseconds, and start the callable code directly (nanoseconds delay) that would be superb.

[robert-hh]

If you replace the ISR for a peripheral with your own function, then some time can be saved. It depends on which peripheral you go for. Eventually the previous ISR could be called after your urgent stuff has been done. Then you can get into few µs response time. Some response time using a callback toggling a PIN after PIN IRQ using the standard IRQ handler:

MIMXRT1170 0.75 µs
Teensy 4.1 1.5µs
RP2 Pico 17µs
ESP32: 20 - 350µs (!)

[cve2022]

If you replace the ISR for a peripheral with your own function, then some time can be saved. It depends on which peripheral you go for. Eventually the previous ISR could be called after your urgent stuff has been done. Then you can get into few µs response time. Some response time using a callback toggling a PIN after PIN IRQ using the standard IRQ handler:

MIMXRT1170 0.75 µs Teensy 4.1 1.5µs RP2 Pico 17µs ESP32: 20 - 350µs (!)

FWIW I am targeting the Timer class. I want to extend it (on RP2 port) to use other alarm interrupt(s). Currently, only the ALARM3 interrupt is being used by the timing subsystem of MP, including Timer objects. The ISR function of the SDK already determines which one of the four ALARM interrupts was triggered, does some housekeeping and calls the handler of the corresponding ALARM.

My understanding is that at the C level I just need to install the handler(s) for other ALARM interrupt(s) that will simply call the respective callback(s). The callback itself (with native machine code) should do the urgent stuff and, if necessary, call micropython.schedule() for other not as urgent tasks.

About the latencies, up to 350us with the ESP32? Wow! 😲 But in fact, it is not as much the latency as the jitter that concerns me.