piclist 1997\06\02\021004a >
Thread: os/wars - a compilation - was Re: SoNoboby knows
piclist.com/techref/index.htm?key=sonoboby+knows
flavicon
face BY : John Payson email (remove spam text)



> > When you say cooperative multitasking, are you
> > meaning MT where the code moves between any and
> > all possible combinations of output states, waiting
> > and testing at each one for conditions that say to
> > go to a new output state and wait again?

> Cooperative multitasking is multitasking where a context switch
> occurs only when the current task or thread decides it is prepared
> to relinquish the CPU. This is usually done by calling an OS
> function, e.g. Yield(), which will either return immediately if
> no other task is ready to run, or perform a context switch if there
> is another task ready.

Unfortunately, no PIC (not even the 17Cxx) can at present handle the
general case of cooperative multi-tasking, where either/any process may
execute a yield() from within nested procedures.  The normal method for
handling such task switching is to split the stack area into two or more
pieces; on the 8x51, a task switch (assuming two tasks) would then be
performed as:

Yield:
       mov     a,other_sp
       xch     a,sp
       mov     other_sp,a
       ret


Calling Yield() will place the address following the call onto the stack,
save the stack pointer and point it to the other stack, and then work on
the other task.  When that task calls Yield() the stack pointer will be
restored with its old value, so RETurning will resume execution of the
former task.  Simple and very efficient.

The best a PIC can do is have one task with arbitrary procedure nesting
(up to the total stack limit) and have the other task(s) only yield at the
"top" level [not within a routine].  For a two-way task manager, I think
the following is probably the best approach (assuming the secondary task
fits into 256 bytes):

[general]
There needs to be a byte variable called "Task2PC", and PCLATH should
'always' [any time there's a task switch] be pointed at the page
containing task two.

[for task 1]
 Yield should be a macro that reads as follows:

       call    DoYield
       movwf   Task2PC

 The DoYield label should point to the code:

       movf    Task2PC,w
       movwf   PC

[for task 2]
 Yield2 takes an argument, which is an address to go to once task 1
yields again.  The Yield2 macro [if you want to use a macro] is simply:

       retlw   [address]

[example]

Task 1 is a general purpose who-knows what.  Task 2 is a serial-port
receive routine.  For this particular application, assume the DoYield
"routine" contains code to wait until the end of the current 1/3-bit-time
clock.  Task2 might then look like the following [written to maximize
speed]:

SerIdle:
       btfss   PORTB,0
        retlw  SerIdle
       retlw   SerGotStart1
SerGotStart1:
       btfss   PORTB,0
        retlw  SerIdle
       retlw   SerGotStart2
SerGotStart2:
       retlw   SerGotStart3
SerGotStart3:
       clr     DataIn
       retlw   SerGetBit0a
SerGetBit0a:
       btfsc   PORTB,0
        bsf    DataIn,0
       retlw   SerGetBit0b
SerGetBit0b:
       retlw   SerGetBit0c
SerGetBit0c:
       retlw   SerGetBit1a
SerGetBit1a:
       btfsc   PORTB,0
        bsf    DataIn,1
       retlw   SerGetBit1b
SerGetBit1b:
       retlw   SerGetBit1c
SerGetBit1c:
       retlw   SerGetBit2a
       ...

[I think the overall code size would end up being around 50-60
instructions for the receive routine.  Using a loop would save code space,
but would make the logic more complex.]

Pseudo-cooperative multitasking like the above can be very useful, and can
work quite effectively on a PIC (the total time to switch to and from the
second task is eight cycles).  Unfortunately, for applications where both
tasks are complex, the requirement that the second task always be at
top-level whenever yielding control can make clear and efficient coding
difficult.  Such jobs are perhaps better suited to other processors (alas)
such as the 8x51 or 68HCxx.  For most tasks, however, the PIC is a
wonderful little chip.
<199706020608.BAA01304@Kitten.mcs.com> 7BIT

In reply to: <19970602112009.02936@htsoft.com>
See also: piclist.com/techref/index.htm?key=sonoboby+knows
Reply You must be a member of the piclist mailing list (not only a piclist.com member) to post to the piclist. This form requires JavaScript and a browser/email client that can handle form mailto: posts.
Subject (change) os/wars - a compilation - was Re: SoNoboby knows

month overview.

new search...