Embedded Systems September 2000 Vol13_10

Issue link:

Contents of this Issue


Page 55 of 229

FIGURE 4 Tasks waiting on a semaphore Semaphore 0 - Highest priority Lowest priority tan t task to execute. A proce sor's con- text generally consists of me volatile state of a processor. For d1e Z80, lie con text consists of the following regis- ters: AF, BC, DE, HL, AF', BC' , DE', HL', IX, IY, SP, and PC. In other words, if you want to stop execution of one task and resume execution of anod1er task, you need to save the con- text of the first task onto its stack and restore the context of the task you wish to execute from its stack. A context switch for the Z80 is shown 'A task suspending itself A Task #1 calls osnmeDiy(1) ~ f~ !!C/05-11, OSTimeDiy() (S !!CIOS-11 , OSSched() !!C/OS- 11 , OSCtxSw() Task #2 resumes execution - Time to switch to a higher priority task Task #1 is suspended until delay expires Task #2 is ready to run in Figure 6. It is assumed d1at the kernel maintains pointers to the TCB of d1e running task (task to suspend) and me new task (task to resume) . A context switch starts by saving d1e processor's context onto the 1unning task's stack (1). The processor's SP register (new TOS) is then saved in the TCB of the task to suspend (2). The task's TOS is retrieved from the new task's TCB and placed in the processor's SP register (3) . Finally, me processor registers are restored by popping d1em from the stack ( 4). At this point, the new task code continues execution as if it had never been suspended. Listing 3 shows the pseudo-code for the curren t (running) task is no longer able to run. Figure 3 shows how TCBs can be organized in the ready list. The singly linked list is only shown to demonstrate the concept. Kernel designers have devised more efficient ways to main tain a ready list. The kernel also maintains a num- ber of Wait Lists. A task can wait on kernel objects such as a semaphore, mailbox, message queue, or pipe. Each of these objects contains state informa- tion. For example, a semaphore con- tains a value indicating whether d1e semaphore is available or not, as well as a list of tasks waiting on d1e sema- phore, provided the semaphore is cur- rently owned by a task. Figure 4 shows a list of tasks waiting on a semaphore. Again, the singly linked list is shOW11 mainly to illustrate the concept. Figure 5 shows me execution pro- file of a servi ce, OSTi meDLyO, provided by an kernel d1at I developed a few years ago, called pC/ OS-II. In the example, Task 1 is executing and calls OSTimeDLyO to suspend execution of Task 1 for one system tick. A system tick is generally created by a timer chip that interrupts the CPU and occurs at a fixed interval (1 Oms to lOOms, depend- ing on the application ) . A task calling OSTimeDLyO is placed on a list of tasks waiting for time to expire. OSTimeDLyO calls OSSchedO, which is another kernel function d1at finds the next most important task that is ready to run. Once found, OSSchedO calls OSCtxSw( ), which performs a context switch to this task. What's important to note here is that d1ese functions take time to execute, so the processor should execute these as quickly as possible. The kern el pe rforms a context switch when it determines that the cur- rent task is no longer the most impor- 54 SEPTEMBER 2000 Embedded Systems Programming me above ope ration. Note that it's assumed that the PC register is already on the TOS of the task to suspend. A context switch takes about 426 clock cycles on a Z80 (17~L at 25MHz). Kernel requirements Kernels can be designed to work with just about any proces or. In fact, a ker- nel requires very few features from a processor. However, to run a preemp- tive kernel, a processor must be: • Able to disable and enable inter- rupts • Able to access a large stack area • Able to load and store the proces- sor's stack pointer • Able to save and restore the proces- sor 's context onto/ from the stack • Able to easily manipulate pointers The Z80 and its derivatives support all of these requirements .

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems September 2000 Vol13_10