PIC specific Multitasking@
Whenever you have multiple tasks on a single CPU, you have to ``context switch'' between the tasks. Task switching is changing the focus of the processor from one ``task'' (process) to a an independent task. If this is done often enough, you can make one CPU ``multitask'', appear to work on several independent things at once. The ``task switcher'' is the most basic part of a multitasking OS kernel.
Each task has a "main loop" of stuff it does over and over. The differences between various flavors of multitasking come down to when exactly we switch from one task's main loop to the next task's main loop.
If we can switch at practically any time (typically triggered by an interrupt), that's pre-emptive. The interrupt routine needs to be careful to save the status word and other crucial registers, and when it switches tasks it needs to preserve the stack ...
If we only switch at certain points in the task, when the task specifically calls or returns to the multitasking kernel (i.e., when the task has reached a "good stopping point"), that's co-operative.
If we only switch when we know the stack is empty, then we never need to save the stack. [FIXME: is there a name for this restricted co-operative multitasking flavor ?] This makes the "context-switching overhead" is lower (which is good). But the tradoff is when some subroutine takes a really long time before it returns to the multitasking kernel, all the other tasks have to wait until it is done.
For small systems where the programmer has complete control of every task, cooperative multitasking can be superior to pre-emptive multitasking. In other situations, pre-emptive multitasking is superior .. but unfortunately, I'm pretty sure it's impossible to implement pre-emptive multitasking on 12x and 16x series PIC chips. On 18x series, apparently it is possible.
Umm... there's probably a simpler way to explain this.
Priority handling can be done in a couple of ways:
1. A single linked list queue. This allows many different priorities and avoids the need to diminsion each que for the largest possible size.
2. Several queues - one for each priority. This allows you to have low/medium and high priorities. The code runs FAST - a queue insert doesn't have to traverse linked lists! You can also dimension each queue separately.
make sure that your queue pointers or indexes can survive "simultaneous" accesses from both foreground & interrupt level!
This means do NOT do something like:
next_free++ if (next_free == LIMIT) next_free= 0;
but do ....
temp = next_free; temp++; if (temp == LIMIT) temp = 0; next_free = temp;
This ensures that any other "parallel" code peeping at next_free will never see the transient illegal value of LIMIT.
Make the shared pointers volatile.
Ensure you don't make dumb mistakes with the que array like referencing QUE_ARRAY_SIZE rather then QUE_ARRAY_SIZE-1 when the que is zero based, or indexing element 0 when the array is based at one. Those sorts of errors cause intermittent failures that are very difficult to debug.
|file: /Techref/method/multitask.htm, 5KB, , updated: 2007/8/24 09:12, local time: 2024/2/22 14:03,
|©2024 These pages are served without commercial sponsorship. (No popup ads, etc...).Bandwidth abuse increases hosting cost forcing sponsorship or shutdown. This server aggressively defends against automated copying for any reason including offline viewing, duplication, etc... Please respect this requirement and DO NOT RIP THIS SITE. Questions?
<A HREF="http://www.sxlist.com/techref/method/multitask.htm"> Multitasking</A>
|Did you find what you needed?
Welcome to sxlist.com!
& kind contributors
just like you!
Please don't rip/copy
Copies of the site on CD
are available at minimal cost.
Welcome to www.sxlist.com!