Electronic Circuits and Projects Forum

2nd January 2010 10:17 AM

Hi guys, I've been playing with some PIC multi-thread concepts.

It is still in early stages but I have been trying to create some multi-thread systems in PIC firmware (in C language).

The goal of these systems is to act as a simple framework to create PIC projects using a multi-thread type methodology where the code tasks are defined as separate "threads" and as a whole the code will allow a level of multi-task "parallel" type performance;

# Will run many threads, each is independent
# Processor time can be divided between threads
# Threads are fast sequenced, and for many purposes "run at the same time"
# Threads can be easily added without affecting application performance
# Threads can be placed in any order
# Each thread can be executed (or not) with no effect on other threads
# RAM variables and special timers can be shared or dedicated to one thread
# Threads can be prioritised
# It may be a good general structure for many microcontroller projects

This work is still in a very early stage but I can see some possibilities. It seems to be a good framework for creating new projects from scratch that will need to have features added or changed later.

The web page is mainly descriptions of possible multi-thread systems and lots of source code examples, and there are 4 actual projects using the PIC-thread system including an LCD clock demo and two nice performance RS232 baudrate converters;

The PIC-thread web page can be seen here;

PIC-thread, simple PIC multi-thread systems

2nd January 2010 01:54 PM

I've often thought of writing a multi-tasking kernel for the 16 bit pics, so it's interesting to see what you've been doing here. Alas, there are so many projects I want to do and this isn't very high priority atm.

Have you though of writing an actual kernel for true pre-emptive multi-tasking? I doubt it would be worth it on the 8-bits, but the 16-bit pics I think have enough power and memory to handle a simple one.

2nd January 2010 03:00 PM

I just went and Wiki'd preemptive multi-tasking so I would know what you were talking about.

Actually I did use preemptive multitasking in the second version of that baudrate converter, the one that displays the buffer on a 62 bar bargraph shown on a graphics LCD. The "preemptive" process of interrupting the task was done manually by that task itself which just draws one of the 62 bars every time that task is executed in the task sequence.

I hadn't heard of the term preemptive multitasking (or cooperative multitasking) but the simple systems I've suggested can do what looks to be a blend of both, it's quite preemptive because there can be an interrupt (separate to the task) or sequencing engine separate to the task that will cause that task to end and also cooperative because the task has to choose to end.

Given the limitations of the PIC hardware I doub't it would be worth performing TRUE preemptive multitasking. You could interrupt the task directly, but then would need to save the entire stack specific to that task including the program counter. The overhead of the interrupt and saving and restoring the entire stack for every task just doesn't seem worth it especially with all the extra code and chance of trashing a stack being a catastrophic failure.

Which is the reason for exploring faster simpler more reliable ways of getting basically the same end result.

2nd January 2010 05:41 PM

Hi Roman,

Forgive me but I don't see the advantage of the "thread" architecture in your examples. Take your "multi-thread3.c" program for example. I don't see why you would dedicate 1-msec of processing time to "thread 0" and 1-msec of processing time to "thread 1" when the task in "thread 0" is keyed to an interrupt flag that occurs once every second and the tasks in "thread 1" are keyed to the once-per-second update of the "secs" variable in "thread 0".

