<?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>SPIM xfer delay</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/114516/spim-xfer-delay</link><description>Hi, 
 I&amp;#39;m using nRFConnect 2.6.1 SDK on a nRF52833 with the speed build optimization. 
 I got two peripherals on the same SPI which is SPIM3. It is configured at 32MHz and the 2 CS are controlled through PPI. 
 The first peripheral sends a DataReady </description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Fri, 06 Sep 2024 13:29:28 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/114516/spim-xfer-delay" /><item><title>RE: SPIM xfer delay</title><link>https://devzone.nordicsemi.com/thread/501559?ContentTypeID=1</link><pubDate>Fri, 06 Sep 2024 13:29:28 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:b160cbd7-4d27-43d2-bf09-28dc619001a8</guid><dc:creator>QuentinCisteme</dc:creator><description>&lt;p&gt;Hello,&lt;/p&gt;
&lt;p&gt;I tried this solution before but it didn&amp;#39;t knew about this event test so the two SPI were colliding.&lt;/p&gt;
&lt;p&gt;It works great, the delay between the two transmissions is reduced from 16 to 5us, thank you so much.&lt;/p&gt;
&lt;p&gt;In my first program the first transfer was triggered by PPI and i had the same problem of collision. I will try with this test, to see the maximum frequency of the system.&lt;/p&gt;
&lt;p&gt;Thank you so much,&lt;/p&gt;
&lt;p&gt;Quentin.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: SPIM xfer delay</title><link>https://devzone.nordicsemi.com/thread/501547?ContentTypeID=1</link><pubDate>Fri, 06 Sep 2024 12:50:06 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:a072edd1-f120-4706-a001-e16b97c8be36</guid><dc:creator>Vidar Berg</dc:creator><description>&lt;p&gt;Hello,&lt;/p&gt;
&lt;p&gt;The delay likely results from the time required to reach the spim_handler ISR (including interrupt latency and the processing of the interrupt handling code), as well as the configuration of the next transfer within the ISR. The transfer itself is performed without CPU involvement.&lt;/p&gt;
&lt;p&gt;If this is really timing critical, you may be able to reduce the delay by starting setting up the subsequent transfer from the trigger_handler() ISR.&lt;/p&gt;
&lt;p&gt;&lt;pre class="ui-code" data-mode="c_cpp"&gt;void trigger_handler(..)&amp;#160;
{
    nrfx_spim_tranfer(&amp;amp;spim_adc, &amp;amp;xfer_adc, NRFX_SPIM_FLAG_NO_XFER_EVT_HANDLER);

    while (!nrf_spim_event_check(&amp;amp;spim_adc, NRF_SPIM_EVENT_END))
    {}

    nrfx_spim_tranfer(&amp;amp;spim_adc, &amp;amp;xfer_ram, NRFX_SPIM_FLAG_NO_XFER_EVT_HANDLER);
}&lt;/pre&gt;&lt;/p&gt;
&lt;p&gt;Best regards,&lt;/p&gt;
&lt;p&gt;Vidar&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>