本人在单片机上每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缓冲机制的原因吗？
各位高手指点指点 这个怎么解决？加快波特率可以吗？
上位机接收事件里面将接收到的字符和时间记录日志，代码如下：
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次接收”。这是解决的问题的正确次序问题。
首先搞明白，“本来就应该写成循环接收数据的程序流程”。在这个程序写正确之后，再来考虑为什么不能快速收到信息的问题。原因是效率并不会影响正确性。假如连正确你都不保证，就不要奢谈“分2次或3次接收”。这是解决的问题的正确次序问题。
10
对于 .net 的串口组件来说，有两种可以设置的模式。一种是你可以设置一个“消息结束符”，组件收到这个符号之后才会触发 DataReceived 事件。另外一种（默认）就是不设置这个结束符，组件只要是在轮到处理应用程序消息循环时就会触发这个 DataReceived事件，而寻找结束符的工作交给你本人来办。
20
所谓“加快波特率”是个不靠谱的想法，原因是加到“多少才保证没有这个问题，而又能保证通讯稳定”？上面已经说过了解决问题的正确次序了。
有一些比较坑爹的博客，你会看到甚至上面在DataReceived 事件处理中写了 Thread.Sleep(2000)这种代码。其实用屁股都能想清楚，数据都来了不跑去接收，干嘛还要故意延迟2秒？
其出发点，就是用不靠谱的“瞎试”的做法莱蒙本人。这个数值设置为多少合适？多少才能保证没有接收问题、同时又能保证一有完整数据就立刻收到完整数据？设置大点好还是小点好？——根本没有纠结的结果。
原因是这根本就不是靠谱的思路。靠谱的思路是先保证完整接收到消息，不管是1次2次还是3次收到的，先保证流程数据正确。而不需要考虑玩什么“波特率、阻塞时间”之类的。
有一些比较坑爹的博客，你会看到甚至上面在DataReceived 事件处理中写了 Thread.Sleep(2000)这种代码。其实用屁股都能想清楚，数据都来了不跑去接收，干嘛还要故意延迟2秒？
其出发点，就是用不靠谱的“瞎试”的做法莱蒙本人。这个数值设置为多少合适？多少才能保证没有接收问题、同时又能保证一有完整数据就立刻收到完整数据？设置大点好还是小点好？——根本没有纠结的结果。
原因是这根本就不是靠谱的思路。靠谱的思路是先保证完整接收到消息，不管是1次2次还是3次收到的，先保证流程数据正确。而不需要考虑玩什么“波特率、阻塞时间”之类的。