Searching \ for 'Multitasking without interrupt ?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ints.htm?key=interrupt
Search entire site for: 'Multitasking without interrupt ?'.

Truncated match.
PICList Thread
'Multitasking without interrupt ?'
1999\05\10@104703 by Seyler Jean-Yves

flavicon
face
               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

1999\05\10@121429 by Barry King

flavicon
face
Jean-Yves,

> Does any of you has an idea of a multitask kernel (2 tasks should cover
> most applications) without using interrupt facilities in order to be put
> on a PIC 12C509 for example ?

Are you looking for a commercially built kernal?  Or are you looking
for ideas on how to structure code to multi-task?

If you are asking for ideas, we need to know more about what the tasks
will do.  To multi-task without interrupts, you will end up with a
main loop which calls the tasks, or portions of them.  The taks must
be structured to run for some time, then let another task run. And
there will usually be some other code to coordinate any shared
variables or communication between the tasks.

Two important things are to know how the tasks must communicate, and
whether there is hardware that they must share.  Also, it is
important to know what latency is acceptable, that is, how long can
one of the tasks be stopped before it fails?

------------
Barry King, KA1NLH
Engineering Manager
NRG Systems "Measuring the Wind's Energy"
Hinesburg, Vermont, USA
spam_OUTbarryTakeThisOuTspamnrgsystems.com
"The witty saying has been deleted due to limited EPROM space"

1999\05\10@143239 by John Payson

flavicon
face
|        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 ?

Here's a nice simple method, assuming one of the tasks will fit within
256 bytes of codespace, won't call subroutines more than 1-deep, and no
task switch will need to occur within a subroutine.

Define a register called "VirtPC".  When it starts up, your main task
should set it equal to the start address of your "alternate" task.  You
should also have a code address called "Springboard" at which is coded:

Springboard:
       movf    VirtPC,w
       movwf   PC

>From the main program, when you want to yield control to the alternate
task you just use the two instructions:

       call    Springboard
       movwf   VirtPC

When your alternate program wants to yield control, it should either do
a

       retlw   $+1

if its execution should resume at the next instruction the next time the
main program yields, or else

       retlw   label

if execution should resume at /label/.

Aside from the restrictions on call depth and the fact that W is trashed
on a context switch, this is probably just about the cheapest little multi-
tasker for ANY CPU platform (5 cycles to switch to the alternate task; 3
to switch back to the main line).  Cute, eh?

1999\05\10@163157 by Harold Hallikainen

picon face
       Though not a PIC application, I did a multitasking system in
Borland Pascal several years ago.  Each task had its own stack space.
When a task finished something or went into a loop waiting for something
else to happen, it called "NextTask."  This pushed the current program
counter on this task's stack, saved the current stack pointer value,
advanced (or cleared if this was the last task) a "task pointer" which
determined which stack to use.  This task pointer then loaded the stack
pointer with the appropriate value for this stack, then did a return.
Each task's stack held variables local to that task and held return
addresses, as mentioned above.  When interrupts occurred, they just used
the current stack, whichever one was active.
       I did a similar thing years earlier with a 6800 processor.  The
"separate stack" idea had not occurred to me yet.  Also, due to limited
memory space, it may not have worked anyway.  Here, each task was a
subroutine.  Prior to exiting the subroutine (going on to the next task),
the "continue address" was stored in RAM.  When we got back to this task,
we always called the first location in the subroutine.  This location had
an indirect jump (good old self modifying code!) to the appropriate
location in the current task.  Another, similar, approach (that could be
used on the PIC) would be to have a byte hold a number representing the
entry point where you want the task to continue.  The top of our task
subroutine would have a jump table the same as we use in a state machine.

       This multitasking approach is really just a state machine.  Each
time the task is called, it evaluates the state variable and picks up
based on it.  Prior to exiting the task's routine, we save an appropriate
value in the state variable.
       Just some thoughts...


Harold




Harold Hallikainen
.....haroldKILLspamspam@spam@hallikainen.com
Hallikainen & Friends, Inc.
See the FCC Rules at http://hallikainen.com/FccRules and comments filed
in LPFM proceeding at http://hallikainen.com/lpfm

On Mon, 10 May 1999 16:36:35 +0200 Seyler Jean-Yves
<Jean-Yves.SeylerspamKILLspamCNES.FR> writes:
{Quote hidden}

