[BY DESIGN] Slow response to external ISR when using AttachInterrupt

[buaus]

Hi,
I tried today the attachInterrupt function and I saw that this slow approx 5 to 10usec. Is there any chance to speed up to approx 200nsec?
buaus

[Pito]

How did you measure the 5-10us interrupt latency?

[victor_pv]

Is that the latency you measure between driving a pin to a certain level and your function being called? that seems like a lot.
There is some overhead because the interrupt will not call your function right away, instead it calls a function in the core, that keeps a table of what functions to call for each interrupt, and that's going to call yours, but but still 10uS are 720 cpu cycles, seems a bit too much.

[peekay123]

Well, kind of. For external interrupts that share a common IRQ (exti9_5 and exti15_10), the firmware will scan each of the interrupt pending bits (of the shared IRQ register) and, if defined, call the ISR pointed to in the vector table. If multiple ISRs fire at the same time or the interrupt pending bit is sampled later in the sampling loop then there will be delays in calling that specific ISR (scanning delay + time to service other ISR). This may or may not explain the 5us to 10us latency in your situation.

Take a look at exti.c and ext_interrupts.cpp.

[buaus]

Mandy thanks for the many helpfull comments.
I used to measure the time a routine which was setting directly a Port Pin after receiving the Interrupt.
I saw in meantime also within an other thread this topic, which confirm "weakness" of the attachInterrupt function, so I set up today in IAR workbench a C_Project. Finally I reach now approx 470ns.
buaus

[RogerClark]

The Arduino API is not written to be fast, so if you want quick response times, you would need to do more low level programming.

That being said, I'm surprised that the response time is as slow as you mentioned.

You didn't describe exactly how you tested this

I presume you must have an external signal generator, creating the pulses get the ISR code to set a GPIO pin and connect both the input pin and the GPIO to a logic analyser to measure the time delay

Presumably you have factored in the time to set the GPIO bit by using digitalWrite - which in its self is not that fast, or did you directly set the BSSR register after pre-defining the device and the pin data in your global setup ?

[RogerClark]

I looked at how this operates and I'm not surprised its slow

Take a look at

https://github.com/rogerclarkmelbourne/ ... #L273-L292

But I presume LeafLabs had a reason to do it that way, rather than simply using a lookup table

[victor_pv]

I looked at how this operates and I'm not surprised its slow

Take a look at

https://github.com/rogerclarkmelbourne/ ... #L273-L292

But I presume LeafLabs had a reason to do it that way, rather than simply using a lookup table

I believe that's for the lines that share 1 interrupt vector for several lines.

[RogerClark]

Victor.

Yes. Thats the worst case.

There do some to be some possibilities for optimisation, depending if the compiler has already done the optimisation...

If all the handlers were initially set to go to a dummy function, there would be no need to check whether the handler was valid

This would save 1 "if" function, and "if"s seem to be where ARM code gets slowed down

[Pito]

FYI:
http://stm32duinoforum.com/forum/viewtopic.php?f=18&t=2501