<?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>nRF53840 dual M33s timing impacts from BLE events</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/65309/nrf53840-dual-m33s-timing-impacts-from-ble-events</link><description>In a single core BLE SOC, whenever a BLE event occurs the BLE stack takes high priority and any application code running on the single core, is delayed while the event is processed. 
 So has anyone looked at the nRF53840 with the dual cores to evaluate</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Fri, 28 Aug 2020 12:33:11 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/65309/nrf53840-dual-m33s-timing-impacts-from-ble-events" /><item><title>RE: nRF53840 dual M33s timing impacts from BLE events</title><link>https://devzone.nordicsemi.com/thread/267006?ContentTypeID=1</link><pubDate>Fri, 28 Aug 2020 12:33:11 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:737d7b15-3df8-4d1c-ad08-07f64bf389a1</guid><dc:creator>Susheel Nuguru</dc:creator><description>&lt;p&gt;In theory, the BLE activity should not steal any processing time on the host CPU.&amp;nbsp;&lt;/p&gt;
&lt;p&gt;I have not done any benchmarks on this yet, but that was the whole point of having dual core chip with dedicated network core so that the activity on it does not intervene with application core. Hence the timings of the application should be very predictable.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>