Code Bye

c#串口接收字符串

本人在单片机上每10s发送4个字符到上位机  波特率9600
上位机接收事件里面将接收到的字符和时间记录日志,代码如下:
private void serialPort1_DataReceived(object sender, System.IO.Ports.SerialDataReceivedEventArgs e)
{
string str = serialPort1.ReadExisting();
write_log(str);  //记录日志  将接收到的数据和时间记录下来
}
然后本人接收一段时间后查看日志内容如下:
2760    2016/6/11 16:35:26
2           2016/6/11 16:35:37
760      2016/6/11 16:35:37

2           2016/6/11 16:35:48
760      2016/6/11 16:35:48

2          2016/6/11 16:35:59
76       2016/6/11 16:35:59
0         2016/6/11 16:35:59

2         2016/6/11 16:36:09
75      2016/6/11 16:36:09
9        2016/6/11 16:36:09

2        2016/6/11 16:36:20
759   2016/6/11 16:36:20

27     2016/6/11 16:36:31
59     2016/6/11 16:36:31

可以看出本人一次发送的数据除了第一次能接收完整  其余时候都要分2次或3次接收
是windows缓冲机制的原因吗?
各位高手指点指点  这个怎么解决?加快波特率可以吗?
解决方案

10

分几次接收那是不确定的。假如你电脑比较卡,那么你的 .net 组件接收缓存中的数据自然就少一些,那么自然就需要多接受一次才可能收到消息的结尾。
首先搞明白,“本来就应该写成循环接收数据的程序流程”。在这个程序写正确之后,再来考虑为什么不能快速收到信息的问题。原因是效率并不会影响正确性。假如连正确你都不保证,就不要奢谈“分2次或3次接收”。这是解决的问题的正确次序问题。

10

对于 .net 的串口组件来说,有两种可以设置的模式。一种是你可以设置一个“消息结束符”,组件收到这个符号之后才会触发 DataReceived 事件。另外一种(默认)就是不设置这个结束符,组件只要是在轮到处理应用程序消息循环时就会触发这个 DataReceived事件,而寻找结束符的工作交给你本人来办。

20

所谓“加快波特率”是个不靠谱的想法,原因是加到“多少才保证没有这个问题,而又能保证通讯稳定”?上面已经说过了解决问题的正确次序了。
有一些比较坑爹的博客,你会看到甚至上面在DataReceived  事件处理中写了 Thread.Sleep(2000)这种代码。其实用屁股都能想清楚,数据都来了不跑去接收,干嘛还要故意延迟2秒?
其出发点,就是用不靠谱的“瞎试”的做法莱蒙本人。这个数值设置为多少合适?多少才能保证没有接收问题、同时又能保证一有完整数据就立刻收到完整数据?设置大点好还是小点好?——根本没有纠结的结果。
原因是这根本就不是靠谱的思路。靠谱的思路是先保证完整接收到消息,不管是1次2次还是3次收到的,先保证流程数据正确。而不需要考虑玩什么“波特率、阻塞时间”之类的。

CodeBye 版权所有丨如未注明 , 均为原创丨本网站采用BY-NC-SA协议进行授权 , 转载请注明c#串口接收字符串