前面转载的几篇文章详细介绍了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

最新文章

1. JavaScript——之对象参数的引用传递
2. Unicode explorer
3. （一）JAVA项目（非web项目）部署到windows服务器运行
4. FastJson的基本用法----转
5. 非常详细GC学习笔记
6. 简单3d RPG游戏 之 001 生命条（一）
7. ASP.NET页面生命周期总结（1）
8. Java_Web 连接池
9. Arch安装KDE5
10. 前端安全之CSRF攻击
11. python_如何进行反向迭代和实现反向迭代？
12. 简述Java变量和强制转换类型
13. Maven 项目打包出现错误 Failed to execute goal org.apache.maven.plugins:maven-resources-plugin
14. mysql 开发基础系列10 存储引擎 InnoDB 介绍
15. 【XSY1580】Y队列 容斥
16. DataTable不能通过已删除的行访问该行的信息解决方法
17. CF895C: Square Subsets && 【BZOJ2844】albus就是要第一个出场
18. [转] 通过jQuery Ajax使用FormData对象上传文件
19. HAProxy用法详解
20. formidable模块的使用

热门文章

1. .Net 开源项目资源大全
2. Unity3D 5.x 交互功能 - 碰撞检测函数
3. wampsever在线模式和离线模式有什么区别
4. php中的M方法
5. windows下新安装的mysql修改root password问题
6. 【夯实PHP基础】PHP发送邮件（PHPMailer）
7. JavaScript利用装饰模拟实现私有状态
8. 用C#缩小照片上传到各种空间
9. Linux下安装使用Solr
10. 【代码笔记】iOS-替换电话号码中间4位为-号