<?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>Scheduler benefits</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/6261/scheduler-benefits</link><description>Hi,
I&amp;#39;m doing some throughput/current consumption tests with nRF51822 (on PCA10001).
My firmware has been developed starting from hrm example. I have created a custom service for sending 20byte with notification (many have already done the same, I know</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Mon, 30 Mar 2015 10:48:34 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/6261/scheduler-benefits" /><item><title>RE: Scheduler benefits</title><link>https://devzone.nordicsemi.com/thread/21893?ContentTypeID=1</link><pubDate>Mon, 30 Mar 2015 10:48:34 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:dbba0aff-3ec1-497f-9897-5e8cae3419de</guid><dc:creator>Davide</dc:creator><description>&lt;p&gt;Very clear, thanks!
After adding scheduler to my project I can clearly see more stable timings in current consumption and also some current peaks are a little bit reduced!&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Scheduler benefits</title><link>https://devzone.nordicsemi.com/thread/21892?ContentTypeID=1</link><pubDate>Mon, 30 Mar 2015 10:11:38 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:40d3b8cb-41ad-4b33-a5cb-249f28f47664</guid><dc:creator>Stefan Birnir Sverrisson</dc:creator><description>&lt;p&gt;Hi Davide&lt;/p&gt;
&lt;p&gt;Yes, you are correct, the purpose of using the scheduler is to have your code execute in the main context, which is the lowest priority. The motivation for executing code in the lowest priority is to not let your code execution block other tasks that need to run with minimum latency. When you i.e. get a callback from the softdevice which has ARM priority 3, execution of that callback handler will block other softdevice callbacks. It is therefore a good practice to call the scheduler instead of executing a long task in the callback handler.  An introduction how the priorities work is given on these threads &lt;a href="https://devzone.nordicsemi.com/question/23542/nrf51822s-original-interrupt-priority/"&gt;(1)&lt;/a&gt; &lt;a href="https://devzone.nordicsemi.com/question/32040/using-i2c-nus-and-two-timer-interrupts-reading-sensor-from-both-timer-interrupts/?answer=32422#post-id-32422"&gt;(2)&lt;/a&gt;.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>