“Serial ports are one of the easiest ways for PICs to communicate with other devices. However, event serial ports have their flaws, so in this tutorial, we will look at how a message protocol can increase the reliability of data transfers.
Modern microcontrollers will usually have many device interface peripherals built into them, including I2C, SPI, UART, and CAN. While I2C and SPI are very specific to devices and heavily rely on either select signals or start/stop signals, UART is more free. One of the biggest disadvantages of UART is the lack of a clock signal, which can result in clock drift of either the transmitter or receiver (which results in a baud difference), frame errors, and even overrun errors when one of the buffers on either side is full. Of course, these problems are relativity easy to overcome with the use of timers, watchdogs, and events. But serial connections are more commonly found in one particular scenario, unlike I2C and SPI: removable hardware. I2C and SPI devices are usually ICs directly soldered to the main circuit board or permanently connected to them. At the same time, these devices are children to the main controller and thus can never initiate a data transfer themselves.
Imagine a PIC and computer communicating over a serial connection where each device can send either commands or data to the other device. Such a system could easily be implemented with a trivial message protocol where the first byte sent represents the command, and the following bytes represent data for that command. As long as there are no interruptions, this system works without any issues. However, what would happen if the computer crashed and restarted while it was halfway through transmitting data bytes after sending a command? Well, our program would restart and try to send a command byte to initiate a data transfer, but the command byte would be interpreted as a data byte by the PIC, as it was still expecting a data byte. This results in the PIC producing errors, as the bytes it reads may produce unexpected results. But this is not just a problem for UART; any connection that can potentially be terminated, with no way of knowing that the connection has been terminated, can also crash. The solution is to use a message protocol!”