Thought Leadership

Simple real-time task scheduling – a question and an answer

By Colin Walls

I recently received an email, from somebody with whom I was not acquainted, with the subject line “Probably a silly question”. This got my attention, as I think the only silly thing about a question is not asking it. It certainly was not a silly question. The emailer was asking about implementation of a real time system and I gave him some advice, which I hope was helpful.

With his permission, I will share the question and my answer …

As the question was about implementing a real time system, my default response would be advice about using an RTOS. Although, in this case, it might have been a valid response, it is probably not the best answer. Here is what he asked:

I am using a bare metal app with a super loop. Using polling inside for 3 tasks at different time periods. So am I better off using a simple for loop or using the timer module present in the Atmel SAM D20 Arm M0+ microcontroller ?

100usec – action A
1msec – action B
10msec – action C

Obviously, a for loop/delay is the easiest way but it keeps the processor working and it may not be easy to put the microcontroller to sleep to conserve power. So I am taking a look at implementing it using timers. Please let me know if I am doing it wrong ?!

The nature of the three actions is unimportant. Suffice it to say that they are small amounts of processing that needs to be performed at regular intervals.

It would be quite possible to use an RTOS. Each action would be coded as a task something like this:

void task_A()
{
 action_A();
 RTOS_delay(100);
}

void task_B()
{
 action_B();
 RTOS_delay(1000);
}

void task_C()
{
 action_C();
 RTOS_delay(10000);
}

If the application was the starting point for something bigger – i.e. much more functionality/complexity might be added later – utilizing an RTOS may be an excellent idea. This is because an RTOS supports a multi-threaded structure which is very scaleable, so adding new functionality is less likely to adversely affect existing code. Of course, I feel honor bound to recommend our own Nucleus RTOS, which is ideal for such an application.

However, in this case, I had the impression that the project was bounded and I suggested setting up a 100usec timer interrupt and coding the ISR thus:

interrupt void timer_ISR()
{
 static int timer_B = 0;
 static int timer_C = 0;

 action_A();

 if (timer_B-- == 0)
 {
  action_B();
  timer_B = 10;
 }

 if (timer_C-- == 0)
 {
  action_C();
  timer_C = 100;
 }
}

Any other suggestions on how to address this problem? Please comment, email or contact me via social media.

I am also very open to queries such as this, so please feel free to ask.

Comments

0 thoughts about “Simple real-time task scheduling – a question and an answer
  • Colin, it really comes down to the complexity of the tasks. If all tasks can be performed in a single time slot, it sounds like a good approach. If they take slightly over a time slot, you may decide to shift B or C to the next slot (as long as it is transparent to the app). If they take significantly longer, a preemptive kernel would be the answer. At least this would be my suggestion.

  • @Vasanth – Yes. I assumed that this was what was required. It would be easy to adjust the code so that action_B() and action_C() never occur on the same tick. [Initializing timer_C to -1 would be one way to do this.]

Leave a Reply

This article first appeared on the Siemens Digital Industries Software blog at https://blogs.sw.siemens.com/embedded-software/2016/05/23/simple-task-scheduling-a-question-and-an-answer/