0
\$\begingroup\$

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?

\$\endgroup\$
5
  • \$\begingroup\$ make Task2 the top priority task \$\endgroup\$
    – jsotola
    Apr 23, 2018 at 0:16
  • \$\begingroup\$ @jsotola, but then Task 1 potentially misses time intervals. \$\endgroup\$
    – M-R
    Apr 23, 2018 at 0:57
  • \$\begingroup\$ you left out information ... you said that Task2 must run in strict time intervals ... no such statement was made about Task1 \$\endgroup\$
    – jsotola
    Apr 23, 2018 at 1:21
  • \$\begingroup\$ @jsotola, sorry, I should remove that comma. Any chance you have an answer to the last comment I wrote in the answer below? \$\endgroup\$
    – M-R
    Apr 23, 2018 at 1:25
  • \$\begingroup\$ Some tasks need to run on a strict schedule. Others need to run, but it doesn't matter if they run now or in a few ms. So the idea is to make sure your tasks that need to run in regular intervals do, and all the leftover time is for tasks which are not as urgent (they can still be important tasks, but not urgent, if you see the difference). \$\endgroup\$
    – user57037
    Apr 23, 2018 at 1:34

2 Answers 2

Reset to default
2
\$\begingroup\$

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.

\$\endgroup\$
8
  • \$\begingroup\$ I thought that may be the case. How often would a FreeRTOS TCP task need to be executed? Would packets still be received while another task is runnning? \$\endgroup\$
    – M-R
    Apr 22, 2018 at 22:25
  • \$\begingroup\$ It runs when needed to process an incoming or outgoing packet. That depends entirely on your specific application. Yes, packets are buffered in the hardware when the CPU is busy. There are also flow-control mechanisms built into the protocol. If the hardware buffers fill up, things slow down, but data is not lost. \$\endgroup\$
    – Dave Tweed
    Apr 22, 2018 at 22:33
  • \$\begingroup\$ If an incoming packet needs to be processed, does the running task need to be interrupted, or can the TCP task takeover after the running task has blocked, without losing data? I guess it might be appropriate to have the TCP handling task run continuously, at a priority lower than the time critical task, so it only ever runs when nothing else needs to be done. Sound sensible? \$\endgroup\$
    – M-R
    Apr 22, 2018 at 22:40
  • \$\begingroup\$ UDP packets could conceivably get lost. TCP will be re-transmitted if needed. \$\endgroup\$
    – user57037
    Apr 23, 2018 at 1:34
  • \$\begingroup\$ @mkeith, would the packet definitely be lost if another task was running? Did my approach above seem appropriate? \$\endgroup\$
    – M-R
    Apr 23, 2018 at 1:37
0
\$\begingroup\$

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.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.