Pin interrupt polarity timing issue

RE: Pin interrupt polarity timing issue

Daniel Dakhno — Thu, 06 Aug 2020 19:57:14 GMT

had to patch the following:

nrf_drv_gpiote.c line 758:

handler(pin, polarity);

replaced with

handler(pin, (sense == NRF_GPIO_PIN_SENSE_HIGH) ? NRF_GPIOTE_POLARITY_LOTOHI : NRF_GPIOTE_POLARITY_HITOLO);

RE: Pin interrupt polarity timing issue

Dmitry — Wed, 05 Aug 2020 11:25:20 GMT

You're right.. I agree, API design is weird. You can tweak nrfx_gpiote.c interrupt handler to return sense value instead of polarity. From other side, in low-accuracy mode you should not loose any event - each next event will signal an opposite value.

RE: Pin interrupt polarity timing issue

Daniel Dakhno — Wed, 05 Aug 2020 10:10:13 GMT

AFAIK my callback only gets passed NRF_GPIOTE_POLARITY_TOGGLE, which is neither value...

RE: Pin interrupt polarity timing issue

Dmitry — Wed, 05 Aug 2020 10:08:38 GMT

In low-accuracy mode, your callback will be called with right value.

RE: Pin interrupt polarity timing issue

Daniel Dakhno — Wed, 05 Aug 2020 10:06:06 GMT

and how do i get that value? using gpio_read only gives me the value at runtime of the handler.

So, how do i get that value at the time of the interrupt?

RE: Pin interrupt polarity timing issue

Dmitry — Wed, 05 Aug 2020 10:04:10 GMT

With millisecond resolution, you can use low-accuracy mode. In this mode, toggle is emulated by library - it changes sense level every time an event is coming, and you'll get exactly the value that pin has at the time of an event.

RE: Pin interrupt polarity timing issue

Daniel Dakhno — Wed, 05 Aug 2020 08:46:07 GMT

I am not too worried about timing, I can live with a few milliseconds of delay.

I am worried about the useless polaritiy passed to my interrupt handler.

Is there any way to get the precise direction with a TOGGLE-interrupt handler?

RE: Pin interrupt polarity timing issue

Dmitry — Wed, 05 Aug 2020 08:24:22 GMT

Hi Daniel,

do you use hi-accuracy mode for gpiote?

The nrfx_gpiote driver is not optimized for very time-critical tasks, you can look at nrfx_gpiote_irq_handler in nrfx_gpiote.c to see the size of code it runs when interrupt is detected. Using gpiote peripheral directly (without nrfx layer), you can write much shorter code that only checks signal level on a single pin and clears interrupt status. Another thing - when BLE stack is enabled, you cannot ensure time constraints because softdevice interrupts always have higher priority, and if an input signal changes multiple times while gpiote interrupt is blocked, you'll receive only one event.

If you need very precise timings, the best way is to pass an event to a timer or rtc via PPI to capture an exact timestamp by hardware.