The message that needs to be transmitted is a data structure containing instructions from the transmitter to the receiver. The message structure can be divided into three parts, message header (8 bytes), telegram header (8 bytes) and user data (247 bytes). These messages are used to transmit data from one task to another. For all protocol tasks the structure stays the same, but some applications use the messages for parameter passing and these messages don’t have a telegram header but begins immediately with the data.
The two types of messages used are request messages and confirmation messages. The request message causes an action in a task and the confirmation message confirms the performing of that action or task (answer).
For the transmitter to send the message it needs to write it into the receiver’s mailbox and notify the receiver by inverting one of its mailbox bits. The receiver then reads the mail and releases the mailbox in response to the corresponding mail. Only one mailbox is used in each direction. The receiver of the message is thus responsible to quickly read the message in order to release the mailbox again for the next available message.
The messages that cannot immediately be transferred to the Host application are placed in a queue mechanism with a standard configuration of 31 available segments. The actual available segments can be read from the SegmentCount location inside the dual-port memory. If the available number of segments fall bellow a protocol dependent value, the device won’t be able to access messages from its mailbox. The Host application is thus responsible to read out its mailbox messages to ensure that no Host messages are in the queue witch will reduces the available segment count.
Synchronization of message delivery:
The procedure chosen for message synchronization allows the Host to operate in interrupt mode as well as polling mode. The device can cause an interrupt to the Host application by writing into the interrupt capable handshake cell. The hardware has only one interrupt line for each handshake register, indicating different events. The event can be identified by reading the corresponding handshake register in the dual-port memory. The two reserved handshake registers in the duel-port memory are the DevFlags and HostFlags registers. The DevFlags register can only be written to by the Host application and read from by the device. The HostFlags register on the other hand can only be written to by the device and read from by the Host application.
Both these registers contain a command and acknowledgement bit. A command gets activated when the command and acknowledgement bit has opposite values and acknowledged when they have the same value. It is important to note that a new command can only be activated if the preceding command was acknowledged.
In polling mode the Host application monitors the difference between the command and acknowledgement flag bits. The Host application will then be able to send messages or received messages depending on the status of these bits.