说说 SerialPort 的缺点

[wugamp]

SerialPort是串口通讯必不可少的类，但我发现它收数据的速度不稳定。
我在 DataReceived 方法里加入计时语句：刚进入该方法时读一次时间，读完缓冲区后再读一次时间，计算时间差，就知道它花了多久来读缓冲区。
在数据包的长度和波特率不变的情况下，我发现，通常1到2毫秒能读完，有时4到6毫秒，最夸张的一次花了18毫秒。每次进入DataReceived方法时，都知道缓冲区里有72个字节要读。把它们一个个读出来，花的时间可能是1毫秒，也可能要18毫秒。
因为 DataReceived只是从缓冲区里读出来，所以花的时间应该和硬件通信已经没有关系了。时间为什么变化这么大？
我唯一能想到的就是DataReceived方法在读到一半的时候，被什么东西打断了。但应该不是进程切换，因为进程切换的时间不太会这么短。

[stherix]

虽然读缓冲区本身时间的确是是不确定的,因为这涉及到操作系统以及串口驱动代码的问题 你就没想过是你的计时器不准吗

[pamgu]

实在不行就用双缓冲区吧

[wugamp]

引用 1 楼 stherix 的回复:

虽然读缓冲区本身时间的确是是不确定的,因为这涉及到操作系统以及串口驱动代码的问题 你就没想过是你的计时器不准吗

定时器就是一个 DateTime.Now，肯定是准的。而且凡是读取时间较长的那几次，上层处理时也都报了“超时”的错误，就是说计时器观测到的的结果得到了外界的证实。 现在的问题就是如何缩短DataReceive方法所消耗的时间。 提高进程或者线程的优先级？ 用汇编？

[xuggzu]

怀疑楼主计算的时间单位有问题，毫秒有点夸张。
不过，如果读取的方法不对，也确实可能。比如：强制读取固定量数据，而没有查看缓冲区有多少数据。

[wang_peng_yl]

这东西我们用的少，我觉得只要用到了，就是和设备有关系，或者说和设备的环境有关系。 比如：布线长短(意味着信号衰减)，环境温度，设备所需电压是否稳定(意味着数据是否丢包)， 至于代码这块的效率，只要不是小学生去编码，问题都不大。 这些都是我们实际中测出来，但和你的情况可能不一样，参考吧