<story><title>Embedded Rules of Thumb (2018)</title><url>https://embeddedartistry.com/blog/2018/04/26/embedded-rules-of-thumb/</url></story><parent_chain><item><author>barbegal</author><text>&amp;gt;Keep ISRs small&lt;p&gt;I disagree. If you have interrupt priorities then you can treat your interrupt service routines as the highest priority tasks. As an example lets imagine a drone controller which has two functions it needs to perform in real time: it needs to vary the PWM signal to the motor controller and it needs to acknowledge radio packets. An interrupt is raised when the accelerometer has new data and another is raised when the radio has received a packet. You could write ISRs which just queues the accelerometer data and radio packets so they can be dealt with by a flight control task and a radio task respectively. Alternatively, you could run the whole of the flight controller inside the accelerometer ISR. This reduces copying of data and context switches. Because the accelerometer ISR now takes longer you need to use the radio ISR to acknowledge the radio packets itself. You split the radio task into two tasks: a low priority task for processing commands and the ISR task which does the acknowledgements.&lt;p&gt;&amp;gt; Avoid blocking function calls&lt;p&gt;This can be rewritten as never call functions that block on an action of a lower priority task. It leads to priority inversion in normal tasks and deadlocks in ISRs.</text></item></parent_chain><comment><author>brandmeyer</author><text>Re: ISR priorities.  I agree with you somewhat.  Technology is always changing.  Many architectures don&amp;#x27;t have a rich interrupt controller.  A system built to take advantage of the Cortex-M NVIC will have different characteristics than one that doesn&amp;#x27;t.&lt;p&gt;For those who are unaware, the NVIC effectively turns the interrupt handling system into a hardware-based FIFO strict realtime task scheduler.  The only hard limit is that since all of the tasks are executed on the same stack frame that you need an interrupt stack large enough for the maximum nesting depth.  You can safely do much more work in an interrupt handler with such a system than you can in a classical non-nested interrupt-handling system.</text></comment>
<story><title>Embedded Rules of Thumb (2018)</title><url>https://embeddedartistry.com/blog/2018/04/26/embedded-rules-of-thumb/</url></story><parent_chain><item><author>barbegal</author><text>&amp;gt;Keep ISRs small&lt;p&gt;I disagree. If you have interrupt priorities then you can treat your interrupt service routines as the highest priority tasks. As an example lets imagine a drone controller which has two functions it needs to perform in real time: it needs to vary the PWM signal to the motor controller and it needs to acknowledge radio packets. An interrupt is raised when the accelerometer has new data and another is raised when the radio has received a packet. You could write ISRs which just queues the accelerometer data and radio packets so they can be dealt with by a flight control task and a radio task respectively. Alternatively, you could run the whole of the flight controller inside the accelerometer ISR. This reduces copying of data and context switches. Because the accelerometer ISR now takes longer you need to use the radio ISR to acknowledge the radio packets itself. You split the radio task into two tasks: a low priority task for processing commands and the ISR task which does the acknowledgements.&lt;p&gt;&amp;gt; Avoid blocking function calls&lt;p&gt;This can be rewritten as never call functions that block on an action of a lower priority task. It leads to priority inversion in normal tasks and deadlocks in ISRs.</text></item></parent_chain><comment><author>nsajko</author><text>&amp;gt; I disagree. If you have interrupt priorities then you can treat your interrupt service routines as the highest priority tasks. ...&lt;p&gt;I think &amp;quot;Keep ISRs small&amp;quot; is still a good guideline for most cases. Big interrupt handlers require more system-wide knowledge to verify (e.g., stack space, maximal latency, priority problems, ...). They introduce more coupling into the system, in other words.&lt;p&gt;Of course, this should not be some hard rule, rather just a rule of thumb. I wouldn&amp;#x27;t like it if some policy like this prevented you from choosing the optimal solution in a case like you suggested.</text></comment>