Messaging Protocol
A data link ultimately provides methods for transmitting and receiving messages over the link. There are two
distinct types of message transactions supported by a data link.
- Unsolicited Messages
An unsolicited message is a message that is sent without a request. Unsolicited messages can be sent and/or received from both a host or a device. Unsolicited
messages are useful for providing periodic status information and for data streaming. For example, reporting a device's sensor values.
- Request-Response Messages
Request-response messages contain both a request and a response message. The request message is sent from the host and a subsequent response message is returned
by the device. Request-response messages are useful when a device needs to take action from a request. For example, programming a device's memory or controlling
a device's outputs.
Parameters
A message transferred over a data link is defined by a collection of parameters. Each message also contains an identifier field and an optional CRC validation field.
Figure 1 - Illustrates a message that is made up of an identifier field, collection of parameters and an optional CRC field.
Each parameter within a message has a data type, name and a description. The data link serializes and transfers the parameter value based upon its data type. A parameter
can be one of the following data types.
- Integers
Unsigned and signed 8-bit, 16-bit, 32-bit and 64-bit integer values.
- Floating Point
Single 32-bit and double 64-bit precision floating point values.
- String
ASCII encoded character array.
- Enumeration
Application defined enumerations.
- Structure
An application defined collection of other parameters.
- Array
Each parameter can be defined as an array of values.
Message Serialization
Before a message is transferred over the transport interface, each parameter value within the message is serialized by the data link into a simple array of data bytes.
This serialization process is performed by code that is automatically generated based upon the protocol definition for the data link.
For example, assume a device implements a request-response message for reading its memory. Assume the request message has the following two parameters.
- UINT32 Address - The memory address to be read.
- UINT32 Length - The number of bytes to be read and returned.
Figure 2 below illustrates the serialized data for requesting to read 8 bytes from address 0 within the device.
Figure 2 - Illustrates the serialized parameter values for the example Read Memory request message. The data indicates parameter 'Address' = 0 and
parameter 'Length' = 8.
For the response message, assume the message contains a single UINT8 array to return the data that has been read from the device's memory. Figure 3 below illustrates
the serialized data for the response to the previous read memory request.
Figure 3 - Illustrates the serialized parameter values for the example Read Memory response message. The data indicates parameter 'Data' is an array
with an item count = 8, and all values = 0.
Data Encapsulation
Depending upon the transport interface, encoding is necessary to encapsulate the data that represents a single message for the data link. For example, data transferred over
a serial port is a continuous stream of data with no concept of complete messages. For these types of interfaces, the data link uses
Serial Line Internet Protocol (SLIP) encoding, defined within
RFC 1055, to encapsulate the data that represents a message.
Figure 4 - Illustrates a message with extra encapsulation information.
Encapsulation is not required by all transport interfaces. When using the data link over a native USB connection, encapsulation is not needed as the short packet already
provided by USB is enough to signify a message. Encapsulation is used whenever using the data link over a serial connection.
More Information