Searching \ for 'Multi tasking instructor' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=multi+tasking+instructor
Search entire site for: 'Multi tasking instructor'.

Truncated match.
PICList Thread
'Multi tasking instructor'
1999\05\12@203545 by Dennis Plunkett

flavicon
face
13/5/'99


I have been watching this with great interest. (Flame suit on) Isn't it
funny how we can miss the point and drift of into a tangent (Flame suit
off), one has to ask the question of what the operating system is for, and
is there any other way. Remembering that the requirement is to not use
interrupts. If this is so then the programmer will have to spend much time
counting instructions in order to control the task switching. This
invariably makes the code application dependant, and the programmer will be
creating work for him/her self reworking the code and changing it to suit
other applications (Not bad for $50 to $90 per hour eh, get more of them
stock options :) )

So what am I implying: perhaps we should investigate the requirement a bit
more, as I don't think that the solution is a workable one in the long
term-> The simple task scheduler is application dependent if timing is
critical.

If no timer is used then the code will look very fragmented (If fast
scheduling is required) with gotos and calls and move PCL instructions all
over the place. A maintenance nightmare!!!

Also if it is not to use interrupts, will the task scheduler be used in a
PIC with interrupts? If so then we do not directly control the timing, we
may have to look for another way to do such. This then makes the whole
thing even more complex, with timer routines passing values to tasks and
maybe controlling the run time of the module. This also may create trouble
with I/O functions.

Is this scheduler for that project I seen a few days ago where it is
required to read a serial port and then clock stuff out a sync serial port,
read a few keys and that?


Dennis

1999\05\12@205647 by Michael Shiloh

flavicon
face
>I have been watching this with great interest. (Flame suit on) Isn't it
>funny how we can miss the point and drift of into a tangent (Flame suit
>off), one has to ask the question of what the operating system is for, and
>is there any other way. Remembering that the requirement is to not use
>interrupts. If this is so then the programmer will have to spend much time
>counting instructions in order to control the task switching.

Not necessarily - the task switching could be based strictly on priority,
or round robin where a task runs to completion.

Probably not very common but there might be some applications.

1999\05\12@224956 by Dennis Plunkett

flavicon
face
13/5/'99

       /\
       |
Oh isn't it great to live in the future!
       |
       \/
At 18:04 12/05/99 -0700, you wrote:
{Quote hidden}

Yes this is so, but is it a task switcher or a mulittasking environment?
Round robin is used quite often, the time critical things are completed by
interrupt, such is the RX116 type operating system (In basic form)
It is also common to group the two together and rounf robin switch tasks
according to priority levels (Can be set by timer for example)

Dennis

1999\05\13@031517 by William Chops Westfield

face picon face
   (Flame suit on) Isn't it funny how we can miss the point and drift of
   into a tangent (Flame suit off), one has to ask the question of what
   the operating system is for, and is there any other way. Remembering
   that the requirement is to not use interrupts. If this is so then the
   programmer will have to spend much time counting instructions in order
   to control the task switching.

ok.  Here is a basic lesson in multicasting.  I'll use a C-like syntax.

This is part 1 - a very basic multitasking setup.

Your most basic form of multitasking looks something like this:

scheduler() {
   while (TRUE) {
       task1();
       task2();
       task3();
       task4();
        :
       taskN();
   }
}

Obviously, this places rather severe constraints on how each task must
operate.  They have to be well behaved and not sit in loops waiting for
something to happen.  They can't run for too long even if stuff is
happening.  And they have to return (at their "top level") when they're
done.  Still, even in this simplistic environment, you can accomplish
useful things.  Consider:

   task1() { /* Uart receiver */
       while (uart->status & RXRDY)
           char_enqueue(uart->data);
   }

   task2() { /* Uart transmitter */
       char c;
       while (uart->status & TXREADY) {
           if (NULL != (c = char_dequeue()))
               uart->data = baudot2ascii(c);
       }
   }

   task3() { /* flash an LED at slow rate */
       static boolean savedbit;
       boolean thisbit;

       thisbit = (0 != (timerreg16() & 0x0080)); /* get HALFSEC bit */
       if (thisbit != savedbit)
           toggle_led();
   }

There - you now have a system that reads data from a uart, translates the
character set, and transmits the translated character back out, and blinks
an LED at a timed rate, all while continuing to do task4() through taskN()
as well.  Not bad.  The limitation is that the sum of the execution time of
all the tasks can not exceed the time it takes the data link to fill up the
uart's receive fifo, or you'll lose data.  If the link is slow, the fifo is
big, and the processor is fast, you can do quite a bit.  You also can't take
so long that task3() will miss the bit change, and if you don't call it at
a fairly frequent interval, people will notice an uneven duty cycle.

