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