1

UNIT-4
Message Queues, Mailboxes and Pipes:

❖ Basic techniques for inter-task communication and data sharing are: interrupt

enable/disable and using semaphores. E.g., the tank monitoring tasks and serial port
and printer handling tasks

❖ Others supported by RTOS: Message Queues, Mailboxes and Pipes

❖ Example of Message Queue:

❖ Task1 and Task2 (guaranteed to be reentrant) compute separate functions

❖ Use services of vLogError and ErrorsTask (vLogError enqueues errors for ErrorsTask

to process)

❖ vLogError is supported by AddToQueue function, which keeps a queue of integers for

the RTOS to interpret or map to error-type. Using the ReadFromQueue function, the
RTOS then activates ErrorTask to handle the error if the queue is not empty – freeing
Task1 and Task2 to continue their tasks.
❖ Functions AddToQueue and ReadFromQueue are non-reentrant, and the RTOS

switches between Task1 and Task2 in the middle of their tasks execution are
guaranteed to be ok.

EMBEDDED SYSTEMSJP
 2

EMBEDDED SYSTEMSJP
 3

❖ Difficulties in using Queues:

❖ Queue initialization (like semaphore initialization) must be dedicated to a separate

task to a) guarantee correct start-up values and b) avoid uncertainty about task
priorities and order of execution which might affect the queue’s content

❖ Queues must be tagged (identify which queue is referenced)

❖ Need code to manage the queue (when full and empty) if RTOS doesn’t – block

reading/writing task on empty/full, plus returning an error code

❖ RTOS may limit the amount of info to write/read to queue in any single call

EMBEDDED SYSTEMSJP
 4

EMBEDDED SYSTEMSJP
 5

❖ Using Pointers and Queues:

❖ Code in above Figure limits the amount of data to write to or read from the queue.

❖ For tasks to communicate any amount of data, create a buffer and write the pointer to

the buffer to the queue. (The receiving task reads/retrieves data from the buffer via
the pointer, and frees the buffer space.)

EMBEDDED SYSTEMSJP
 6

EMBEDDED SYSTEMSJP
 7

Using Mailboxes:
❖ Purpose is similar to queues (both supporting asynchronous task

communication)

❖ Typical RTOS function for managing mailboxes – create, write, read,

check-mail, destroy

❖ Variations in RTOS implementations of mailboxes

❖ Either a single-message mailbox or multi-message mailbox (set # entries at

start)

❖ # of messages per mailbox could be unlimited, but total # in the system could

be (with possibility of shuffling/distributing messages among mailboxes)

❖ Mailboxes could be prioritized.

Examples: (from the RTOS – ​MultiTask!​ )

int sndmsg (unsigned int uMbid, void *p_vMsg, unsigned int

uPriority);

void *rcvmsg(unsigned int uMbid, unsigned int uTimeout);

void *chkmsg(unsigned int uMbid);

Using Pipes:

❖ Pipes are implemented as (special) files, using normal file-descriptors

❖ RTOS can create, read from, write to, destroy pipes (typically: each pipe has 2 ends)

❖ Details of implementation depends on RTOS.

❖ Pipes can have varying length messages (unlike fixed length for queues / mailboxes)

❖ Pipes could be byte-oriented – and read/write by tasks depends on # bytes specified

❖ In standard C, read/write of pipes use fread/fwrite functions, respectively

EMBEDDED SYSTEMSJP
 8

❖ Programming queues, mailboxes, and pipes – caution!

❖ Coding tasks to read from or write to intended ‘structure’ (RTOS can’t help on mismatch)

❖ Interpretation and processing of message types (see code segments on p. 182)

❖ Overflow of ‘structure’ size – could cripple the software, so need to set size as large as

possible.

❖ Passing pointers in ‘structures’ provides ‘unwanted’ opportunity to create shared data

problem.

EMBEDDED SYSTEMSJP
 9

Timer Functions:

❖ Issues:

❖ Embedded systems track time passage, hence, need to keep time (e.g., to save battery

life, power need to be shut off automatically after, say, X seconds; a message
send-task expects an ACK after Y seconds, it is delayed Y seconds and may
retransmit; task is allowed a slice of time after which it is blocked).

EMBEDDED SYSTEMSJP
 10

❖ How long is delay – measured in ticks (a tick is like a single ‘heartbeat’ timer interrupt

time)

❖ RTOS knowledge of time/timer and specifics of nticks or time-interval – relies on

microprocessor’s hardware timer and its interrupt cycles (RTOS writers must know
this!) OR RTOS writers write ‘watchdog’ timers – based on non-standard timer
hardware – and corresponding software interrupts – called each time the software timer
expires.

❖ RTOS vendors provide board support packages (BSP) – of drivers for timers and other

hardware.

❖ Length of a tick – depends on the hardware timer’s design – trade-off.

EMBEDDED SYSTEMSJP
 11

❖ Accurate timing – short tick intervals OR use dedicated timer for purpose.

Other Timing Services (all based on system tick):

