A. Go to www.pumpkininc.com

Look at their 'Salvo' real time operating system. The quote below says it all.

1. There is multiple tasks.
2. Some of the tasks are low-priority, and can execute in the background, being interrupted by higher priority tasks. For example, low-frequency PWM with 300ms of mathematical calculations happening every 1 second.

Using a State Machine

The topic of this tutorial is not to teach state machines - they are very common - look them up on the web.

Using a Time Sliced Multi-tasking system

The multitasking system below was used to implement, on an 8-pin 12CE674 and 28-pin 16F876, software polling of a pin to get serial characters, perform maths at regular intervals on the serial character buffer, write the data to a 24LC256 I2C EEPROM, and generate 50Hz variable duty cycle PWM.  This was all performed simultaneously, so the PIC could accept a continuous serial stream.  It works beautifully - the code is stable.

Heres the explanation of how this was achieved.  This technique that allows one to harness the power of a PIC micro.  It is definitely worth learning, and probably the single most important technique in this FAQ.

1. For this example, set up the simulator for a PIC16F876.
   
2. Set up timer 1 to overflow and trigger and generate an interrupt every 500us.
   
3. The interrupt service routine will get executed every 500us.
   
4. For each individual task, have three things:
   i.      A counter that increments every time the interrupt happens every 500us
   ii.      A task counter maximum, called TASKX_COUNTER_MAX.  When the counter gets to this maximum, it executes the task.  Thus, one can set the frequency that each task gets performed by changing this maximum.  One task may have a maximum set to 1, which means it executes every 500us, and another set to 2000 which means it only gets executed every 1000ms.
   iii.      A task enable boolean flag, TASKX_ENABLE.
   
5. Thus, we can set the frequency and priority of how often each task gets performed.
   
6. We can extend this further – what happens if we have to regularly do a task that takes ages, say 100ms of mathematical calculations, but it only happens every second?  It we execute it right in the interrupt, it will stop all the high frequency, important tasks from executing every 500us.  We couldn’t have the PWM stopping for 100ms.
   1. So, all we do is trigger the slow, complex task from the interrupt, by setting taskX_go=true.  Then, the interrupt immediately finishes ready for the next task. 
   2. In the meantime, a loop in main() is polling taskX_go.  If it is true, it sets it to false ready for next time, then executes the task at its leisure.  While this is going on, the high priority tasks still happen at a normal rate.
      
7. In summary:
   1. We can execute any number of tasks at regular intervals. 
   2. We can choose the frequency of executing each task by altering TASKX_COUNTER_MAX. 
   3. Choose the order of execution by having the most important tasks first in the interrupt routine.  This alters the priority.
   4. Have slow, infrequent background  tasks executing in main(), triggered by the interrupt setting ‘taskX_go=true’ at regular intervals.
8. There is one more tip to avoid problems.  The time inbetween the 500us ‘ticks’ must be enough to execute all the tasks, in the worst case.  Either that, or only one task is executed per 500us interrupt ‘tick’, and the others have to wait until a free slot comes along.  To tell whether the timing is too tight and tasks are executed again before the previous one had a chance to finish, add a line to check whether the timer interrupt flag has aleady been set before the interrupt exits.

Download Complete Example Project

For the complete C source code which illustrates this time-sliced method, follow the link to the "Complete Design for Giant 8-foot LCD Counter" (see the picture showing the completed product). The sample project includes C source code, hardware, and VB controller.

Sample Code Outline

The sample code below briefly outlines the code described above:

//(c)Shane Tolmie, http://www.microchipc.com/, distribute freely for non commercial use on the condition that you include this web link somewhere in your document.
//*****
//multitasking system – handle multiple tasks with one microprocessor

//task counters used to tell when a task is ready to be executed
//all these counters are incremented every time a 500us interrupt happens
//every task has its own counter that is updated every time a 500us interrupt happens
unsigned int task0_counter=0;
unsigned int task1_counter=0;
unsigned int task2_counter=0;