___________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com/getjuno.html
or call Juno at (800) 654-JUNO [654-5866]

1999\05\10@165221 by Michael Shiloh

flavicon
face
I am very interested in this as a project. I've worked with some trivial
Multitasking executives in the past, and I currently work at Wind River
Systems, writers of a very popular real time OS for embedded applications.
I would very much like to kick around ideas, to develop code, and to test
ideas. Granted, vxWorks (what we sell) is made for 32 bit high end processors,
so I will have to rethink for the PIC world, but I still think I can
contribute to the project.

If there are objections to using this forum I'd be happy to set up a
mailing list elsewhere for this as a project.

I'm also happy to discuss this privately, if you wish
Michael Shiloh
Wind River Systems
510-749-2171
.....michaelsKILLspamspam.....wrs.com
alternate email at
EraseMEmichaelspam_OUTspamTakeThisOuTsrl.org

1999\05\10@232301 by Mik Kim

flavicon
face
Hi all,

There is Microchip appnote on multitasking (cooperative) with PIC. It's
an585. Although I haven't used it, it seems to do simple things given
limited resources of PIC.

I've been looking for a job lately, and it looks like every embedded
engineering job _requires_ knowledge of VxWorks. Too bad it won't work
with PIC so I can learn, so the job hunt goes on...  ;)

It would be very interesting to see other RTOS for PIC. I wonder how
things will be saved with context switch, especially for low end PICs;
is there enough memory for doing anything useful? I suppose watchdog
timer coule be used in limited sense for time slicing, but it will be
challenging. Please do keep the list updated if anything comes of this.


Michael Shiloh wrote:
{Quote hidden}

1999\05\11@084951 by Seyler Jean-Yves

flavicon
face
       1st : thanks for all answers ...

- Kim for the Microchip AN585 reference but, as far as I have read, it dealt
with interrupts ! ...
- Anyway, let's precise my aim for Barry King who asked me :

{Quote hidden}

I'm looking for ideas for a specific project :

I have to check for serial inputs while out-puting one or more PWM depending
on the input(s).

In fact, my first application should be an attempt to read 1 RC pulsed
command, ie :

1) Measure the "n"st positive pulse among 7 overall pulses ; synchro being
made by a 1st larger pulse and length of the usefull pulse varying between 1
and 2 ms ; overall time = 10 to 20 ms

2) While outputing a PWM at 10 to 100 Hz, from #0 to #100% duty cycle

3) That's all !

4) I've thought of an absolute timing that each individual task could check
and determine if their allowed time have passed. That shouldn't be very
accurate but enough for me ?

Thanks for any other comment !

1999\05\11@103251 by Scott Dattalo

face
flavicon
face
On Tue, 11 May 1999, Seyler Jean-Yves wrote:

> I'm looking for ideas for a specific project :
>
> I have to check for serial inputs while out-puting one or more PWM depending
> on the input(s).
>
> In fact, my first application should be an attempt to read 1 RC pulsed
> command, ie :
>
> 1) Measure the "n"st positive pulse among 7 overall pulses ; synchro being
> made by a 1st larger pulse and length of the usefull pulse varying between 1
> and 2 ms ; overall time = 10 to 20 ms
>
> 2) While outputing a PWM at 10 to 100 Hz, from #0 to #100% duty cycle
>
> 3) That's all !
>
> 4) I've thought of an absolute timing that each individual task could check
> and determine if their allowed time have passed. That shouldn't be very
> accurate but enough for me ?

You may wish to check out:

http://www.interstice.com/~sdattalo/technical/software/pic/pwm256.txt

This an all-software, 256-level pwm routine capable of 0 to 100% duty
cycles. Since it doesn't use interrupts, it's suitable for the 12 bit
core. Roughly half of the 256 cycles are available for other (isochronous)
tasks.

The only problem I can see with it is that it may be too fast for your
application. For example, with a 20Mhz clock this routine can produce a
nearly 20khz pwm'd square wave. I suppose you could slow the pic down a
factor of 200 or so, but I don'tsee this as being too practical.

