IPC@CHIP® RTOS-LNX – API Documentation
RTOS RTX API overview
The IPC@CHIP® Message Exchange Manager provides a mechanism for interprocess communication and synchronization. In particular, it offers an instant solution to a common producer/consumer problem:
An often cited example of using Message Exchange is a print request queue. Assume that there are two different server tasks (consumers), each of which is connected to a different printer. There are some other tasks (producers) which want to asynchronously use one of the two servers for printing and they don't care which of the two printers is used. The solution is to synchronize those requests: The producer tasks send their requests (messages) to the Message Exchange Manager. The two server tasks waiting for messages take a message (if any) from the message queue and execute the requested print job.
The Message Exchange Manager uses a Message Exchange to deliver messages. A Message Exchange consists of four mailboxes into which messages can be deposited. The mailboxes are ordered according to priority (0-3), where mailbox 0 has the highest priority. The maximum depth of a mailbox is specified when the Message Exchange is created, which indicates the maximum number of messages which can be stored in that particular mailbox.
Messages are delivered to the mailboxes of the Message Exchange in message envelopes. The system's maximum number of available messages envelopes is 256. The kernel requires two general purpose kernel objects to construct a Message Exchange. The are 1000 total kernel objects in the system, from which timers, semaphores and Event Groups are also created (one general purpose object per kernel object, except for Message Exchanges which require two).
The message length is always 12 bytes. The message format is designed by the application programmer. (Note: Larger messages can be implemented with a pointer and a length parameter in the message.)
Any task, timer procedure or Interrupt Service Procedure (ISP) can send a message to a Message Exchange. The sender indicates the priority of its message (0-3), thereby identifying the mailbox into which the message will be delivered.
Any task or timer procedure can request a message from a Message Exchange, but only tasks are allowed to wait for the arrival of a message, if none is available. A task can specify the maximum time that it is willing to wait for a message. When more than one message is available at the exchange, a task requesting a message will be given the message at the head of the highest priority non-empty mailbox FIFO (of which there are four).
The task also specifies a priority at which it should receive the next message, allowing either for that task to cut in line ahead of other tasks that were waiting at the same message exchange or to yield to other tasks that later come looking for a message with a higher wait priority (lower numeric value). So conceptually, there are 2**32 FIFO priority queues at each Message Exchange where tasks wait for a message. When a message becomes available, this message will be handed to the first task waiting in the highest priority non-empty task wait queue.
What can be confusing here is that there are two concepts of priority involved in Message Exchanges (neither of which is related to task priority).
When task synchronization is not a requirement, interprocess communication may also be accomplished with the public data API.