<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://test-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>Problem on combining ADC, GPIO, and BLE</title><link>https://test-devzone.nordicsemi.com/f/nordic-q-a/88795/problem-on-combining-adc-gpio-and-ble</link><description>Hello all! 
 I&amp;#39;m using nRF52-DK to develop program which is controlled by smartphone (BLE) and do ADC&amp;amp;GPIO in the circuit. 
 
 GPIO acts like this: High-Low-High-Low.... it changes its state every 24 us. Let&amp;#39;s say pin number of GPIO is P.20. 
 ADC reads</description><dc:language>en-US</dc:language><generator>Telligent Community 13 Non-Production</generator><lastBuildDate>Mon, 13 Jun 2022 05:36:12 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://test-devzone.nordicsemi.com/f/nordic-q-a/88795/problem-on-combining-adc-gpio-and-ble" /><item><title>RE: Problem on combining ADC, GPIO, and BLE</title><link>https://test-devzone.nordicsemi.com/thread/372003?ContentTypeID=1</link><pubDate>Mon, 13 Jun 2022 05:36:12 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:69647fa6-e3e8-43d6-bba3-fb7a466a163a</guid><dc:creator>user81429</dc:creator><description>&lt;p&gt;Wow Thanks, Thorsrud!!&lt;/p&gt;
&lt;p&gt;I accepted your first suggestion.&lt;/p&gt;
&lt;p&gt;I increased the ADC buffer size, and it was really helpful.&lt;/p&gt;
&lt;p&gt;Also, I increased the connection interval, and it makes perfect operation.&lt;/p&gt;
&lt;p&gt;Thank you again,.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Problem on combining ADC, GPIO, and BLE</title><link>https://test-devzone.nordicsemi.com/thread/371859?ContentTypeID=1</link><pubDate>Fri, 10 Jun 2022 11:36:07 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:5e4ba4e7-1da5-4c9d-aef4-7138e6070b28</guid><dc:creator>user7377</dc:creator><description>&lt;p&gt;Hi,&lt;/p&gt;
&lt;p&gt;As you only see this when BLE is in use I assume this is related to SoftDevice interrupts, which have high priority. You can refer to the SoftDevice specification to see for how long the SoftDevice can block the application (&lt;a href="https://test-devzone.nordicsemi.com/support-private/support/290391/Bluetooth%20Low%20Energy%20processor%20usage%20patterns"&gt;Bluetooth Low Energy processor usage patterns&lt;/a&gt;). If this causes problems then there are several potential ways around it:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;If the SAADC sampling happens for a not too long time, provide a long ADC buffer so that the CPU is only needed to start sampling and process the samples after all samples are collected (I see you already trigger sampling and toggle the GPIOs using a timer and PPI, so that does not involve the CPU).&lt;/li&gt;
&lt;li&gt;If you do not need to do the time critical operations continuously, you could consider doing it in &lt;a href="https://infocenter.nordicsemi.com/topic/sds_s132/SDS/s1xx/concurrent_multiprotocol_tsl_api/concurrent_multiprotocol_tsl_api.html"&gt;timeslots&lt;/a&gt;. During that time, you will not get interrupted by the SoftDevice.&lt;/li&gt;
&lt;/ul&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>