Code:

  while(1)
  {
    // THREAD 0 ===========================================
    while(thread == 0)
    {
      // this thread looks for a new second and updates the seconds
      if(newsecond)
      {
        newsecond = 0;
        secs++;
        refresh_display = 1;  // tell other thread to redraw LCD
      }
    }
    // THREAD 1 ===========================================
    while(thread == 1)
    {
      // this thread updates the minutes and hours
      if(secs >= 60)
      {
        secs = 0;
        mins++;
      }
      if(mins >= 60)
      {
        mins = 0;
        hours++;
      }
      if(hours > 12) hours = 1;
    }

It seems you're adding a level of complexity to the program that just isn't necessary but perhaps I'm missing something more subtle? Is there an advantage to your "threaded" program over a simpler program running at any loop speed that I'm missing?

Code:

  while(1)
  {
    if(newsecond)           // if "newsecond" isr flag
    { newsecond = 0;        // reset "newsecond" isr flag
      secs++;               // and bump "secs"
      if(secs >= 60)        // if "secs" overflow
      { secs = 0;           // reset "secs" var'
        mins++;             // and bump "mins"
      }
      if(mins >= 60)        // if "mins" overflow
      { mins = 0;           // reset "mins" var'
        hours++;            // and bump "hours"
      }
      if(hours > 12)        // if "hours" overflow
      { hours = 1;          // reset "hours" var'
      }
      ByteToStr(secs,txt);  // format and display secs
      txt[0] = ':';
      if(txt[1] == ' ') txt[1] = '0';
      RomanLCD_Out(0,6,txt);

      ByteToStr(mins,txt);  // format and display mins
      txt[0] = ':';
      if(txt[1] == ' ') txt[1] = '0';
      RomanLCD_Out(0,3,txt);

      ByteToStr(hours,txt); // format and display hours
      RomanLCD_Out(0,0,txt);
    }
    if(thread2timer > 250)  // if 250-msec interval
    { thread2timer = 0;     // reset 250-msec timer
      if(PORTC.F0)          // if set mins button
      { mins++;             //
        mscount = 0;        //
        secs = 0;           //
        newsecond = 1;      //
      }
      if(PORTC.F1)          // if set hours button
      { hours++;            //
        mscount = 0;        //
        secs = 0;           //
        newsecond = 1;      //
      }
    }
  }

3rd January 2010 04:08 AM

I find it hard to believe that there are not a million RTOS's out there for the PIC already. FreeRTOS says it has ports for the PIC.

Actually, doing a google search comes up with a bunch, but I'm too lazy to investigate any more.

3rd January 2010 07:57 AM

Originally Posted by Mike, K8LH

...

It seems you're adding a level of complexity to the program that just isn't necessary but perhaps I'm missing something more subtle? Is there an advantage to your "threaded" program over a simpler program running at any loop speed that I'm missing?
...

Hi Mike, the first code examples on the page are multi-threading by dividing the processor time between tasks. So you can allocate 30% of time to task1, and 10% of the time to task2 etc.

That first clock project I did is just a poor example because it does not really take advantage of the system ability to divide processor time between tasks. Like I said these are experimental systems in the early stages so even though that one project itself doesn't really gain much from being coded as multi-thread doesn't meant that other projects won't benefit.

Ill summarise because that page is a bit long;

Top section of the page;
Multi-thread examples that divide the processor TIME between threads.
So tasks get a percentage of processor time each. I haven't found a good project to demo it yet.

Bottom section of the page;
Multi-thread examples that divide processor between tasks based on FREQUENCY.
So some tasks are performed every loop, some every X loops, and some can be every X milliseconds.
The 2 baudrate converter projects are pretty good demo examples.

Advantages of all of the systems;
All the systems have benefits because tasks can be added without affecting other tasks, tasks can have totally independent timers and execute every X seconds without affecting other tasks, tasks can be structured to operate without affecting other tasks and without being affected by other tasks.

Tasks can be independently prioritised so important tasks run often or get lots of processor time, while less important tasks run infrequently or get less processor time, that can all be adjusted without tasks affecting each other.

I also think there are actual coding benefits from using these structures as a starting point for projects. Like a beginner can add a "read the buttons" thread with its own timer that reads the buttons every 300mS, and that thread slots straight in with absolutely no affect on the other threads that flash the LEDs every 1000mS etc.

Originally Posted by DirtyLude;

...
I find it hard to believe that there are not a million RTOS's out there for the PIC already. FreeRTOS says it has ports for the PIC.
...

I think this is really a level lower than a RTOS and a heap simpler. It is more a "template", a simple system to structure a program so that tasks can easily be added or removed from the program without interfering with each other.

3rd January 2010 08:42 AM

Hi Mike, the first code examples on the page are multi-threading by dividing the processor time between tasks. So you can allocate 30% of time to task1, and 10% of the time to task2 etc.

Why would you want to dedicate 30% or 20% or 10% of processing time to a task that doesn't require that amount of time? Why not just run it once when needed? Time-Slice "threading" is probably not the best way to use the limited resources on a small PIC mcu.

All of the advantages you listed can be achieved without using time-slice threads. The Arduino guys were pretty clever in this regard. They have a 1-msec system timer that you can use to schedule tasks that run asynchronously (or synchronously) at any interval -- you can have one task that runs every 250-msecs, one that runs every 1250-msecs, and another one that runs every 60000-msecs (1 second), etc. And you still have event driven tasks running at the main loop speed and can use almost any method you like for linking dependant and/or synchronous tasks.

Regards...

3rd January 2010 09:33 AM

Originally Posted by Mike, K8LH

Why would you want to dedicate 30% or 20% or 10% of processing time to a task that doesn't require that amount of time? ...

Because as a system it MIGHT be useful. Imagine if you need to do some massive calculations that will take a lot of time. You could allocate X% of the time to doing that task while other more urgent tasks get more of the timeslice.

Originally Posted by Mike, K8LH

...
The Arduino guys were pretty clever in this regard. They have a 1-msec system timer that you can use to schedule tasks that run asynchronously (or synchronously) at any interval -- you can have one task that runs every 250-msecs, one that runs every 1250-msecs, and another one that runs every 60000-msecs (1 second), etc. And you still have event driven tasks running at the main loop speed and can use almost any method you like for linking dependant and/or synchronous tasks.
...

Yep. That is just ONE of the features I already had implemented in the PIC-thread systems.

3rd January 2010 10:07 AM

Originally Posted by Mr RB

Because as a system it MIGHT be useful. Imagine if you need to do some massive calculations that will take a lot of time. You could allocate X% of the time to doing that task while other more urgent tasks get more of the timeslice.

Unfortunately that's just too rigid and too inflexible a system to be useful for more than a few simple applications. If you have a single task that requires a large time slice you wouldn't be able to execute other tasks that require servicing at intervals that are shorter than your large time slice task.

3rd January 2010 10:28 AM

Have to agree with Mike. Multi tasking on a pic is not usually required.

Mike.

Electronic Circuits and Projects Forum

Here are some PIC multi-tasking systems

Here are some PIC multi-tasking systems

Similar Threads

PIC's multi-tasking

Multi-tasking

Multi Tasking...Sort of

How does a multi-tasking kernel works?

software multi-tasking for 89c52