At 19:36 15/05/99 -0600, you wrote:
>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.
>

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)

>>
>> 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.
>

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