<?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>Zephyr interrupt-thread synchronization - improving real time performance</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/119001/zephyr-interrupt-thread-synchronization---improving-real-time-performance</link><description>Hello, 
 
 In an nRF52840, NCS2.7.0 application (based on BT NUS shell) I need to address the following case: 
 
 UART Interrupt handler monitors incoming bytes 
 A working thread (UART message parser &amp;amp; handler) is blocked on a sync object until a full</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Mon, 17 Feb 2025 14:19:39 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/119001/zephyr-interrupt-thread-synchronization---improving-real-time-performance" /><item><title>RE: Zephyr interrupt-thread synchronization - improving real time performance</title><link>https://devzone.nordicsemi.com/thread/523309?ContentTypeID=1</link><pubDate>Mon, 17 Feb 2025 14:19:39 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:8547182d-f966-4a71-90c1-08a3aa3be17a</guid><dc:creator>Edvin</dc:creator><description>&lt;p&gt;Hello,&lt;/p&gt;
&lt;p&gt;You are sure that it isn&amp;#39;t the UART RX time that is taking up the time? In what interrupts do you toggle the GPIO? If you could share some snippets, or perhaps the entire application, then I can have a look.&lt;/p&gt;
&lt;p&gt;&lt;/p&gt;
&lt;p&gt;Best regards,&lt;/p&gt;
&lt;p&gt;Edvin&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Zephyr interrupt-thread synchronization - improving real time performance</title><link>https://devzone.nordicsemi.com/thread/523193?ContentTypeID=1</link><pubDate>Mon, 17 Feb 2025 09:08:53 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:a55d8b26-9c07-491e-962f-9bbd86879e9c</guid><dc:creator>Jakob Ruhe</dc:creator><description>&lt;p&gt;Sounds like a good approach!&amp;nbsp;I assume you use a logic analyzer to capture the output of the pin and to measure the time.&lt;/p&gt;
&lt;p&gt;Probably not exactly related to your problem but one detail that do differ between FreeRTOS and Zephyr are that in Zephyr a low priority value means high priority. You can read about that here:&amp;nbsp;&lt;a href="https://docs.zephyrproject.org/latest/kernel/services/threads/index.html"&gt;Threads &amp;mdash; Zephyr Project Documentation&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;If you add the following to your `prj.conf`:&lt;/p&gt;
&lt;p&gt;&lt;pre class="ui-code" data-mode="text"&gt;CONFIG_THREAD_NAME=y
CONFIG_THREAD_MONITOR=y&lt;/pre&gt;&lt;/p&gt;
&lt;p&gt;You can log all your threads like this:&lt;/p&gt;
&lt;p&gt;&lt;pre class="ui-code" data-mode="c_cpp"&gt;void log_thread_info(const struct k_thread *thread, void *user_data)
{
    k_tid_t tid = (k_tid_t)thread;
    LOG_INF(&amp;quot;Thread: %s (%p), priority: %d&amp;quot;, k_thread_name_get(tid), tid, k_thread_priority_get(tid));
}

k_thread_foreach(log_thread_info, NULL);
&lt;/pre&gt;&lt;/p&gt;
&lt;p&gt;But again, your problem is probably not related to the priorities of the thread, unless you do a lot of work in them. If you can share a minimal application so that others can reproduce your problem it would increase the likelihood of getting help a lot!&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Zephyr interrupt-thread synchronization - improving real time performance</title><link>https://devzone.nordicsemi.com/thread/523149?ContentTypeID=1</link><pubDate>Sun, 16 Feb 2025 21:35:35 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:bf6448b9-c666-4e41-b130-7f780a44e8b4</guid><dc:creator>eyalasko</dc:creator><description>&lt;p&gt;Hey @Jakob,&lt;/p&gt;
&lt;p&gt;&lt;/p&gt;
&lt;p&gt;I measure the latency by toggling&amp;nbsp; a bit when giving the semaphore and when taking (consuming) it&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Zephyr interrupt-thread synchronization - improving real time performance</title><link>https://devzone.nordicsemi.com/thread/523148?ContentTypeID=1</link><pubDate>Sun, 16 Feb 2025 21:19:42 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:1a021a36-7cfb-4370-bb90-68bb9bbd3326</guid><dc:creator>Jakob Ruhe</dc:creator><description>&lt;p&gt;Hi,&lt;/p&gt;
&lt;p&gt;20 ms is a very long time indeed! Regardless if you use k_event, k_sem or workques, you&amp;nbsp;should&amp;nbsp;have a latency magnitudes below that!&lt;/p&gt;
&lt;p&gt;As long as you do it right of course.&amp;nbsp;&lt;/p&gt;
&lt;p&gt;And since you have a latency of 20 ms, something is&amp;nbsp;&lt;span&gt;definitely&lt;/span&gt;&amp;nbsp;not right.&lt;/p&gt;
&lt;p&gt;However. Without any source code it is hard to say what is wrong.&lt;/p&gt;
[quote userid="27169" url="~/f/nordic-q-a/119001/zephyr-interrupt-thread-synchronization---improving-real-time-performance"]The problem I&amp;#39;m facing is a very looong (&amp;gt;20ms !) latency from the time the interrupt asserted the sync object until the thread is unblocked.[/quote]
&lt;p&gt;Are you sure you are measuring the time from when the &amp;quot;interrupt asserted the sync object until the thread is unblocked&amp;quot;?&amp;nbsp;How do you measure this latency?&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>