>
>   Is there a way to read the stack .

Nope.

 I am designing a multitasking
> interface for more than two jobs , not necessarrily counters or built in
> kkind of stuff .
>   The only problem is reading stack to return from jobs at the correct
> order . Example :
>   Assume ther are three jobs : Namely job1 ... etc
>   Order is job1 . job2 . job3 . job1 ... going on .
>   The time for jobs is got from built in tmr0 interrupt . But I am not
> able to make the system turn back to correct job , in correct order .
>   The place of return is important of course . So by a technique I must
> store the return adress ...
>   Does anybody know a technique to do this ?

Several. Most require that you maintain your own external software stack
and not to use the call/return interface. Essentially you build a state
machine where the state variable is accessible. Upon encountering an event
the state is changed. The next time the state machine is invoked you can change
states. So for example of your jobs could be written:

jobX()
{
   while (1) {
      goto check_state();
      do_task();
   }
}

check_state()
{
   if (state == 1)
      goto job1
   else if (state == 2)
      goto job2
   else if (state == 3)
       goto job3
}

Note that none of these routines are actually called but implemented with
gotos. Yes there is a latency because if a job is in the middle of its task
the switch will not occur until the task is complete. To combat this the
task should check the state variable (or a changed state flag) often and
wrap up if the state changes.

The interrupt routing (for the timer for example) would change the state
variable and the state flag.

Obviously this concept breaks down in the face of dynamic adding/deletion
of tasks. But for simple fixed scheduling it does work. Also issues have
to be worked out if you have the same task executing multiple times each
with different data too.

Access to the hardware stack is one of the few things I actually wish for
in a PIC. Two registers accessing the top of the stack would have been
more than enough.

BAJ

>