// THREAD 1 ===========================================
while(thread == 1)
{
if(PORTB.F1) LED = 1;
else give_up_timeslice();
}
// THREAD 2 ===========================================
while(thread == 2)
{
}
// THREAD END =========================================
give_up_timeslice();
thread = 0;
}
}
// this function can be called by any thread
void give_up_timeslice(void)
{
while(TMR0 > 240); // WAIT HERE until sure that int cant happen
thread++; // make next thread active
intcount = 255; // will roll to zero, so next thread gets full timeslice
}
Above you can see above, thread 1 politely decided to give up its timeslice when it discovered it had nothing left to do.
The little function give_up_timeslice() can also be used to clean up after all the threads at the bottom of the sequence. So if a thread has gone into overtime the give_up_timeslice() function will re-sync so the next thread (which will be thread 0) will get a full timeslice.
multi-threading by frequency
The systems above are all timeslice multi-thread systems, they operate by allocating a percentage of the available time to each thread.
This next system is a totally different approach. It is a "frequency multi-thread system" (for want of a better name). Threads are executed based on frequency so a thread might be executed on every loop, or every 2nd loop, or every 20th loop etc.
This might be a better multi-threading system where there is a very high priority thread which can be called every loop and other threads called much less frequently. It may also be a good system if there are a large amount of very fast tasks, which are of varying priorities.
while(1)
{
// LOOP SYNCHRONISE ===================================
while(!loop_time_sync); // WAIT HERE until loop time
loop_time_sync--;
loopnum++;
// THREAD 0 ===========================================
// this is very high priority, it is done every loop
// THREAD 1 ===========================================
// this thread is also very high priority
// THREAD 2 ===========================================
if((loopnum % 2) == 0) // do this thread every 2nd loop
{
}
// THREAD 3 ===========================================
if((loopnum % 20) == 0) // do this thread every 20th loop
{
}
// THREAD 4 ===========================================
if(loopnum == 0) // do this thread every 256th loop
{
}
// THREAD 5 ===========================================
if(loopnum == 1) // do this thread every 256th loop
{
}
// THREAD END =========================================
}
The variable loopnum increments for every loop done. It just rolls over so it is always 0-255 range. So threads can be executed on loop frequency like every X loops.
This is a fairly common programming practice; to de-prioritise a section of code that does not need to be run as often as other tasks. But I think if this technique is refined to a new level it may qualify as a form of multi-threading.
The obvious improvement would be to use a timer interrupt again. So any thread could use a shared real world timer or have its own dedicated timer. Also I have added a very simple but sophisticated loop synchronisation system. Now it is looking like a useful form of multi-threading.
The loop sync system (see above) works in tandem with the interrupt timer engine. Imagine that the loop needs to be executed 100 times a second (10mS). The interrupt increments the variable loop_time_sync every 10mS. If a loop takes less than 10mS, the next loop will wait and sync (restart) when the variable is incremented to 1 by the interrupt.
Now some loops may take longer than 10mS, even a lot longer. Or there may be a number of consecutive loops each one being longer than 10mS. The loop_time_sync system will increment for every 10mS, so it keeps perfect accumulated time. If there is a very long overtime loop, or many overtime loops, then the loop_time_sync variable just increments in value and keeps track of the lost time.
Then when there are shorter loops (ie <10mS) they will decrement the loop_time_sync variable every loop until the loop is perfectly back in sync with the interrupt engine! It is a self-correcting self-synchronising loop timer that will allow quite a large total of overtime situations and then just fix itself up later.
Loop frequency PIC-thread application!
This is the same clock project with the same 4 threads. But this time it has been re-structured in a loop frequency multi-thread format and another "time waster" thread has been added to test it. Yes it has been tested in hardware and it keeps great time.
/******************************************************************************
multi-thread4.c Example of PIC multi-thread - making a 12:00:00 clock
Open-source 22nd Dec 2009 - www.RomanBlack.com
(PIC16F887 8MHz EasyPIC6 2x16 LCD; HSOSC WDTOFF LVPOFF)
This uses loop frequency multi-threading.
TMR0 interrupt is the loop timing generator.
Uses 5 threads; varying priorities.
******************************************************************************/
unsigned char intcount;
unsigned char loop_time_sync;
unsigned char loopnum;
unsigned char loop10ms;
unsigned char refresh_display;
unsigned char thread1timer;
unsigned char hours; // clock vars
unsigned char mins;
unsigned char secs;
unsigned char txt[4];
#include "RomanLCD.c" // my library to drive 2x16 LCD
//-----------------------------------------------------------------------------
void interrupt(void)
{
// TMR0 interrupt, gets here every 200 instructions (100uS)
// this incs the loop sync flag every 10mS.
TMR0 += ((256-200)+3); // adjust TMR0 so it rolls every 200 ticks
intcount++;
if(intcount >= 100) // if reached 10mS
{
intcount = 0;
loop_time_sync++;
thread2timer++; // every 10mS
}
INTCON.T0IF = 0; // clear int flag
}
//-----------------------------------------------------------------------------
void main()
{
// setup PIC 16F887 (EasyPIC6)
ANSEL = 0; // Configure AN pins as digital
ANSELH = 0;
CM1CON0 = 0;
CM2CON0 = 0;
PORTB = 0b00111111; // SET LCD pins HI
TRISB = 0b00000000; // PORTB all outs, drives LCD
TRISC = 0b00000011; // RC0,1 are buttons
OPTION_REG = 0b00001000; // TMR0 1:1 prescale (2MHz)
loopnum = 0;
hours = 12;
mins = 0;
secs = 0;
RomanLCD_Init(); // init 2x16 text LCD
INTCON = 0b10100000; // TMR0 interrupt on
// loop here and do the multi-threading loop.
while(1)
{
// LOOP SYNCHONISE ====================================
while(!loop_time_sync); // WAIT HERE until loop time (10mS)
loop_time_sync--;
loopnum++;
// THREAD 0 ===========================================
// HIGH PRIORITY! this thread generates the 1 second event
loop10ms++;
if(loop10ms >= 100) // if reached 1 second!
{
loop10ms = 0;
secs++;
refresh_display = 1; // tell other thread to redraw LCD
}
// THREAD 1 ===========================================
// medium priority
if((loopnum % 5) == 0) // do this thread every 5th loop
{
// this thread checks the 2 buttons to set the clock
// test buttons 4 times per sec
if(thread1timer > 25) // 25x10mS = 250mS
{
thread1timer = 0;
if(PORTC.F0) // set mins button
{
mins++;
secs = 0;
refresh_display = 1; // tell other thread to redraw LCD
}
if(PORTC.F1) // set hours button
{
hours++;
secs = 0;
refresh_display = 1; // tell other thread to redraw LCD
}
}
}
// THREAD 2 ===========================================
// HIGH PRIORITY! this thread updates the minutes and hours
if(secs >= 60)
{
secs = 0;
mins++;
}
if(mins >= 60)
{
mins = 0;
hours++;
}
if(hours > 12) hours = 1;
// THREAD 3 ===========================================
// medium priority
if((loopnum % 5) == 1) // do this thread every 5th loop
{
// this thread draws the clock on LCD if needed
// this thread is last in case it runs >1mS
if(refresh_display)
{
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);
refresh_display = 0; // refresh is done
}
}
// THREAD 4 ===========================================
// low priority
if((loopnum % 20) == 2) // do this thread every 20th loop
{
// this thread is just a nasty big delay every 20 loops
// to test the self correcting loop sync system.
Delay_ms(60);
}
// THREAD END =========================================
}
}
As the sync loop can be relied on to make exactly 100 loops per second I generated the 1 second event by counting loops, mainly to test the reliability of the loop sync. However it could have used a dedicated 1 second timer like the last project, which would have been a better choice. Thread 1 still uses a dedicated timer that is controlled in the interrupt to make the 250mS period for checking the buttons.
The loop sync works fine, it swallows up the large 60mS "task" in thread 4 that occurs every 20 loops and resyncs within a few loops and there is no noticable difference on the display, and obviously it keeps perfect time.
I'm definiely NOT an expert in multi-thread software! But having independant threads that can have independant resources (real world timers etc) and being able to just slot in a large clumsy task by simply adding a thread, all without any noticable effect on operation, seems like a decent definition. At least it's a starting point for working with multi-thread systems on a PIC.
Where to go from here?
The code examples on this page are all pretty crude. Even the 2 clock applications have no real NEED to be multi-threaded apps.
But when I look back at some of the larger PIC projects I have made in the past (especially ones that grew until they became clumsy) I can see they would have been much better built with some type of multi-thread structure.
For the future it would be good to explore systems for controlling the threads communication with each other. Using better variable names and a system for controlling whether data flows in or out of a thread, so threads can pass data and commands to each other with no conflict. Also to look at ways of making threads more independent, like ways of removing any need for threads to be sequenced in a particular order.
And also to explore ways of making thread execution much more parallel and less sequential. As an example if a thread is writing graphics data to a GLCD (which can take a while) it might only write one byte every time that thread is executed, so the GLCD write occurs in parallel to other tasks. This could be done with intra-thread scheduling so each thread can queue up tasks and and perform a little piece of each task every time that thread is executed.
A proper PIC-thread project; Baudrate converter 1
This uses the PIC-thread loop frequency system and 4 threads to operate as a high speed asynchronous bidirectional baudrate converter.
The 4 threads are displayed in colour;
// THREAD 0 ===========================================
// check if usart1 received a byte, put it in buffer
// THREAD 1 ===========================================
// check if usart2 received a byte, send it out to usart1
// THREAD 2 ===========================================
// send usart1 byte if any bytes are in buffer
// THREAD 3 ===========================================
// display the buffer1 load as a 7 LED bargraph on PORTB
The loop frequency system gives high priority to threads 0, 1 and 2. These are checked and executed every loop to keep data transfer high. Thread 3 is a lower priority (because it just displays the bargraph) and is only executed every 16th loop.
Here is the actual thread code;
while(1)
{
// LOOP SYNCHONISE ====================================
// don't sync, just run loop at full speed
loopnum++;
// THREAD 0 ===========================================
// HIGH PRIORITY!
// check if usart1 received a byte, put it in buffer
if(PIR1.RC1IF)
{
buffer1[inpointer1] = RCREG1; // store the byte
inpointer1++;
if(inpointer1 >= MAXBUFFER1) inpointer1 = 0;
}
// THREAD 1 ===========================================
// HIGH PRIORITY!
// check if usart2 received a byte, send it out to usart1
if(PIR3.RC2IF)
{
if(TXSTA1.TRMT) TXREG1 = RCREG2; // if usart1 TX free, send byte
}
// THREAD 2 ===========================================
// HIGH PRIORITY!
// send usart1 byte if any bytes are in buffer
bufferload1 = (inpointer1 - outpointer1);
if(bufferload1)
{
if(bufferload1 >= MAXBUFFER1) bufferload1 += MAXBUFFER1; // fix buffer roll
th3display = (bufferload1 >> 8); // 1792->7 ready for bar display
if(TXSTA2.TRMT) // if usart2 free, send another byte
{
TXREG2 = buffer1[outpointer1];
outpointer1++;
if(outpointer1 >= MAXBUFFER1) outpointer1 = 0; // fix buffer roll
}
}
else th3display = 0;
// THREAD 3 ===========================================
// medium priority
// display the buffer1 load as a 7 LED bargraph on PORTB
if((loopnum & 0x0F) == 0) // do this thread every 16th loop
{
LATB = 0;
if(bufferload1) LATB.F7 = 1; // 7 LED bargraph
if(th3display) LATB.F6 = 1;
if(th3display > 1) LATB.F5 = 1;
if(th3display > 2) LATB.F4 = 1;
if(th3display > 3) LATB.F3 = 1;
if(th3display > 4) LATB.F2 = 1;
if(th3display > 5) LATB.F1 = 1;
}
// THREAD END =========================================
}
The 7 LED bargraph will light LED 7 if there are any bytes in the buffer and then LEDs 6 to 1 show the buffer usage in a linear fashion.
This project is tested in hardware and can be seen complete on my BIGPIC6 Projects Page along with a more sophisticated PIC-thread project which is a Baudrate converter with GLCD display and a 62 bar bargraph to show the buffer usage.
I think this project is a pretty fair demonstration of a multi-threading application, for these reasons;