Thomas wrote:
> What I want to avoid is to have one task
> waiting for two or more tasks to finish.

Why do you care?  As long as your latency spec is met, it shouldn't make any
difference what the processor was doing before each task got run.

Do these tasks all respond to the same external event, or different ones, or
each other?  It seems like you are making this way too complicated.  You've
already shown that the PIC has about 3x more cycles than all the tasks
require, so the rest is just making sure no one tasks hogs the processor too
long for the other tasks to meet their latency requirements.

In my opinion, a full RTOS is overkill and undesirable on a PIC.  In fact
it's not even strictly possible on all but the 18 and 30 families.  It is
sometimes useful to have separate tasks managing specific inputs or outputs,
like handling a command stream from a host.  On the PIC 16 and 18, I have
the main event loop run each task once after no other events were found that
needed processing.  Each task is a subroutine that returns when a timeslice
has completed, which takes it back to after the call in the main loop.

On the 30 family I sometimes don't use a main loop, and everything is done
with tasks.  When a task has nothing to do, it calls TASK_YIELD, which
causes the next task to run.

In your case, the first task would run for 1mS, then give up its timeslice.
This runs the second task for 1mS followed by the third task for 1mS.  After
that there would be lots of very quick task swaps while each task detects it
has nothing to do and yields the processor.  Eventually one of the tasks
will detect something to do, crank for 1mS, then yield the processor.  Where
do you need an RTOS in all this?

> I am trying to write my own [OS].

Sounds like a waste of time, and then you end up with a white elephant not
appropriate to a PIC anyway.  All you really need is a simple way for a task
to yield the processor to whatever the rest of the code wants to do next.
One example is in my QQQ_CMD.ASPIC module at http://www.embedinc.com/pic.
The GETBYTE macro makes it appear to the task code that it goes and "gets"
the next input byte from the host.  What it really does is return to the
main event loop, which runs the task again the next time it gets around to
it and there is a new input byte available from the host.  Note that GETBYTE
must only be called from the top task level (not in a subroutine) since the
call stack can't be accessed on a PIC 16.  I've got a version for the PIC 18
that performs some unnatural acts on the stack to loosen this restriction,
but I don't think it's on the web site yet.

> All I
> am looking for was to see if there is any way I can
> write the OS so that it spaces out the tasks to avoid
> having too many waiting tasks at the same time.

Again, why?  Is this some asthetic issue?  What are the real time
requirements of each task?


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu