How deterministic is it for PPI to detect a SPIS rx event and then control GPIOTE?

[neochinese]

I am using a PPI to implement a READY line for my SPI slave.

PPI's EEP is set to my SPI slave's EVENT_END

PPI's TEP is set to my GPIOTE's TASK_SET to deassert my READY_n pin to indicate that I am not ready to receive any packets.

My hardware engineer observed that there is a delay between the SPI master CS's deassertion and READY_n's deassertion. The delay is 380ns. And he'd like to know if PPI is deterministic and the delay is always 380ns as he observed. If so, he would not monitor READY_n line for 380ns after CS's deassertion.

Or would it be worse or how worse could it be?

[Sigurd]

Hi,

The delay is here considered to be highly deterministic, and expected to be around 3 to 4 clock cycles@16MHz in constant latency mode. In Low power mode, there will be some additional delay and generally it might vary depending on the resources required by the peripheral where the task originated. Also keep in mind that the pin load capacitance and GPIO drive(high/low) will affect the GPIO rise/fall time. In total this seems to add up to 130 ns additional delay(4clock@16MHz + 130 = 380 ns). This is very similar to what others have measured.

 

neochinese said:

And he'd like to know if PPI is deterministic and the delay is always 380ns as he observed. If so, he would not monitor READY_n line for 380ns after CS's deassertion.

If it’s important to not miss the CS's/ READY_n's deassertion, it might be advisable to add some overhead/safety-margin to the 380 ns. One additional 16MHz clock tick (62.5 ns), or maybe two, should suffice.