Page 255 - Embedded Microprocessor Systems Real World Design

the keypad. Again, these tasks are very simple, and the longest processing time for
the most complicated task is still too short to be a problem.
But imagine a system that is controlling an automated assembly line. There might
be code that sorts the incoming material, adjusts the temperature of processes,
regulates the speed of the motors that move objects down the line, and tests the
finished products, rejecting any that are bad. In such a system, the temperature
control might have a fairly long delay, so it could take a while to get the tempera-
ture right. If the temperature routine sets the temperature and then waits to see
what happens, all the other functions are held up in the meantime. In other words,
the processing time for one task affects the ability of others to do their jobs.
A second problem with sequential task ordering is that all tasks have the same
priority. In the assembly line example just mentioned, imagine that the assembly
line gets jammed. The code that handles the jam and shuts down the line should
take priority over everything else.
Actual sequential scheduling systems, of course, do not really assign tasks that
way. The temperature process would not keep control of the system but would
adjust the temperature and check it again the next time it is executed. However,
the concept is still valid-handling a jam may take priority over the temperature,
regardless of how far out of tolerance it is.
A third potential problem with sequential scheduling is the sheer number of
tasks. If the number of tasks in the system is too large, it may be impossible for the
system to keep up with processing demands, even if each individual task takes little
time. Each task in a sequential arrangement requires a certain amount of time to
execute, even if it is just checking to find out that it has nothing to do. The com-
munication protocol converter mentioned in Chapter 3 is an example of this. The
output code checks for buffer not empty. If the buffer is not empty, it proceeds to
check for interface ready. If the interface is ready, it sends a byte. If it has nothing
to transmit or if the interface is not ready, the code passes control to the next task.
But even if the process cannot send because there are no data or because the output
device is not ready, checking for these conditions takes time.
That protocol converter had four very simple tasks: receive data processing,
XOFF processing, output processing, and XON processing. One way to handle task
scheduling would be to have each task active only when needed. Receive data
processing might get a byte and put it in the first in, first out (FIFO) buffer. It then
activates the output task. XON and XOFF are inactive. So the program loop trans
fers control from receive to output and back, skipping over XON and XOFF and
their minimal checks. Then suppose that enough receive data are placed in the
buffer to require an XOFF be sent to the host. The receive process detects this con-
dition and activates the XOFF process. The XOFF process remains active, waiting
for the interface to the host system to be ready and then transmitting the XOFF
byte. The program loop would then be receive-XOFF-output-receive and so on.
Once XOFF completes its task (sending XOFF), it deactivates itself, and the loop

236 Embedded Microprocessor Systems