Another possibility is to use the 16-bit delay loop that we were
discussing just last week. There was one solution that a) created a delay
with 3 instruction cycle resolution and 16-bits of dynamic range and b)
provided additonal cycles for simultaneously performing other tasks. The
number of 'additional cycles' can be varied between 1 to ~240 out of every
256 cycles. In fact, this number could vary depending on the time required
for each task. I unfortunately don't have time to expand upon the details
(gotta go to the Mchip seminar) - perhaps someone else may?

Scott

1999\05\12@042640 by Nuno Pedrosa

flavicon
face
In my (never-ending) meter counter, I used a "micro-routine task sweeper" [I
invented the name, not the concept! 8)]. Anyway, it's a trivial solution, I
think.

I used the 16f84.
All timers are maintained by an Interrupt timer.
Resources are managed through semaphores (which are also used to signal end of
delays.).
Tasks are made to be short. The execution time must be smaller than the maximum
latency to answer to a given event. (This is not very annoying, anyway).
Since, memory is short, all variables are global.
Typical cycles are not closed, but can be. It all depends on the timing
constraints (maximum atomic execution time for each task.).

Tasks are polled in the main cycle. Since resources are handled through
semaphores, tasks can be quite ignorant of what other tasks do. This is quite
useful to change code.

It worked quite well, and allowed for easy change of code, as I added (and
still add) features, and correct bugs.

For instance: PORTB is shared between displays and keyboard.
Display_number is called, and checks the semaphore.
Is PORTB free?
 No, return.
 Yes, set flag, display value, start timer (display).
Read_keyboard is called.
Is PORTB free?
 No, return.
 Yes, set flag, read keyboard, start timer (debounce).

Bye,
Nuno.

Michael Shiloh wrote:
{Quote hidden}

--
----  ~~~~~~~  -------  Nuno Filipe Freitas Pedrosa
--  ~~~~     ~~  -----  SIEMENS S.A. Portugal       TEL: +351 1 4242454
-  ~~~~       ~~  ----  spamBeGoneNuno.PedrosaspamBeGonespamicn.siemens.de
-  ~~~~       ~~  ----  "MSWindows - Best run on a SlideShow"
=======================================================================

1999\05\12@075553 by Seyler Jean-Yves

flavicon
face
               hello Nuno (or Nu–o ?),

Thanks for your answer :-)

My first analysis leads to roughly the same approach. But I still have some
inquiries :

> All timers are maintained by an Interrupt timer.
>
Do you mean you must wait for a timer induced interruption to increment your
several auxilliary timers ?
Remember I must use a 12C509 without an interrupt :-(
Somebody told me I could use a watchdog wakeup ? (but the timing would be :
1st not accurate, 2nd too long)
-> any other idea ?

> Resources are managed through semaphores (which are also used to signal
> end of
> delays.).
>
By "semaphore", I think you mean 1-bit-"flag" at H or L level ?

> Since, memory is short, all variables are global.
>
That was also my way of thinking : no need to use stacks !

> Typical cycles are not closed, but can be. It all depends on the timing
> constraints (maximum atomic execution time for each task.).
>
What do you mean by "cycles are not closed" ?

Thanks for any additional idea ;-)

Jean-Yves

1999\05\12@103841 by Nuno Pedrosa

flavicon
face
Hi!

Seyler Jean-Yves wrote:
>
>                 hello Nuno (or Nu–o ?),

That's Nuno, without ~. I'm from Portugal, not Spain.

> > All timers are maintained by an Interrupt timer.
> >
> Do you mean you must wait for a timer induced interruption to increment your
> several auxilliary timers ?
> Remember I must use a 12C509 without an interrupt :-(
> Somebody told me I could use a watchdog wakeup ? (but the timing would be :
> 1st not accurate, 2nd too long)
> -> any other idea ?

Well, the interrupt based timers, guarantee that time is always correct.
In my case, I use the 16f84 on 8.192MHz. I increment timers with 125us
resolution.

Without interrupts, things get a little more difficult. To keep accurate
timing, you would need isochronous tasks. This means that you need to know how
much time each task takes, and keep timing based on this.

> By "semaphore", I think you mean 1-bit-"flag" at H or L level ?

Yep. Flag 1, resource busy. Flag 0, resource free.

> >
> That was also my way of thinking : no need to use stacks !

Stacks are still a good option with more complex routines. But not on a 12C509.
It would be overkill.

> > Typical cycles are not closed, but can be. It all depends on the timing
> > constraints (maximum atomic execution time for each task.).
> >
> What do you mean by "cycles are not closed" ?

To me, a closed cycle means that the full cycle is executed without
interruption.
Suppose you need to write 10 chars to an LCD: you can send them all at once, or
you can send one, task switch, send another, switch, and so on. The first
approach will be a bit easier to code. The second allows other task to do small
jobs in between.

If you choose to take my approach, try to keep tasks as simple and as short as
possible. The less time they take to execute, the more you will approach to a
multi-tasking environment. 8)

