solarflare

• 11.18.2016
• Tasks and scheduling

Hi Colin, I am trying to better understand different system run-time scenarios in bare metal with ISRs versus RTOSes. So in a bare metal system, you can have a situation where the system architecture has ISR prioritization (sometimes you can set the prioritization in code, though admittedly sometimes it is also hard-fixed). Typically I have seen applications where there is a main loop that would execute code based on flags that would be set in ISRs. With bare metal, task scheduling is not exactly predictable, but by associating more important (perhaps time-critical in certain instances) code with higher priority interrupts, program flow should generally work in a way such if a less important interrupt flag is set at the same time a higher priority code block should run first. I suppose in the above scenario you could run into a case where a lower priority code block is running in the main loop but a higher priority interrupt flag gets set. Likely the lower priority code would run before the flag for the higher priority interrupt is checked in the main loop. Going back to a previous article on why use an RTOS, would this be one reason an RTOS could be beneficial over bare metal? In this described design scenario, are there other benefits? Of course, these would have to be balanced with the cost/complexity/development time of using an RTOS over bare metal.

• 10.21.2016
• Program structure and real time

Hi Colin, Thanks for writing these articles as I am trying to learn about RTOSes and am finding this to be beneficial. "Most RTOSes simply allow ISRs to “steal” time from the task running at the moment that the interrupt occurs. This, in turn, places the onus on the programmer to keep the ISR code as short as possible." So my question here is based on the quoted text, how is the control of the timing different in bare metal with ISRs, compared to RTOS?