GRAEME SMITH                         email: grysmith@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