FreeRTOS - Potential issues with Periodic Tasks

Question

Suppose Task 1 has the highest priority of all tasks, and is run periodically using vTaskDelayUntil().

Task 2 has a lower priority, but is also required to run periodically in strict time intervals.

Does this mean that there may be cases when Task 2 isn't always able to execute at the right time, whereas Task 1 will always execute in the correct intervals?

What difference would setting both tasks to the same priority have, if any?

It is my understanding that an RTOS is supposed to execute tasks predictably/deterministically. How can this issue be avoided?

Answer 1

If the intervals are completely asynchronous, then yes, sometimes one task will have to wait for the other.

If the intervals can be synchronized in some way, then arrange the timing such that the second task runs in the gaps between runs of the first task.

Answer 2

You may want to lookup Rate Monotic Scheduling on Wikipedia. If you got 2 hard real-time tasks and want to know for sure they can meet their deadlines (the deadline being their next scheduled period), then the Lui&Layland bound can be a quick guess if it's possible to schedule it. The LL bound puts a limit how many % CPU time your whole real-time program can use.

Note that if LL bound fails, it does not disprove that the program isn't schedudable. There are more bounds available that can be used for a better guess, up to response time estimation which is the most iterative approach.

Note that however most regular RTOS use different schedulers than the theory says. So in that case you really need to make sure the periods are scheduled in a monotonic way, preferably via a timer. Other schedules have different bounds, like EDF scheduling allows the CPU time go up to 100%, while still being able to prove your program can function.

From your post and other comments and doens't sound you're really building a hard-real time system, but these bounds are still nice to take into consideration. Another factor that can help in the robustness of RTOS systems is making sure that:

• Thread-safe; for example your code can deal with preemptions and is reentrant.
• Sufficient buffer space available for e.g. incoming streams or data between processes.
• Keep an eye on interrupts usage and construction. Interrupts are often executed at a kernel permission, and use a different stack. Moreover interrupts can happen at any time, and thus eat up CPU time for any task of your program.

A common design pattern is to do the bare minimum in the interrupt to make sure hardware stays available, and then to signal a RTOS task from the interrupt to process data further at a higher level.