Bye,
Nuno.

> Thanks for any additional idea ;-)
>
> Jean-Yves

--
----  ~~~~~~~  -------  Nuno Filipe Freitas Pedrosa
--  ~~~~     ~~  -----  SIEMENS S.A. Portugal       TEL: +351 1 4242454
-  ~~~~       ~~  ----  TakeThisOuTNuno.PedrosaEraseMEspamspam_OUTicn.siemens.de        
-  ~~~~       ~~  ----  "MSWindows - Best run on a SlideShow"
=======================================================================

1999\05\12@111525 by Nuno Pedrosa

flavicon
face
Seyler Jean-Yves wrote:
>
> Remember I must use a 12C509 without an interrupt :-(
> Somebody told me I could use a watchdog wakeup ? (but the timing would be :
> 1st not accurate, 2nd too long)
> -> any other idea ?
>

Ok. I went look on the 12C509 datasheet.
Here's an idea to keep timings:

You have TMR0, and a pre-scaler. I forgot the kind of timings you needed, so
this may not work for you. It would avoid the assle of making sure that each
task is isochronous....

Imagine this is your main block:

main
 call update_timers
 call task_1
 call task_2
 call task_3
 goto main

TMR0 has a resolution of 1 instruction cycle.
When update_timers is called, it reads TMR0 value, and adds it to the timers.
If a timer reachs the value you wanted or more, set the flag from that timer.
Subtraction might be easier, since you can check flags for a result of zero or
less. In this case, timers start with the value you want.

This kind of timing is accurate over time, but does not guarantee that you act
precisely when the timer ended. There is some jitter. The larger your timers
are, the less important the error becomes.

You do need to guarantee that update_timers is called in less than 255
instructions, before TMR0 rolls over. This can be done with multiple calls to
update_timers, or with small tasks. Your choice.
Pre-scaler can be used if timer resolution is bigger.
This is just an idea, and details must be sorted out. But it seems to be ok, I
think.

Any improvements are welcome! 8)

Bye,
Nuno.

--
----  ~~~~~~~  -------  Nuno Filipe Freitas Pedrosa
--  ~~~~     ~~  -----  SIEMENS S.A. Portugal       TEL: +351 1 4242454
-  ~~~~       ~~  ----  RemoveMENuno.PedrosaspamTakeThisOuTicn.siemens.de
-  ~~~~       ~~  ----  "MSWindows - Best run on a SlideShow"
=======================================================================

1999\05\15@202212 by Graeme Smith

flavicon
face
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: grysmithEraseMEspam.....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:

{Quote hidden}

1999\05\16@120004 by marcel

flavicon
face
Take a look at AN591 apple Descktop Bus app at microchip Works with the time
slice method
I did some debugging on it i think a good example have a look.

Marcel
EraseMEM.v.d.Biltspamfibre.A2000.nl

Graeme Smith wrote:

{Quote hidden}

1999\05\16@161810 by Jamil J. Weatherbee

flavicon
face
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:

{Quote hidden}

1999\05\17@053144 by Dr. Imre Bartfai

flavicon
face
Hi,
only as a small remark: the DOS print spooler (I do not know whether
another ones...) is working on an interrupt basis, as the printer tells
with an IT if the data has been printed, so asks for new data. There is no
time slicing.
Imre


On Sat, 15 May 1999, Graeme Smith wrote:

{Quote hidden}

1999\05\18@193756 by Sean Breheny

face picon face
Hi Imre,

How does it work on PC's without a printer IRQ? I thought I had used it on
ones that probably didn't have a printer interrupt.

Sean

At 11:32 AM 5/17/99 +0200, you wrote:
>Hi,
>only as a small remark: the DOS print spooler (I do not know whether
>another ones...) is working on an interrupt basis, as the printer tells
>with an IT if the data has been printed, so asks for new data. There is no
>time slicing.
>Imre
>
>

