gnupic: Re: [gnupic] seek opinion re multitasking
Subject:
Re: [gnupic] seek opinion re multitasking
From:
"Robert J. Lee" ####@####.####
Date:
1 Feb 2005 12:57:26 +0000
Message-Id: <200502011257.15698.kiki@rjlee.dyndns.org>
On Sunday 30 Jan 2005 00:25, David McNab wrote:
> Hi GnuPic'ers
>
> Need some opinions here.
>
> Development of Pic18Forth continues to surge, with the current dev
> version (not yet released) now having throw/catch exception handling,
> dynamic memory allocation and inline assembly.
>
> Now, I'm thinking about multitasking.
>
> Since Pic18Forth is VM-based, there's some good opportunities and
> flexibility for implementing multitasking, with several different
> schemes possible.
>
> Minimal 'task control block' could contain as little as just the current
> IP, return stack pointer and data stack pointer.
>
> Options are:
> 1) No multitasking - 'desire for multitasking reflects poor software
> design'
>
> 2) Voluntary round-robin - threads explicitly invoke a 'task-switch'
> function to voluntarily relinquish control of the CPU and allow another
> task to run - also, potentially blocking functions such as 'get char
> from tty' imply a task switch.
>
> 3) Task-as-event-handler - each task is dispatched like an event
> handler, and is expected to terminate promptly
>
> 4) Pre-emptive task switching - the bytecode execution loop may
> context-switch at any time before executing the next bytecode.
>
> What is your preferred tasking model for PIC programming?
1) is not a valid argument IMHO. You need multitasking whenever you have
potentially blocking inputs, in order to use the processor (or
microcontroller) most efficiently. It also lets you reduce the overall system
cost by giving more than one processing requirement per PIC in a multi-PIC
system. (I might agree with that if adding an extra PIC to a circuit incurred
zero cost.)
Personally, I tend to use 3) for lower-end PIC designs because it doesn't
steal any interrupts, and you don't have to worry about things like resource
locking (as you know exactly when process switches can occur). Also, I don't
tend to bother doing any of (register) context-switching, just allocating
individual processor registers to processes as needed. This approach seems to
work quite well for state-machine type program designs, although you do have
to be careful with instruction-counts if timing is critical.
I tried to use 2) but I found that (at least for my designs) I tended to end
up with a group of short, discrete functions anyway (doing serial I/O in
parallel with everything else meant that there was never any long time to run
a process for). So 3) was easier to implement.
I guess 4) would be useful when converting code from larger processors to run
on PICs, or possibly when using higher-end PICs that don't have such limited
memory.