❖ Waiting time or delay on message, on a semaphore (but not too tight for high priority

tasks to miss access to shared data)

❖ Place ‘call to’ or ‘activation of’ time-critical, high priority tasks inside timer interrupts

or specialized-time-critical tasks inside the RTOS (Note: OS task have higher priority
over other embedded software tasks).

❖ Calling a function of choice after some S nticks.

❖ Example:​ The Timer Callback Function

❖ Note how wdStart function is passed a function – vSetFrequency or vTurnOnTxorRx,

associated nticks, and the parameter to the function. Also note how the
vRadioControlTask communicates with vTurnOnTxorRx and vSetFrequency using
the queue ‘queueRadio’ and msgQreceive/msgQSend).

EMBEDDED SYSTEMSJP
 12

EMBEDDED SYSTEMSJP
 13

EMBEDDED SYSTEMSJP
 14

EMBEDDED SYSTEMSJP
 15

EMBEDDED SYSTEMSJP
 16

Events:

❖ In standard OS, an event is typically an indication which is related to time

❖ In RTOS, an event is a boolean flag, which is set and reset by tasks/routines for other
tasks to wait on
❖ RTOS is supposed to manage several events for the ‘waiting’ tasks. Blocked or
waiting tasks are unblocked after the event occurrence, and the event is reset
❖ E.g., pulling the trigger of a cordless bar-code scanner sets the flag for a waiting task,
which turns of the laser beam for scanning, to start running

❖ Features of events (and comparison with semaphores, queues, mailbox, pipes):

EMBEDDED SYSTEMSJP
 17

❖ More than one task can wait on the same event (tasks are activated by priority)

❖ Events can be grouped, and tasks may wait on a subset of events in a group

❖ Resetting events is either done by the RTOS automatically or your embedded

software

❖ Tasks can wait on only one semaphore, queue, mbox or pipe, but on many events

simultaneously.

❖ Semaphores are faster, but unlike queues, mboxes, and pipes, they carry 1-bit info

❖ Queues, mboxes, and pipes are error prone and message posting/retrieval is
compute-intensive.

EMBEDDED SYSTEMSJP
 18

EMBEDDED SYSTEMSJP
 19

EMBEDDED SYSTEMSJP
 20

EMBEDDED SYSTEMSJP
 21

Memory Management:

❖ In general RTOS offer C lang equivalent of malloc and free for MM, which are slow
and unpredictable
❖ Real time system engineers prefer the faster and more predictable alloc/free functions
for fixed size buffers. E.g., ​MultiTask! RTOS allocates pools of fixed size buffers,
using

❖ getbuf() [with ​timed task blocking on no buffers] and reqbuf() [with no blocking and

return of NULL pointer on no buffers]

❖ relbuf() to free buffers in a given pool (buffer pointer must be valid)

EMBEDDED SYSTEMSJP
 22

❖ Note that most embedded sw is integrated with the RTOS (same address space) and
the ES starts the microprocessor; hence your ES must tell the memory-pool

EMBEDDED SYSTEMSJP
 23

EMBEDDED SYSTEMSJP
 24

Interrupt Routines in an RTOS Environment:

❖ Rules that IR’s must comply with (but not a task code).

❖ Rule 1: an IR can’t call RTOS function that will cause it to block, e.g., wait on
semaphores, ​reading empty queues or mailboxes, wait on events to avoid high latency
or large response time and potential deadlock.

EMBEDDED SYSTEMSJP
 25

EMBEDDED SYSTEMSJP
 26

EMBEDDED SYSTEMSJP
 27

❖ Rule 2: an IR can’t call RTOS functions that will cause the RTOS to switch other
tasks (except other IR’s); breaking this rule will cause the RTOS to switch from the
IR itself to handle the task, leaving the IR code incomplete or delay lower priority
interrupts.

EMBEDDED SYSTEMSJP
 28

❖ One solution to Rule 2:

❖ Let the RTOS intercept all the interrupts, aided by an RTOS function which tells the
RTOS where the IRs are and the corresponding interrupt hardware
❖ The RTOS then ‘activates’ the calling IR or the highest priority IR
❖ Control returns to the RTOS, and the RTOS scheduler decides which task gets the
microprocessor (allowing the IR to run to completion).

❖ Second solution to Rule 2:

❖ Let the IR call a function in the RTOS to inform the RTOS of an interrupt
❖ After the IR is done, control goes back to the RTOS, where another function calls the
scheduler to schedule the next task.

❖ Third solution to Rule 2:

❖ Let RTOS maintain a separate queue of specialized, interrupt-supporting functions

which are called by the IR (on the appropriate interrupt). When these functions
complete, control goes back to that IR.

EMBEDDED SYSTEMSJP
 29

❖ Nested Interrupts

❖ If a running IR is interrupted by another (higher) priority interrupt (kind of interrupt

stacking), the RTOS should unstack the IR’s to allow all IR’s to complete before
letting the scheduler switch to any task code.

EMBEDDED SYSTEMSJP