|
| Sean Breheny
| Amateur Radio Callsign: KA3YXM
| Electrical Engineering Student
\--------------=----------------
Save lives, please look at http://www.all.org
Personal page: http://www.people.cornell.edu/pages/shb7
EraseMEshb7spamspamspamBeGonecornell.edu ICQ #: 3329174

1999\05\18@201001 by Peter van Hoof

flavicon
face
The dos print spooler polls the parallel port on the timer interrupt, no
interrupt from the printer is needed

-timer interrupt jumps to hooked service routine (about 18 times a second)
-printer status check
-if printer buffer empty send new characters
-if printing done unhook timer interrupt
-jump to original timer service routine
-original timer service routine returns controll to dos till next timer
interrupt

Peter RemoveMEpvhKILLspamspamvertonet.com


{Original Message removed}

1999\05\18@202839 by Sean Breheny

face picon face
Peter,

Thanks for the clarification.

Sean

At 08:07 PM 5/18/99 -0400, you wrote:
{Quote hidden}

| Sean Breheny
| Amateur Radio Callsign: KA3YXM
| Electrical Engineering Student
\--------------=----------------
Save lives, please look at http://www.all.org
Personal page: http://www.people.cornell.edu/pages/shb7
spamBeGoneshb7STOPspamspamEraseMEcornell.edu ICQ #: 3329174

1999\05\19@021011 by Dr. Imre Bartfai

flavicon
face
Hi Sean, I do not know how did it work and whether it did work. PRINT
definitely runs on IT basis (the ACK causes the printer IT).
Unfortunately, the printer IRQ-s (IRQ7 for LPT1 and IRQ5 for LPT2) are
often misused for another things (e. g. some sound cards defaults IRQ7
also) causing funny things when you try to print with PRINT. Such way, the
IRQ seems to be the bottleneck on the PC from my point of view. Of course,
there are also a few printers with serial interface, or you can install a
multitasking environment, and one task prints a normal way (i. e. with
time slicing).  But it is not the printer spooler for the DOS.  I hope
this helped.
Regards,
Imre


On Tue, 18 May 1999, Sean Breheny wrote:

{Quote hidden}

1999\05\19@055916 by Dr. Imre Bartfai

flavicon
face
Hi,
sounds interesting. I would check both statements.
Imre


On Tue, 18 May 1999, Peter van Hoof wrote:

{Quote hidden}

> {Original Message removed}

1999\05\19@093028 by Dr. Imre Bartfai

flavicon
face
Hi,
I must retire. I checked and it seems really so, that PRINT itself does
not use the IRQ of the printer. The following statement has deceived me:
"IRQ 7 [ ... means] data request on LPT1" from Helppc. It seemed logical
for me...
Sorry again.
Imre

{Quote hidden}

> > {Original Message removed}

1999\05\19@094727 by Tjaart van der Walt

flavicon
face
"Dr. Imre Bartfai" wrote:
>
> Hi,
> I must retire. I checked and it seems really so, that PRINT itself does
> not use the IRQ of the printer. The following statement has deceived me:
> "IRQ 7 [ ... means] data request on LPT1" from Helppc. It seemed logical
> for me...
> Sorry again.
> Imre

You guys have it all wrong. This is what really happens :

If a packet hits a pocket on a socket on a port,
And the interrupt controller has a reason to report,
And the packet for your printer has no paper tray to sort,
Then the socket packet pocket has an error and will abort.

--
Friendly Regards          /"\
                         \ /
Tjaart van der Walt        X  ASCII RIBBON CAMPAIGN
spamBeGonetjaartspamKILLspamwasp.co.za  / \ AGAINST HTML MAIL
|--------------------------------------------------|
|             Cellpoint Systems SA                 |
|             http://www.cellpt.com                |
|--------------------------------------------------|
|     http://www.wasp.co.za/~tjaart/index.html     |
|Voice: +27-(0)11-622-8686  Fax: +27-(0)11-622-8973|
|          WGS-84 : 26¡10.52'S 28¡06.19'E          |
|--------------------------------------------------|

1999\05\19@095314 by Fansler, David

flavicon
face
Without a doubt, one of the best pieces of information ever presented here!
ROFL

