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.


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.

Message fields
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.

Read memory request message data
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.

Read memory response message data
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.

Read memory response message data
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