Finding the right means of communication through an adapted protocol
Philippe Dreyer
For two entities to be able to communicate, two things are essential. First, the transmission medium must be appropriate. For example, it is more sensible for two people separated by a glass partition who wish to greet each other to wave (light) rather than speak (sound). Second, both entities must specify rules that enable communication — the interlocutors must speak the same language, take turns to speak, a question generally expects a response, and so on.
In computing and microelectronics, transmission media are varied (cable, radio waves, optical fibre, etc.) and the specification of communication rules is called a protocol.
How to choose a protocol?
When developing a communication system for a specific application, engineers must pay particular attention to the following points:
- Throughput: This value defines the quantity of data (bits) sent per second.
- Latency: Latency represents the time elapsed between a request and a response. This quantity is important for defining the responsiveness of a system.
- Integrity: This concept allows a message and its possible alterations during packet transfer to be assessed.
- Security: This factor takes into account the importance of the confidentiality of data transmitted in a message.
These different points will favour a serial or parallel hardware architecture, as well as the choice of protocol. In the case of TCP/UDP for example, UDP does not guarantee message integrity (there are no acknowledgements and the checksum is not mandatory in IPv4), but throughput and latency are good, making UDP a suitable protocol for solutions where the loss of a few packets is not critical (voice over IP, for example). As another example, in the case of video transmission, throughput influences the choice of protocol and transmission medium. Indeed, SDI (Serial Digital Interface) uses coaxial cables (waveguides) to transmit data at up to 2.97 Gbit/s.
Communication protocols between microcontrollers
The development of an embedded and autonomous electronic system is often dependent on the limited communication capabilities of microcontrollers as well as the specific requirements of this type of application:
| Criterion | Level | Detail |
|---|---|---|
| Throughput | Non-critical | Data is generally small in size (commands, sensor measurements, etc.) |
| Latency | Critical | A command must generally be processed as quickly as possible |
| Integrity | Critical | The message must be correctly transmitted, as errors can have serious consequences (a sensor in a safety system, for example) |
| Security | Non-critical | Transmitted data is generally not sensitive (of little interest and difficult to hack) and therefore does not need to be protected |
| CPU power | Critical | The processing power of microcontrollers is limited |
To meet these requirements, FiveCo's engineers very frequently work with two-line I²C buses (Inter-IC bus), which is the best-known serial link between microcontrollers and electronic systems.
However, when communication is required between systems that are not on the same electronic board, additional considerations must be taken into account and I²C is no longer suitable. Communication lines must be protected against electrostatic discharge (ESD). Parasitic capacitances along the lines can affect the bus and the error rate during transmissions can then become unacceptable.
For embedded system applications that are interconnected over significant distances and for which network infrastructures (TCP/IP networks) are not necessary — such as a group of synchronised modules or peripherals that connect occasionally to a central system — FiveCo's engineers have developed a dedicated protocol: the RAP, which can operate on different physical buses such as differential mode lines.
The RAP — Register Access Protocol
The RAP was developed with the aim of accessing registers in read or write mode on remote microcontrollers. It can be used on several buses such as UART, RS485, RS422, and USB. It can also be used as an overlay on other protocols (IP, etc.).
The protocol is based on the principle of a request followed by an optional response. Requests and responses are composed of the following frame structure:
| 1 Byte | 1 Byte | N Bytes | x Byte |
|---|---|---|---|
| Destination address | Source address | Size of the data to follow | DATA |
The data is a series of messages which can be: read requests/responses, write requests, an acknowledgement request, a routing request, error messages, an end-of-frame message, and a checksum.
Thanks to these functionalities, the protocol therefore enables:
- Point-to-point communication as well as multipoint communication (addressing system)
- Identification of the origin and destination of each request
- Read and write access to accessible microcontroller registers via a serial interface (RS485, RS422, UART)
- Guaranteed message integrity and receipt through a checksum and an acknowledgement system (including management of any collisions)
- Firmware updates
- Routing a message to another interface on the peripheral
These characteristics are extremely valuable for low-level communications between remote systems. It allows engineers to develop and guarantee their clients robust, reliable, and highly responsive interconnected systems.
In conclusion, the choice and correct implementation of protocols are paramount in the design of interconnected systems. This challenge has been addressed by FiveCo for many years across its various development projects.
