<?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 to use PPI for reading data from ADC</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/123551/how-to-use-ppi-for-reading-data-from-adc</link><description>Hello 
 I need help, I have a problem implementing ppi gpiote and spim. The ADC I use is mcp3562 which sends via the irq pin when the data is ready. I need to work in continuous mode at almost 100khz data sample rate. Is it smart to use that pin as gpiote</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Sun, 10 Aug 2025 17:06:05 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/123551/how-to-use-ppi-for-reading-data-from-adc" /><item><title>RE: How to use PPI for reading data from ADC</title><link>https://devzone.nordicsemi.com/thread/545111?ContentTypeID=1</link><pubDate>Sun, 10 Aug 2025 17:06:05 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:2a428b27-71f1-4d02-9277-78541330e1e5</guid><dc:creator>Kenneth</dc:creator><description>&lt;p&gt;Hi,&lt;/p&gt;
&lt;p&gt;I am not sure there are any&amp;nbsp;good examples that do what you want no, so I guess you just have to look at potential existing nrfx and nrfxpiote examples and try to use them as reference on how to do it. The description you provide seems to be correct, so if you have any faults you may need to check you have connected tasks and events correctly, and you don&amp;#39;t use any ppi channels that are not already in use by other code. If you have an nRF52840 DK you should be able to debug and narrow down the fault.&lt;/p&gt;
&lt;p&gt;I highly recommend that you buffer up data to fill an entire radio payload before you send the data, since it&amp;#39;s much more efficient to send several tens of byte rather than a few bytes. Overall this will also improve quality since it can allow some retransmissions and quality of service. But I guess it&amp;#39;s up to you what is most important: some latency but less packet loss, or shorter latency but allow more packet loss.&lt;/p&gt;
&lt;p&gt;Kenneth&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>