Long interrupt response time in example project for NRF52840, "pin_change_int_pca10056"

[nicsam1992]

Hello,

I'm trying out the example code "pin_change_int_pca10056". But the delay time between sensing a voltage change and toggling the output GPIO is quite long. 22us. Is there any way to make the ISR faster? 

In the picture below, yellow is the sensed voltage and blue is the toggled GPIO in the ISR. I'm using this code on the pca10056 board.

 

[Susheel Nuguru]

If you need lower latencies on the trigger of your interrupt handler, then you need to bypass the whole Zephyr driver handling of you interrupt. Since it takes a longer path from the vector table to the zephyr driver handler which in turn call your interrupt callbacks after some post processing. For the application, this post processing of the interrupt before the driver interrupt handler call the application handler might be sometimes too much.

Try using IRQ_DIRECT_CONNECT to put the address of your interrupt handler directly into the vector table so that the redirections are avoided.

The discussion in this thread might help understand this better..

[nicsam1992]

Is there any other way except using interrupt that I can react fast on a signal?

[Susheel Nuguru]

Just realized that this example is in our old nRF5SDK and not in the newer nRF Connect SDK.

I see that this pin_change_int example uses nrf_gpiote driver and your pin toggle most likely is happening in the callback and not the isr itself. If you want your application to have less latency before its callback is called, then it is best not to use the driver and implement your own ISR for gpiote irq.