There are a couple of things to notice here.  First is that the tasks
themselves have no "permanant" context other than what they save for
themselves off in what are really global resources.  The stack (such as
it is) is shared by all tasks.  The global resources really ARE global,
and a badly behaved task can easilly screw up everyone else.

Still, I have a hard time imagining anything much more complex than this
operating on the small PICs.  Shucks - the entire CHIP doesn't have as much
"context" as the register set on a modern CISC chip :-)

The rest of multi-tasking is mostly a matter of allowing each task to have
more in the way of private context, more flexibility in giving up control to
"the scheduler", more control of deciding when it needs to be "woken up",
and more protection from the actions of badly behaved tasks.

More in part 2.

BillW

1999\05\13@034549 by Gerhard Fiedler

picon face
At 00:13 05/13/99 -0700, William Chops Westfield wrote:
>Still, I have a hard time imagining anything much more complex than this
>operating on the small PICs.  Shucks - the entire CHIP doesn't have as much
>"context" as the register set on a modern CISC chip :-)
>
>The rest of multi-tasking is mostly a matter of allowing each task to have
>more in the way of private context, more flexibility in giving up control to
>"the scheduler", more control of deciding when it needs to be "woken up",
>and more protection from the actions of badly behaved tasks.

you can do pretty complex things in this way, if you use state machines in
the tasks, with short state actions, returning regularly to the scheduler.

ge

1999\05\13@150322 by Dwayne Reid

flavicon
face
Dennis Plunkett wrote:

>Is this scheduler for that project I seen a few days ago where it is
>required to read a serial port and then clock stuff out a sync serial port,
>read a few keys and that?

Nope - that was me (Dwayne).  Project is mostly finished (got another
project that has to go out first) and I'll be posting the code for it once I
have it working.

Just a refresher - what I needed to do was: receive serial input at 9600
baud, transmit an ack (9600), talk to some shift registers, generate a
medium speed PWM (~1000 Hz), and misc other stuff (read a/d, etc).  Its
implemented as a loop that executes in 104 cycles (samples RX 3 times within
the loop) and uses a mickey mouse task switcher to fit the housekeeping
stuff in the free time slots (2 slots of 22 cyles in each pass of the loop).
Its not very pretty and I'm sure that I'll get lots of comments to that
effect when I do post it.  But thats how I learn!

dwayne


Dwayne Reid   <spam_OUTdwaynerTakeThisOuTspamplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax

Celebrating 15 years of Engineering Innovation (1984 - 1999)

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Do NOT send unsolicited commercial email to this email address.
My posting messages to Usenet neither grants consent to receive
unsolicited commercial email nor is intended to solicit commercial
email.

1999\05\15@213748 by Graeme Smith

flavicon
face
GRAEME SMITH                         email: .....grysmithKILLspamspam@spam@freenet.edmonton.ab.ca
YMCA Edmonton

Address has changed with little warning!
(I moved across the hall! :) )

Email will remain constant... at least for now.


On Thu, 13 May 1999, Dennis Plunkett wrote:

> 13/5/'99
>
>
> I have been watching this with great interest.
... snip ...>

> So what am I implying: perhaps we should investigate the requirement a bit
> more, as I don't think that the solution is a workable one in the long
> term-> The simple task scheduler is application dependent if timing is
> critical.
>
> If no timer is used then the code will look very fragmented (If fast
> scheduling is required) with gotos and calls and move PCL instructions all
> over the place. A maintenance nightmare!!!

Doesn't have to be.... if the co-operative code is used to build a virtual
machine language. Each snippet of code, would simply need to be padded out
to a similar length of processing time. You would then program in the VML
rather than in native code, which believe it or not is recommended in
certain programming circles.

>
> Also if it is not to use interrupts, will the task scheduler be used in a
> PIC with interrupts? If so then we do not directly control the timing, we
> may have to look for another way to do such. This then makes the whole
> thing even more complex, with timer routines passing values to tasks and
> maybe controlling the run time of the module. This also may create trouble
> with I/O functions.

If I were running this on a machine that implimented interrupts, I would
set the mask so that the interrupts didn't interrupt the code. Then there
is no problem with changing timing. On the other hand, it recently occured
to me, that having the ability to munge the timing from time to time,
might actually simplify some applications.

                               Grey

1999\05\16@181943 by Dennis Plunkett

flavicon
face
At 19:36 15/05/99 -0600, you wrote:
{Quote hidden}

VML good it your not looking at machine code. Padded out code segments are
what is normally used in a PIC time based scheduler, try and asnychronus
serial without it (Unless you can halt processing until the byte is sent or
received)

{Quote hidden}

Only the timing within the masked section would not be effected. That
outside of the masked area could be. Masking off interrupts is not a good
idea at any time.



>                                Grey
>
>

Dennis

More... (looser matching)
- Last day of these posts
- In 1999 , 2000 only
- Today
- New search...