C# 串口操作系列(3) -- 协议篇，二进制协议数据解析

我们的串口程序，除了通用的，进行串口监听收发的简单工具，大多都和下位机有关，这就需要关心我们的通讯协议如何缓存，分析，以及通知界面。

我们先说一下通讯协议。通讯协议就是通讯双方共同遵循的一套规则，定义协议的原则是尽可能的简单以提高传输率，尽可能的具有安全性保证数据传输完整正确。基于这2点规则，我们一个通讯协议应该是这样的：头+数据长度+数据正文+校验

例如：AA 44 05 01 02 03 04 05 EA

这里我假设的一条数据，协议如下：

数据头：     AA 44

数据长度： 05

数据正文： 01 02 03 04 05

校验：       EA

一般数据的校验，都会采用常用的方式，CRC16,CRC32,Xor。

有的数据安全要求高的，不允许丢包的，可能还要加入重发机制或是加入数据恢复算法，在校验后根据前面数据添加恢复字节流以恢复数据。我这里采用的是简单的异或校验，包含数据头的所有字节，依次异或得到的。

协议很简单，我也认为分析协议是很简单的事情，下面我们就如何分析协议来实际的结合c#看一下。

er…再等等，在我们实际开始编码之前，还有一个规则需要了解，我们有了通讯协议，如何结合串口的协议来分析，需要关心什么呢？哦。一般就是4个问题：缓存收到的所有数据，找到一条完整数据，分析数据，界面通知。

如果分的更详细一点，缓存收到的所有数据，我们想到最高效的办法就是顺序表，也就是数组，但数组的操作比较复杂，当你使用完一条数据后，用过的需要移除；新数据如果过多的时候，缓存过大需要清理；数据搬移等等，很有可能一个不小心就会丢数据导致软件出些莫名其妙的小问题。个人建议，使用List，内部是数组方式实现，每次数据不足够的时候会扩容1倍，数据的增删改都已经做的很完善了。不会出现什么小问题。

找到一条完整数据，如何找到完整数据呢？就我们例子的这个协议，首先在缓存的数据中找AA 44，当我们找到后，探测后面的字节，发现是05，然后看缓存剩下的数据是否足够，不足够就不用判断，减少时间消耗，如果剩余数据>=6个（包含1个字节的校验），我们就算一个校验，看和最后的校验是否一致。

分析数据：鉴于网络的开放性，我无法确定读者对c#的了解程度，介绍一下，常用的方式就是BitConvert.ToInt32这一系列的方法，把连续的字节（和变量长度一样）读取并转换为对应的变量。c++下使用memcpy，或直接类型转换后进行值拷贝，vb6下使用CopyMemory这个api。

校验：前面说过了。完整性判断的时候需要和校验对比，大多系统都不太严格，不支持重发，所以数据错误就直接丢弃。导致数据错误的原因很多，比如电磁干扰导致数据不完整或错误、硬件驱动效率不够导致数据丢失、我们的软件缓存出错等。这些软件因素数据系统错误，需要修改，但是电磁干扰么，有这个可能的。虽然很少。

其实我知道，就算是我，看别人的博客也是，喜欢看图片，看代码，文字性的东西，一看就头大。那我接下来贴出基于上一篇文章的改进版本，支持协议分析（协议不能配置，可配置的协议不是我们讨论的范畴。可以看看有DFA(确定性有限状态机))

我们修改一下界面，以便能显示收到后分析的数据

代码如下：

至此，你只要按这个协议格式发送数据到软件打开的串口。就能在数据的data标签显示出你的数据内容，我们现在是直接显示为：

01 02 03 04 05

也就是数据段内容。

运行截图：

发送模拟数据的界面，使用通用工具SSCOMM32.exe

我们在回顾一下，一般二进制格式数据就是这样分析，分析数据长度是否足够，找到数据头，数据长度，校验，然后分析。

分析方式很多。结合各自实际情况操作，可以使用序列化方式，但是wince不支持，也可以用BitConvert方式将连续的字节读取为某个类型的变量。

希望看到这里，能给你带来帮助，欢迎大家和我讨论，希望经验丰富的朋友不吝赐教。上一篇中，有朋友说用BeginInvoke可以避免死锁问题，我暂时没有线，没有测试成功，改天测试后再公布结果。

DataReceived事件中，最高效的做法是指缓存数据，然后异步的去分析数据。但是，这样较复杂，在效率要求不是很高的情况下（大多数情况），可以在DataReceived事件中缓存数据后，立刻进行数据完整性检查，有效性检查，分析数据，以及更新界面。但这么做有一个隐患，底层串口操作的效率依赖于数据分析和界面更新，任何一个环节频繁耗时过长，都会造成数据的堆积。文章只假设都不拖时间的情况。

谢谢观赏，通讯协议分析系列，未完待续……

作者：兔子党逍遥
来源：CSDN
原文：https://blog.csdn.net/wuyazhe/article/details/5627253
版权声明：本文为博主原创文章，转载请附上博文链接！