Tech Talk

In Part 1 of this series, we looked at the low-level requirements for a communications protocol and considered the factors involved in choosing the right protocol for the job at hand. In this article we look at how the data transferred in the message is structured and how differing requirements affect its complexity.

Building a System
To build a complete multi-functional system, microprocessors need to communicate, exchanging information such as settings and data. In most cases this task is centralized and performed by a dedicated Host microprocessor, though in some cases this may be made more complex by the architecture of the system (e.g., The Streaming module may control a Bluetooth module).

What’s in a Message?
As discussed in Part 1 a message comprises a Start of Message indicator, a device address (dependent on the protocol), the Message Payload and an End of Message indicator.

The Message Payload is the part of the message that contains the data specific to the current communication.

We will take a look at two types of messages:

• Simple data transfer
• Bespoke Messaging protocols

Simple Data Transfer
Much of the communication handled by the Host microprocessor is between itself and the peripherals that it controls and involves either setting or requesting simple values. In these cases, all communication is initiated by the Host.

While different communication protocols each have their own way of managing this in general the Message Payload will contain the following information:

• A means of identifying which data item is to be updated or retrieved. This is usually an address or identifier used to identify the setting or value being accessed (as opposed to the address of the device being accessed)
• An indication of whether the message represents a data request or an update (in the case of I2C this is included in the address, so a peripheral will have two addresses - one for reading, one for writing)
• In the case of an update, the new value which is usually a single byte in size

As you can see, the message content has a simple structure. This is extended to allow for sequential items to be updated in a single Message Payload and is used as a technique for writing data to peripherals such as EEPROMs where it may be necessary to write a number of bytes in a single message.

A characteristic of this type of messaging is that it is generally synchronous and does not include mechanisms for the peripheral to initiate data transfer to the Host.

Where there is a need to transfer more complex data structures a Bespoke Messaging Protocol is required.

Bespoke Messaging Protocols
A Messaging protocol defines a suite of messages that are used to transfer data and commands between two microprocessors (the Sender and the Receiver). The scope of the interface is tailored to the specific data structures that are required for the interaction over the interface.

Microprocessors that are part of a component which provides specific functionality will often define an “out-of-the-box” protocol for communication. In this scenario it is the responsibility of the developer writing the code for the microprocessor using the component to utilize the protocol.

Where the microprocessor is running bespoke device specific code, or an operating system that is used to implement flexible functionality, a bespoke application specific protocol may be required.

The scope of the protocol is dependent on the requirements of the interface but will usually include the following types of functionality:

• Handshaking
• Control / Feedback
• Data Transfer

Handshaking
Handshaking normally occurs when the device is initializing, or when it is restarting. It is used to pass information between the two microprocessors such as device type and version that allows them to set up their running environment, identify whether any upgrades are required, and to signal to each other when they are ready to send/receive messages.

Control
Control messages are used by one microprocessor to tell the other to perform an action that is required for the originating microprocessor to perform the task it is currently undertaking. The receiving microprocessor is programmed to perform a specific task in response to receiving the message.

For instance, a Host microprocessor in a Streamer may send a Control message telling a streaming module to accept input from one of the device's external digital inputs rather than from its own streaming input.

Data Transfer
Data Transfer messages are used for the bulk transfer of data between microprocessors. This generally requires the data to be split into a number of segments (known as packets) for transfer, and generally requires the receiving microprocessor to send a message confirming that it is ready to receive the next packet once it has processed the current packet.

An example of this is when upgrade data is passed between microprocessors; however, it may also occur where one microprocessor is responsible for acquiring data for the other from an external source.

Getting the Message Across
The data contained in a message will generally be focussed on the activity the message is referring to. In many cases it may be necessary to include information relating to the transfer of the message in addition to its content. For instance:

• It cannot always be guaranteed that messages will be successfully transferred between microprocessors. Issues may occur in the hardware or software that cause the data to become corrupted in the transfer. This requires some form of acknowledgement that the message has (or has not) been received
• When different message types in the protocol are related (e.g., album, artist and track information) it is possible that the protocol will allow multiple message types to be included in a single Message Payload. Information about the number and type of messages included will be required

Headers
To address the need for extra information, a header may be included at the start of the message containing information about the structure and state of the Message Payload.

While this header is bespoke and specific to the messaging protocol, it will generally contain the following types of information:

• A “Packet” identifier which is a unique identifier for the message and may be used to identify the message where a request that the message be re-transmitted if required
• A “Frame” identifier may also be included in the header and is generally a simple incrementing integer value. This is used where large amounts of data are transferred in a single packet (particularly in the case of Data Transfer messages). It may be necessary to split the message up into a number of parts known as frames
• The length of data being sent in the packet. This can be used by the receiving microprocessor to identify when the transfer of the data is complete
• A Checksum value. Again, this may be used to verify by the receiver that the correct data has been sent
• Control flags which indicate the type of message and whether further data for the message will follow in subsequent transfers. This may also contain an acknowledgement from the receiver that the message has been transferred successfully or has failed
• Where a Packet contains multiple message types, a counter may be included indicating how many message types are contained in the message payload with each message type having its own header information

Each message type included in the payload may also have its own header describing the contents of the data related to that message type (if that has not already been included in the main header). This would contain information such as:

• A Message Type identifying the type of Message
• The length of the data in the Message Payload that relates to the specific message
• Data Encoding. This will identify the format that the data in the messages is being transferred as (e.g., whether it is a 1-, 2-, or 4-byte integer, or Binary data)

Acknowledgements
As mentioned above, some messaging protocols include a mechanism for the receiving microprocessor to send a response upon receipt of a packet of message data. This generally takes the form of an acknowledgement which indicates whether the transfer was successful (known as an ACK), or not (known as a NACK). This is in addition to a response message that contains the data requested by the original message, and which will be sent at a later time when the data has been sourced and formatted.

These acknowledgments often include a header similar to the original message, mirroring the Packet and Frame identifiers, though it will generally not contain data.

Synchronous vs Asynchronous Responses
Another consideration when developing bespoke messaging protocols is when any responses from the receiver will be transferred, and when they will be processed.

In general, when a message is sent the receiver will immediate send an ACK/NACK indicating whether the message has been successfully received, followed by a response message containing any data that has been requested at some later point when the data has been gathered and formatted.

The asynchronous nature of the response message leads to considerations on how the message is processed on the receiving microprocessor.

• Does it need processing as soon as it is received?
• Can it be put in a queue and processed at a later point?
• This is a discussion for another article, but it shows that it must be taken into consideration when designing a bespoke messaging protocol

Conclusion
The majority of communication between a Host processor and its peripherals will use a simple form of communication. However, when the interaction becomes more complicated a bespoke solution is required that provides a richer interface.

The overheads of providing this kind of interface are an increase in complexity, and the cost of developing the bespoke interface. However, once developed they provide a rich and extensible way of passing information between the microprocessors used in a device.