IPC@CHIP Documentation - SC12 @CHIP-RTOS V1.10

Top of list
Index page
allows more than one task to simultaneously wait for a particular event. Tasks can also wait for a
particular combination of events or for any one in a set of events.
The Event Manager provides a set of event flags which can be associated with specific events in your
system. These event flags are provided in groups with 16 event flags per group. The number of event
groups which can be created is limited by the 60 kernel objects available. One kernel object is expended
to create a semaphore, event group or timer procedure.
The Event Manager is useful when two or more tasks will wait for the same event, e.g. waiting for the
start of a motor. An event flag is defined to represent the state of the motor (off or on). When tasks must
wait for the motor, they do so by calling the Event Manager requesting a wait until the motor control event
flag indicates that the motor is on. When the motor control task or timer procedure detects that the motor
is on, it signals the event with a call to the Event Manager. The Event Manger wakes up all tasks which
are waiting for the motor to be on. For further explanations read the function description in the API call
specifications.
Event Services:
RTX_CREATE_EVENTGROUP Create an event group
RTX_DELETE_EVENTGROUP Delete an event group
RTX_SIGNAL_EVENTS Signal one or more events in a group
RTX_WAIT_EVENTS Wait for all/any of a set of events in a group
RTX_GET_EVENTGROUP_STATE Read current state of events in a group
RTX_GET_EVENT_FLAGS Get saved event flags
RTX_FIND_EVENTGROUP Find the group ID of an group with a specific name
Message Exchange Manager
The internal @CHIP-RTOS Message Exchange Manager provides a mechanism for interprocess
communication and synchronization. In particular, it offers an instant solution to a common
producer/consumer problem:
One or more processes (producers) having to asynchronously deliver requests for service to one
or more servers (consumers) whose identity is unknown to the producer.
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 internal 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. Maximum depth of a mailbox is four.
Messages are delivered to the mailboxes of the message exchange in message envelopes. The
system's maximum number of available messages envelopes is 64. The maximum number of message
exchanges is ten. The maximum message length is 12 bytes. (Note: Larger messages can be
implemented with a pointer and a length parameter in the message.) Any task or timer procedure can
send a message to a Message Exchange. The sender indicates the priority of its message (0-3), thereby
identifying the mailbox into which it 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 priority at which it
Page 234 / 400