This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

How in nrfx_gpiote_irq_handler() Interrupts among different GPIO's are processed?

nrfx_gpiote_irq_handler() which is nearly 150 lines of code. All the GPIOs seems to have same priority at the hardware level, how among different GPIO's Interrupts are processed ?  The interrupt handler pin events are being checked one by one, this would also prolong the interrupt service time. Can we tweek the code according to our applications , not as polling method but on first come first serve basis of Interrupts raised?

  • Hello,

    All the GPIOs seems to have same priority at the hardware level, how among different GPIO's Interrupts are processed ?

    I am not sure I understand what you are asking here.
    Are you using GPIOTE low-accuracy PORT events, or do you intend to use high-accuracy GPIOTE IN_EVENTs?
    When you are using PORT events you will need to iterate through all the pins either way, because the PORT event does not designate which pin that triggered the event. In the case of a button press this is no problem at all, since the button will remain pressed for a very long time. However, if you are trying to catch a very fast pulse, then the PORT event might fall short.

    Can we tweek the code according to our applications , not as polling method but on first come first serve basis of Interrupts raised?

    You may tweak or modify the SDK code as you would like, but we can not guarantee that your implementation or modifications will not break other functionality of the driver. As mentioned above, there is no notion of "first come first serve" when using PORT event, since the pin responsible for the interrupt is not part of the event - the driver needs to iterate through the possible pins, to find which one triggered the event.
    If you would like you can also access the GPIOTE Hardware Layer ( HAL ) directly, to create you own driver - but I would advise you to use the drivers we have provided, since they are thoroughly tested and close to optimal ( if not actually optimal ) for most use-cases.

    Best regards,
    Karl

Related