Yes, multitasking is quite possible without interrupts and I have written
some "cooperative" code on the 12c672 platform (i didn't use interrupts
specifically because they were asynchronous, therefore I really had no
idea exactly when they were happening).  My application was generating a
28kHz PWM ouput in sofware while simultaneously monitoring an analog input
and a digital input (PWM enable/disable), and setting some digital outputs
based on the analog input. Whew!  I used the internal oscillator and the
PWM output was limited 40%.  So each cycle was 1us and I had to fit litle
pieces of the non-PWM code in between.  I did this mostly by writing
routines in blocks that had a fixed execution time no matter what there
side-effects or results were. (i.e. very clever padding with nops or by
calling pause functions etc [depending on the time length])




On Sat, 15 May 1999, Graeme Smith wrote:

> I have been working on such a machine....
>
> As near as I can tell the only real benefit an interrupt gives you, is
> the ability to do instantaneous changes in context. You can get much the
> same effect without an interrupt simply by planning your code so that it
> always takes the same amount of time, to execute, for each portion of a
> task you have it do.
>
> Instead of getting instantaneous service, you get essentially, a known
> delay time between the mainline code, and the service routine. If you use
> a cooperative system that leaves the processor in a known state, or
> dedicate some registers to saving the context for each task, you can
> manage less instantaneous but certainly timely effects that would be hard
> to tell from an interrupt.
>
> The absolute minimum multi-tasking system, for such a processor would of
> course be the simple round robin sequencer, which gives each task its own
> time slice. By designating one task as a foreground task, and the other as
> a background task, you can signal the need for a supporting background
> task to be launched from your main application in the foreground.
>
> A perfect example of this, is spooling, which is a background task that
> runs the printer, while the foreground tasks, are ongoing.
>
> Each time the spooling task is called, it sends another small string of
> characters to the printer, then returns control to the main task. The main
> task, runs for a period, and then returns control to the sequencer, which
> can call the spooler, or another background task, such as garbage clean
> up, to take care of the print buffer after the data has been printed.
>
> In such a two task system control passes back and forth between the tasks
> in an oscillating effect, advancing both of them just as easily as one.
>
> The main difference between this and an interrupt driven system, that does
> two tasks at the same time, lies in the design of the code to be packaged
> in standard length snippets, rather than running any code at all, and
> using the interrupt to switch contexts.
>
> Such programs where the coding co-operates, is called co-operative
> multi-tasking rather than standard multi-tasking, and requires a bit more
> sophistication of the programmer, in order to make more efficient.
>
>                                         GREY
>
> 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 Mon, 10 May 1999, Seyler Jean-Yves wrote:
>
> >                 Hello all PICers,
> >
> >         Some time ago, there has been a discussion about multitasking and
> > solutions have been proposed with interrupts ...
> > Does any of you has an idea of a multitask kernel (2 tasks should cover
> > most applications) without usong interrupt facilities in order to be put
> > on a PIC 12C509 for example ?
> >
> > Thanks
> >
>