//this tells when a task is going to happen again
//for example, when task0_counter==TASK0_COUNTER_MAX, set task0_counter=0 and do task
#define TASK0_COUNTER_MAX 1         //high frequency task – every 500us, maybe PWM
#define TASK1_COUNTER_MAX 2000      //low frequency task – every 1000ms
#define TASK2_COUNTER_MAX 5000      //low frequency and low priority task, every 2500ms

//Note: every variable referenced in both interrupt and main() must be declared volatile. You have been warned!
//this enables/disables a task
volatile unsigned char task0_enable=TRUE;
volatile unsigned char task1_enable=TRUE;
volatile unsigned char task2_enable=TRUE;

//this allows tasks triggered by interrupt to run in the background in main()
volatile unsigned char task2_go=FALSE;
void setup_multitasking(void)
{
   //set up tmr1  to interrupt every 500us
   TMR1CS=0;
   T1CKPS0=0;
   T1CKPS1=0;

/*We want to wait 2000 clock cycles, or 500us @ 16MHz (instructions are 1/4 speed of clock).  Timer 1 interrupts when it gets to 0xFFFF or 65535.  Therefore, we set timer 1 to 65535 minus 2000 = 63535, then wait 2000 ticks until rollover at 65535.  To test, use simulator to find that its exactly correct*/

   #define  TICKS_BETWEEN_INTERRUPTS      2000
   #define  INTERRUPT_OVERHEAD            19
   #define TMR1RESET (0xFFFF-(TICKS_BETWEEN_INTERRUPTS-INTERRUPT_OVERHEAD))
   #define TMR1RESET_HIGH TMR1RESET >> 8
   #define TMR1RESET_LOW TMR1RESET & 0xFF
   TMR1ON=0;
   TMR1H=TMR1RESET_HIGH;
   TMR1L=TMR1RESET_LOW;
   TMR1ON=1;     
   TMR1IF=0;
   TMR1IE=1;
   PEIE=1;
   GIE=1;  
}

void interrupt isr(void)
{
   //one tick every 500us at 16Mhz
   if (TMR1IF)
   {
      //set up timer 1 again to interrupt 500us in future
      TMR1IF=0;
      TMR1ON=0;
      TMR1H=TMR1RESET_HIGH;
      TMR1L=TMR1RESET_LOW;
      TMR1ON=1;
      task0_counter++;
      if (task0_counter>=TASK0_COUNTER_MAX)     //high frequency task – every 1 tick
      {
            task0_counter=0;
            if (task0_enable==TRUE)
            {
                  //do high frequency important task 0, for example PWM
            }
      }
      task1_counter++;
      if (task1_counter>=TASK1_COUNTER_MAX)     //low priority task - every 2000 ticks
      {
            task1_counter=0;
            if (task1_enable==TRUE)
            {
                  //do low frequency yet important task 1
            }
      }

/*this task takes a long time, 100ms for example, lots of maths.  Is extremely low priority, but has to be done at regular intervals, so all this does is trigger it.  In main(), it will, at leisure, poll ‘task2_go’ and then execute it in the background.*/

      task2_counter++;
      if (task2_counter>=TASK2_COUNTER_MAX)     //every 250ms
      {
          task2_counter=0;
          if (task2_enable==TRUE)
          {
               //every 250ms take 100ms to do maths, do this in main() so the we can get back to doing the high frequency tasks.
               task2_go=TRUE;
          }
      }
   }  //if (TMR1IF)
} //interrupt routine

main()
{
   setup_multitasking();
   while(1)
   {
      if (task2_go==TRUE)
      {
            task2_go=FALSE;
            //take our time, doing heaps of complex maths at our leisure in the background
      }
   }
}

User Feedback

On Wed, Jun 10, 2009 at 12:56 AM, Mauricio Gendelman wrote:

> Shane,
>
> Thank you for putting available your website to the whole PIC community, it
> is really well done and I do appreciate your efforts.

You are welcome.

> I was checking in detail your description of the multitasking system but
> still have a few doubts. Sorry for my ignorance and having to ask them.

I'll do my best to answer them.