David V. Fansler
Network Administrator
AutoCyte, Inc.
800-426-2176 Ext. 261
336-222-9707 Ext. 261
.....dfanslerspam_OUTspamautocyte.com <TakeThisOuTdfansler.....spamTakeThisOuTautocyte.com>
Now Showing! http://www.mindspring.com/~dfansler
<http://www.mindspring.com/~dfansler>   Last Updated On April 29,1999
Opinions Expressed Within Are Mine And May Not Reflect Those Of My Employer


               {Original Message removed}

1999\05\19@135444 by Julian Fine

flavicon
face
Tjaart is a poet but he don't knowet
Julian
-----Original Message-----
From: Tjaart van der Walt <TakeThisOuTtjaartKILLspamspamspamWASP.CO.ZA>
To: .....PICLISTspamRemoveMEMITVMA.MIT.EDU <RemoveMEPICLISTspamspamBeGoneMITVMA.MIT.EDU>
Date: 19 May 1999 03:47
Subject: Re: Multitasking without interrupt ?


{Quote hidden}

1999\05\19@171249 by Peter van Hoof

flavicon
face
Actually .... I disassembled the print.exe of dos 6.0 today, just to satisfy
my curiosity (there is nothing much on the net about old technologie) and
print seems to use one of the oldest multitasking mechanisms around (in dos
and windows) the msdos multitask interrupt. and this is timer driven

peter


{Original Message removed}


'Multitasking without interrupt ?'
1999\07\19@152027 by Dwayne Reid
flavicon
face
Way back on 10 May 99, John Payson wtote:

{Quote hidden}

<snip>

I've used state machines to manage multiple tasks in the past and thought
I'd give John's method a try.  The target is a 12 bit core device which
limits my options.

It occured to me that there is a tiny bit more overhead in John's technique
than necessary.  Here is my reasoning.

Anything that modifies PCL on the 12 bit core must live within the first 256
words of a page (512 spaces per page).  Bit 8 of the PC is always cleared.
If the code is small enough to fit in a small device (12c508), you can shave
1 cycle off John's method *and* allow 2 levels of subroutine to be used in
either task.  All you do is set PCL to the entry point of the 2nd task.

The main task looks like this:

;jump to 2nd task.  3 cycle call, 4 cycle return
   movfw       TSK2PC
   movwf       PCL
Tsk2Rtn
   movwf       TSK2PC
;rest of main task


All subtasks are located within the 1st 256 codespaces.  Each subtask ends
with the following:

   movlw       $+2         ;or 'movlw  label' to re-enter somewhere else
   goto        Tsk2Rtn

Thats it!

The downside is that each subtask occupies 1 more codespace than John's method.

Things are a tiny bit more interesting when dealing with a larger 12 bit
core device such as the 12c509.  With both methods, you have to manipulate
the page bit to ensure you end up where you want to be.  When using John's
method, you can simply set the page bit to the proper value so long as
anything else that modifies PCL is on the same page as the 2nd task - it is
still just 8 cycles total since the stack contains the full return address.
If anything changes the page bit, you have to add 2 cycles for a total of 10.

In my case, the 2nd task is going to have to be on the 2nd page since I have
have numerous table jumps in the main task on the 1st page.  I also have to
add the 2 cycles to set and clr the page bit, leaving me with a 9 cycle
context change.  The revised version looks like this:

The main task looks like this:

;jump to 2nd task.  4 cycle call, 5 cycle return
   bsf         PAGE        ;STATUS,5
   movfw       TSK2PC
   movwf       PCL
Tsk2Rtn
   movwf       TSK2PC
;rest of main task


All subtasks are located within the 1st 256 codespaces on page 1.  Each
subtask ends with the following:

   bcf         PAGE
   movlw       $+2         ;or 'movlw  label' to re-enter somewhere else
   goto        Tsk2Rtn

Thoughts, opinions anyone?

dwayne


Dwayne Reid   <TakeThisOuTdwaynerspamspamplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax

Celebrating 15 years of Engineering Innovation (1984 - 1999)

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Do NOT send unsolicited commercial email to this email address.
My posting messages to Usenet neither grants consent to receive
unsolicited commercial email nor is intended to solicit commercial
email.

More... (looser matching)
- Last day of these posts
- In 1999 , 2000 only
- Today
- New search...