Page 262 - Embedded Microprocessor Systems Real World Design

Communication Between Tasks

In the protocol converter example, the receive task puts output data in a common
FIFO buffer. If an RTOS is used, the data normally are passed through the RTOS.
The RTOS may support semaphores, buffers, queues, and mailboxes.
An RTOS semaphore is similar to the key-press flags or semaphores used in the
pool timer. A task asks to set the semaphore, and another task can wait on the
semaphore or possibly reset it. Setting a semaphore can activate a task. The differ-
ence in an RTOS system is that all access to the semaphore is passed through the
RTOS. This is a distinct advantage over non-RTOS scheduling since it prevents
possible race conditions and other timing problems from two processes trying to
access the same communication memory locations at the same time.
An RTOS buffer is just like the FIFO buffer used in the protocol converter except
that the RTOS manages it. If the protocol converter uses an RTOS, the receive task
requests a buffer from the RTOS, puts the data to be transmitted in the buffer, arid
tells the RTOS to pass the data to the output task. The output task typically receives
pointers to the buffer, telling it where the buffer is in memory and how many bytes
(or words or whatever) there are.
A queue is a string of buffers. If the protocol converter worked on a message
basis, outputting data only when a complete message is received, a queue could be
used for this. The receive process could place a message in a buffer and pass the
buffer to the output task. The output device might be busy when the next message
is ready. Thus, the receive task asks the RTOS to put the next message into a queue,
where the output task processes the messages in the order they were received once
the output device becomes ready.
In a mailbox structure, a task typically receives mail from several other tasks, just
like you do at home. The RTOS manages the mailboxes, storing messages for a task
until the task is ready to read them. Like a physical mailbox, once a task sends a
message, it cannot take it back. Depending on the RTOS, a task may check for mail
and wait if there is none, like you did when you were a kid expecting a package to
arrive. An RTOS usually supports multiple mailboxes per task, as if you had a
mailbox at home and several boxes at the post office.
Figure 9.3 summarizes RTOS communication. In Figure 9.3A (RTOS buffer),
Process A transfers data to Process B via a buffer. In Figure 9.3B (RTOS queue),
Process A filled buffers (queues) 1 and ‘2 and is filling buffer 3. Process B is taking
data from buffer 1. Figure 9.3C is an RTOS mailbox. Processes A, B, and C are
placing data in a common mailbox for Process D. Each message from each process
is stored separately, like physical letters, each in its own envelope. Like when you
sort through your mail at home, opening important letters first, the RTOS typically
allows the sending process to assign a priority to the message for the receiv-
ing task.

Real-Time Operating Systems 243