> The concrete questions refer to some paragraphs.
>
> 1) .....Either that, or only one task is executed per 500us interrupt
> ‘tick’, and the others have to wait until a free slot comes along. To tell
> whether the timing is too tight and tasks are executed again before the
> previous one had a chance to finish, add a line to check whether the timer
> interrupt flag has aleady been set before the interrupt exits.

> The whole paragraph cause me problems. It is more or less evident for me
> that the whole processes inside the ISR must be executed between ticks.

Yes, this is correct.

There are two types of tasks: short tasks, and long tasks.

A "short task" is so fast, that it can always be executed entirely within the ISR, i.e. it takes less than 500us to execute. An example is "increment a timer, and set a flag if the timer goes over a certain value".

A "long task" is so slow that it cannot be executed entirely within the ISR, e.g. it takes 50ms to execute. An example of a long task would be "calculated the cosine of an an angle, send it out the serial port".

Here is the key: put the short tasks inside the ISR, and move the long tasks into main() so they will run in the background.

The short tasks get executed immediately, entirely within the ISR.

The long tasks are executed in main(), in the background. The long tasks can be triggered to run by the short tasks in the ISR.

> Q1. Are you referring (with this paragraph) to the case in which one single
> task inside the ISR takes too long and a new tick appears before finishing
> all tasks?

Yes.

> Q2. Why you mention one task per tick? (when there is no guarrantee about a
> task duration...).

I mention one task per tick, because there is only enough time to do extremely quick tasks within the ISR. Longer tasks should be moved to execute in the background, in main(). See above.

> Q3. What do you exactly mean with "time slot" here?

The "time slot" is the amount of time allocated to the ISR.

For example, if you set up the ISR to execute 10 times per second, then there would be 100ms time between each interrupt. If you set up the ISR to execute 100 times per second, then there would be 10ms between each interrupt. The time between each interrupt can be lengthened or shortened, depending on the time that it takes everything within the ISR to execute.

> Q4. Why a task can be executed again before the previous one had a chance to
> finish?

If this is happening, then you have to reduce the number of ticks per second, in the ISR. Another way of thinking about it is that you have to lengthen the amount of time that the ISR has available to execute its tasks.

> Q5. Where exactly would have to be added the line you mention to check if
> TMR1IF has aleady been set before the interrupt exits?...Aren´t you
> referring with this to the first line of the ISR?

This should be checked at the very end of the ISR.

Here is a worked example to illustrate this:

Imagine we set up a timer to trigger an interrupt every 10ms.

At time=10ms, the timer trips, and the program flow jumps into the ISR.

Under normal circumstances, the ISR would take 2ms to execute, and exit at time=12ms.

However, if the ISR took 25ms to execute, then nothing would ever work. The reason is that the interrupt happens every 10ms, and if the ISR takes 25ms, then the program would never get to execute anything running in the background, in main().

How about this situation: 99% of interrupts take 2ms, but the odd interrupt takes 25ms. How would we detect this? Well, at the end of the interrupt, just before we exit and program control returns to main(), we check the flag TMR1IF. If this is set, then its clear that the interrupt must have taken more than 10ms, because the timer tripped the interrupt flag before the interrupt code could exit. In this situation, we would set a variable to let us know. Then, we could react by increasing the amount of time for each interupt to say 50ms.

> 2) In ISR routine
>
> Q1. If in Q5 of 1) you are not referring to the first instruction of the
> ISR: Then, what is this TMR1IF check for? (the one you included in the ISR).

The TMR1IF check is a piece of code to detect if we need to allocate more time to handle each interrupt. See the previous answer.

> 3) Overhead
>
> Q1. I understand it tries to compensate some TMR1 counts before tmr
> overflow, with some time spent in processing other instructions. Which are
> they? Could you please expand your explanation a little bit?

Its just an effort to make the interrupts happen on a regular basis.

Here is an example.

1. Imagine that we set up timer 2 to trigger every 10ms, and set the interrupt flag.
2. When this interrupt flag was set, program flow would jump into the interrupt service routine (ISR).
3. Once we are in the ISR, we reset timer 2 to trigger in another 10ms. This means that another interrupt will occur in 10ms.

