<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://devzone.nordicsemi.com/cfs-file/__key/system/syndication/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>How deterministic is it for PPI to detect a SPIS rx event and then control GPIOTE?</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/37293/how-deterministic-is-it-for-ppi-to-detect-a-spis-rx-event-and-then-control-gpiote</link><description>I am using a PPI to implement a READY line for my SPI slave. 
 PPI&amp;#39;s EEP is set to my SPI slave&amp;#39;s EVENT_END 
 PPI&amp;#39;s TEP is set to my GPIOTE&amp;#39;s TASK_SET to deassert my READY_n pin to indicate that I am not ready to receive any packets. 
 My hardware engineer</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Mon, 13 Aug 2018 09:00:24 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/37293/how-deterministic-is-it-for-ppi-to-detect-a-spis-rx-event-and-then-control-gpiote" /><item><title>RE: How deterministic is it for PPI to detect a SPIS rx event and then control GPIOTE?</title><link>https://devzone.nordicsemi.com/thread/143882?ContentTypeID=1</link><pubDate>Mon, 13 Aug 2018 09:00:24 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:04c17d74-850b-44eb-90ab-87ff6679ab43</guid><dc:creator>Sigurd</dc:creator><description>&lt;p&gt;Hi,&lt;/p&gt;
&lt;p&gt;The delay is here considered to be highly deterministic, and expected to be around 3 to 4 clock cycles@16MHz in &lt;a href="https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52832.ps.v1.1/power.html?cp=2_1_0_17_2_0#unique_406845269"&gt;constant latency mode&lt;/a&gt;. 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 &lt;a href="https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52832.ps.v1.1/gpio.html?cp=2_1_0_19_3_0#unique_1511470077"&gt;GPIO rise/fall time&lt;/a&gt;. 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.&lt;/p&gt;
&lt;p&gt;&amp;nbsp;&lt;/p&gt;
[quote userid="62614" url="~/f/nordic-q-a/37293/how-deterministic-is-it-for-ppi-to-detect-a-spis-rx-event-and-then-control-gpiote"]And he&amp;#39;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&amp;#39;s deassertion.[/quote]
&lt;p&gt;If&amp;nbsp;it’s important to not miss the CS&amp;#39;s/ READY_n&amp;#39;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.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>