Are PPI events and interrupt connected?

[Mitch996]

How should we comprehend the nature of PPI, when dealing with radio interrupts?

For example, if I point radio event handler call back ( of this type:

static nrf_radio_signal_callback_return_param_t*)

to a radio interrupt event handler function of my own, let's call it radio_event_handler, I can do switch-case on these 4:

NRF_RADIO->EVENTS_END

NRF_RADIO->BCMATCH

NRF_RADIO->READY

NRF_RADIO->ADDRESS

in order to tackle different scenarios.

I'm however curious as is there a connection between generating a radio event/interrupt (on NVIC if I'm not mistaken) and producing a PPI event like NRF_RADIO->EVENTS_END? Are they, for example, synchronized? Completely unrelated (Which is very unlikely)?

[Petter Myhre]

I having trouble understanding what you mean. PPI allows you to connect an event in one peripheral to a task in another peripheral, the event will trigger the task without CPU intervention. If you don't use PPI you usually configure the peripheral to trigger an interrupt when a certain event happens, so that the CPU can react to it, with for example setting a task in another peripheral.

[Mitch996]

Putting my question in a more straightforward way: Does triggering either one of them mean you have to trigger the other?

Or you can trigger just one?

Or normally, triggering one of them has no impact whatsoever on the other?

[Petter Myhre]

An event can trigger an interrupt, it depends on how you have configured the peripheral.

An event can trigger task, it depends on how you have configured the shorts of the peripheral, and the PPI.

I think this is well explained in Section 10 in the nRF51 Series reference manual v3.0.

Please add a comment if there is anything I need to clarify.

[Mitch996]

No need, it's quite clear, depends largely on how I configure it.