Serial Communication Protocol Design Hints And Reference

　　前面转载的几篇文章详细介绍了UART、RS-232和RS-485的相关内容，可以知道，串口通信的双方在硬件层面需要约定如波特率、数据位、校验位和停止位等属性，才可以正常收发数据。实际项目中使用串口通信时，一般还需要设计一套通讯协议。那么设计串口通讯协议有什么需要注意的地方呢？本文以iPod、车载CAN解码盒及IoT设备EnOcean的串口通讯协议为例，对通讯协议数据帧的定义做一个简单的介绍和分析。

　　首先看Apple提供的文档《iPod_Accessory_Protocol_Interface_Spec_R38.pdf》，其中有关于设计串口通讯协议的详细说明，具体如下。

The owner or creator of a protocol for communication between accessories and iPhone OS applications must define the preferences that are required or optional. Each accessory and application must then negotiate their level of compatibility directly. Apple does not referee protocols, and protocol creators must ensure that their accessories and applications can verify that they support the same features. The following suggestions can help with protocol design:
■ Ensure that the accessory can always resynchronize its data stream in the event of an error.
■ The round-trip latency of commands may vary; do not draw inferences from propagation times. There is no guarantee of delivery timing over the communication link.
■ After a connection has been established, clearly establish which end speaks first.
■ Begin communication with an exchange of meta-information, such as confirmation of the protocol and version. Give both ends the opportunity to declare that they cannot proceed due to protocol incompatibilities.
■ Ensure that the transaction order is clear and that both ends know their position in it. Packets within each stream are guaranteed to be ordered but not free of gaps between packets, so ensure that the stream can be resynchronized after a gap.
■ Ensure that responses can always be matched to their corresponding requests. The simplest forms of reliable communication are call and response. Interleaved communication streams are more complicated and less desirable.
■ Establish an unambiguous indicator of the start of each packet.
■ Add security where needed, but recognize that it slows down and complicates each transaction.
■ Ensure that the other end of each transaction has both received and understood the last packet.
■ Ensure that each packet is received intact and error free by adding a CRC value, checksum, or the like.
■ Ensure that incoming data can be cached until it can be processed.
■ Try to make the protocol extensible for future needs.

Command Packet Format

Use the small packet format for payloads up to 255 bytes. Use the large packet format for payloads greater than 255 bytes.

Small packet format

For command packets whose payloads are 255 bytes or less, use the small packet format.

Note that the command ID and command data format for packets with currently unspecified lingoes may not follow the format indicated here (1 byte command ID, 0xN bytes command data). Also note that a packet payload length of 0x00 is not valid for the small packet format; it is reserved as a marker for the large packet format.

Large Packet Format
For command packets whose payloads are between 256 bytes and 65535 bytes in length, use the large packet format.

Packet Details
The sync byte (0xFF) is not considered part of the packet. It is sent merely to facilitate automatic baud rate detection and correction when using a UART serial port link and, in some cases, to power on the iPod. It is not necessary to send the sync byte when using BT or USB as a link.
The packet payload length is the number of bytes in the packet, not including the sync byte, packet start byte, packet payload length byte, or packet payload checksum byte. That is, it is the length of the command ID, lingo, and command data. Thus, the packet payload data length for a RequestIdentify command would be 0x02. The Lingo ID specifies the broad category that the communication falls under. The Command ID is a more specific indication of the significance of the packet and is interpreted differently depending on the Lingo ID.
Unless otherwise specified, the following rules apply:
■ All packet data fields larger than 8 bits are sent and received in big-endian format; that is, ordered from the most significant byte to the least significant byte.
■ Device command packets that have a valid checksum but contain an invalid parameter, invalid command, or other such failure cause the iPod to respond with an ACK command containing the appropriate error status.
■ A packet with an invalid checksum received by iPod is presumed to be invalid and is ignored. No ACK or other command is sent to the device in response to the invalid packet.

The sum of all the bytes from the packet payload length (or marker, if applicable) to and including the packet payload checksum is 0x00. The checksum must be calculated appropriately, by adding the bytes together as signed 8-bit values, discarding any signed 8-bit overflow, and then negating the sum to create the signed 8-bit checksum byte. All packets received with a nonzero checksum are presumed to be corrupted and will be discarded.

　　CAN解码盒和车载导航之间的通讯协议如下图所示。

 　　EnOcean串口通讯协议数据帧格式定义如下图所示。

　　可以看到，三个协议的数据帧格式定义虽然有所不同，但基本遵循帧头、数据帧长度、数据类型、数据及校验和的格式。其中iPod在帧头前面还有一个同步字节0xFF，它实际上并不属于数据帧，是为了自动波特率检测和唤醒iPod用的。通常帧头使用一个字节即可，无需使用两个或多个字节作为帧头。有些数据帧的定义没有使用长度，而是使用特殊值作为帧尾，如GPS的NEMA语句，以回车换行作为帧尾。对于GPS模块输出的信息，这没有问题，但对于复杂串口数据的通信，如此定义的局限非常明显，实际数据内容不能存在帧尾的特殊值，否则即会出错。故除使用Asiic码定义的数据帧以外，最好还是以长度属性来明示数据帧的长度，而不要用帧尾符作为数据帧的结束。数据长度使用一个字节还是两个字节来表示，没有特别限制，主要看数据通信的大小。如果单帧数据量都很大，则用2个字节，否则用1个字节，偶尔需要传一段大数据时，分包发送即可。像iPod定义了大小包，更灵活，但处理时稍微麻烦一点点。对于有效数据部分，通常还会碰到有些协议使用转义字节，以去除与帧头相同的数据。这么做，其实既没有必要，又增加了开销。通过数据长度足以排除有效数据部分的数据被误认为是帧头的可能。为了防止因通信错误导致的程序异常，Checksum还是很有必要加上的，有了Checksum就可以在通信出错时，向对方请求重新发送本帧数据或者直接丢弃本帧数据，而不会导致数据解析异常和程序崩溃。像EnOcean协议，在帧头部分也加了校验，是双保险，更可靠，在某些场合还是很有必要的。原来在做车载导航设备时就曾碰到一个严重Bug，因数据帧头错误，导致通讯异常，且长时间不能恢复，原因就是数据帧长度错误地变为60KB多，而实际数据量只有一百多字节，导致接下来所有数据都被认为是那一帧的数据部分。如果帧头也有校验就能规避这个这个问题了。

　　除了数据帧格式的定义，数据流的定义也是通讯协议的重要部分，而这涉及具体的业务逻辑，这里不作具体分析，如有兴趣，可以参考协议文档：

　　Apple Accessory protocol:http://files.cnblogs.com/files/we-hjb/iPod_Accessory_Protocol_Interface_Spec_R38.pdf

　　http://files.cnblogs.com/files/we-hjb/EnOceanSerialProtocol3-V1.30.pdf