Now this module will break down a typical usage case for the main IPC drivers: The sending processor will first call a command function. In this example, the M3 is the sending processor and is executing the “IPCMtoCSetBits” function. g_sIpcController1 is the tIpcController variable which controls the communication between the M3 and C28 IPC interrupt channels. SETMASK_16BIT is the 16-bit mask which indicates which bits should be set, and IPC_LENGTH_16_BITS indicates that the word to be acted upon is 16-bits long. The C28 address to read from has also been passed in as a parameter. The function has been configured to “ENABLE BLOCKING”, which means the function will wait until a slot is available in the M3 PutBuffer to insert the message into the ring buffer. If the function is configured to “DISABLE BLOCKING”, it will return STATUS_FAIL and not send the message to the C28 if the “Put” buffer was full of messages, or STATUS_PASS if there was room in the “Put” buffer and the message was sent to the C28 successfully. The receiving processor will call the IpcGet function continuously to grab messages into the sMessage data structure as long as there are still messages in the “Get” buffer (which is equivalent to the sending processor’s “Put” buffer). IPC Get is called in the ISR using a tIpcController instance on the C28 which ties the same two M3 and C28 IPC interrupt channels together as the tIpcController instance used to send the command from the M3. In this example, the receiving processor “DISABLES BLOCKING” to indicate it will execute the IpcGet function if there is no data available in the “Get” buffer. Inside the IPCGet() loop, the receiving processor code decodes the command sent in the sMessage and calls the function with the same name as the sending processor’s command function. In this example the C28 would also execute a function called IPCMtoCSetBits(), which would process the message and execute the “set bits” command on the appropriate address. Outside of the IpcGet() loop, the receiving processor’s application code would finally acknowledge the IPC interrupt flag once there are no more messages to process. Even while the receiving processor has not acknowledged the IPC interrupt flag, the sending processor can continue sending messages because the tIpcController instance queues these messages into the sending processor’s “Put” buffer, which is equivalent to the receiving processor’s “Get” buffer. The receiving processor’s ISR will continue “getting” and processing the messages as they arrive until there are no more messages.