However, if we actually measured the time between interrupts, we would find that they are occuring about once every 11ms. Where did this extra 1ms come from? Well, it took 1ms to actually get into the interrupt, to the point where we could set the timer to tick in another 10ms. Another way of saying this is that it took 1ms betweensteps 2 and 3, which would increase the total amount of time to 11ms between interrupts.

So, all we do is set timer 2 to trigger in another 9ms (see step 3). This adjusts the error so that the ISR will trip precisely every 10ms.

> 4) In your answer to Mr. Clive Wilson: 03/07/2003 you write: Work it out so
> that even if all the interrupts happen at once, there's still enough time
> for everything.
>
> Q1. What do you mean with "all the interrupts" happening at once?

I mean that in the event that every single line of code in the interrupt is executed, there should still be enough time to finish the interrupt before the next one happens. Another way of saying this is that the longest code path should still be quicker than the time allocated to the interrupt.

As an example, imagine that you set up the interrupts to happen every 10ms. This means that program flow would jump into the interrupt routine every 10ms.

Imagine that normally, the interrupt took 2ms. Now imagine that we added an "if" statement in this interrupt which only triggered occasionally - but when it triggered, it added an additional 15ms of processing time to the interrupt. This wouldn't work, as the entire interrupt would now take 17ms, which is 7ms more than the maximum available time of 10ms. To fix this, we would have to move this code within the "if" statement into main(), and trigger this code running in main() with a flag which is set in the interrupt.

> Thank you in advance for your reply.
>
> Mauricio
>
> Argentina

-----Original Message-----
From: Clive Wilson
Sent: 07 March 2003 09:01
To: support@microchipc.com
Subject: Time-sliced multitasking system for Hi-Tech C
Shane,

Many thanks for giving us the MicrochipC web site - it is a truly invaluable resource.

I have a question for your regarding the time-sliced multitasking system for Hi-Tech C which you discuss, at http://www.microchipc.com/Hi-Tech_C_multitask.htm. I understand how the time slicing works, along with the variable execution rates (determined by the TASKX_COUNTER_MAX value for each task).

I see that task0 (or whatever the first 'task' in the ISR is called) gets executed at precisely the time expected. However, what happens if task0 has some conditional code which causes the execution path through the task0 code to vary from one interrupt to the next? Then, the next task in the ISR call, e.g. task1, would get executed at varying times after the point when the ISR was triggered. The same goes for any task due to run in the current interrupt - the timeliness of each task is dependent upon all previous
tasks in this interrupt instance having non-varying execution times.

Have I got the wrong end of the stick or is my theory correct? How do you cope with this when doing serial comms? Presumably the variable latency limits the speed at which serial comms can be performed?

Many thanks again for the great web site. I look forward to hearing your opinion on my query.

Kind regards,

Clive Wilson

-----Original Message-----
From: Shane Tolmie
Sent: 07 March 2003 10:47
To: Clive Wilson
Subject: RE: Time-sliced multitasking system for Hi-Tech C

Hi Clive,

Yes, you're right. This is known as interrupt jitter. However, with serial, there is a 2 byte internal buffer, so this can cope with a lot of variance in the exact time that the time-sliced interrupts happen.

The trick is to do all the processing in the background, triggered from the interrupts, and have minimal processing done in the actual interrupt. Work it out so that even if all the interrupts happen at once, there's still enough time for everything.

Regards,
Shane Tolmie
www.microchipc.com

This site is non-profit. Ad revenue almost covers hosting costs.

We welcome any suggesions or comments! Send them to Shane Tolmie on support@microchipc.com. This site is a completely separate site to www.microchip.com, and is maintained independently of Microchip Ltd., manufacturers of the PIC micro. All code on this site is free for non-commercial use, unless stated otherwise. Commercial use normally free, however, it is prohibited without contacting support@microchipc.com for permission. All content on this site created by Shane Tolmie is copyrighted by Shane Tolmie 1999-2009. Click to advertise on this website - $29.90 for a banner ad which will reach 55,000 user sessions per month. One months free trial!