Handling for Interrupt

RE: Handling for Interrupt

Einar Thorsrud — Thu, 30 Jan 2020 14:39:46 GMT

Hi,

[quote user="tama"]Is it right recognition that "gpiote_event_handler" in the "app_button.c" is enough short in the IRQ handler.[/quote]

I am not entirely sure about the question, but yes. Unless you do something that takes a long time in the event handler, there should not be any problems. Particularly for button presses (which are extremely slow in this context).

[quote user="tama"]Does it mean that there is no interrupt processing in the multiplex and
the second interrupt processing will be in the pending state in the hardware?[/quote]

If another interrupt occurs on a different IRQ number (of same or lower priority), that will be pending and will be serviced once the current interrupt is processed. But you cannot "queue" multiple interrupts for the same IRQ number. That is rarely a practical problem, though.

RE: Handling for Interrupt

tama — Thu, 30 Jan 2020 09:37:13 GMT

Hello,

Thank you very much. I would like to ask about your answer.

>You can lose interrupts if multiple occur very fast (faster than it takes to process the interrupts).

>There is no way around >this issue though, other than making sure that the code executed

> in the IRQ handler is as short as possible (including >event handlers, etc. called from

> it with the same priority).

Is it right recognition that "gpiote_event_handler" in the "app_button.c" is enough short in the IRQ handler.

>After performing the first interrupt processing, is it waited for the next interrupt processing

>to be performed?

>Yes.

Does it mean that there is no interrupt processing in the multiplex and
the second interrupt processing will be in the pending state in the hardware?

Kind Regards,

Manabu Tajima

RE: Handling for Interrupt

Einar Thorsrud — Thu, 30 Jan 2020 08:30:06 GMT

Hi,

[quote user=""]In the processing of "nrfx_gpiote_irq_handler"(modules/nrfx/drivers/src/nrfx_gpiote.c), it seems that interrupts are not disabled during interrupt processing for one pin.[/quote]

The interrupt is not disabled in the ISR, but that would usually not make sense either. However, it is cleared by a call to nrf_gpiote_event_clear().

[quote user=""]In this case, if one pin is interrupted multiple times in a short time, does the callback "gpiote_event_handler"(components/libraries/button/app_button.c) called from
"nrfx_gpiote_irq_handler" work correctly?[/quote]

Yes. You can lose interrupts if multiple occur very fast (faster than it takes to process the interrupts). There is no way around this issue though, other than making sure that the code executed in the IRQ handler is as short as possible (including event handlers, etc. called from it with the same priority).

[quote user=""]After performing the first interrupt processing, is it waited for the next interrupt processing to be performed?[/quote]

Yes.