110,536
社区成员
发帖
与我相关
我的任务
分享串口通信ReadFile
调试串口通信的一个程序。
接收使用ReadFile这个函数。
调试的时候发现，这个函数不会阻塞，也就是说读不到任何信息他也返回。
这样的话，如果对方还没有来得及发送回信的话，可能会造成判断失败。
目前，我是循环一定次数然后读取。但是总觉得循环次数不保险。
请有经验的人给点建议，谢谢。
另外，我这里的接收不能放到线程去做。因为我每次发送的命令接受方都会
返回一个值，代表是否接收完毕校验是否通过的信息。
谢谢
接收使用ReadFile这个函数。
调试的时候发现，这个函数不会阻塞，也就是说读不到任何信息他也返回。
这样的话，如果对方还没有来得及发送回信的话，可能会造成判断失败。
目前，我是循环一定次数然后读取。但是总觉得循环次数不保险。
请有经验的人给点建议，谢谢。
另外，我这里的接收不能放到线程去做。因为我每次发送的命令接受方都会
返回一个值，代表是否接收完毕校验是否通过的信息。
谢谢
...全文
请发表友善的回复…
发表回复
jason176374 2010-10-17
- 打赏
- 举报
[Quote=引用 7 楼 sp1234 的回复:]
引用 1 楼 3000sunqin 的回复:
接收完全可以放到线程中去做
只要控制好发送代码即可，
起线程收ReadFile，循环一直收，如果收到了数据检查一下是否收到了完整帧数据，如果不完整将数据放入缓冲区内，如果缓冲区内数据已经完整了将这些数据发送给上端数据处理程序处理。
如果你不想使用线程。那么可以使用超时机制来完成，就是发了命令后，等多少毫秒后去读取串口，如果不对就认为超时，进……
[/Quote]
两个线程都在同一个串口上做接收。
数据不会串吗？
引用 1 楼 3000sunqin 的回复:
接收完全可以放到线程中去做
只要控制好发送代码即可，
起线程收ReadFile，循环一直收，如果收到了数据检查一下是否收到了完整帧数据，如果不完整将数据放入缓冲区内，如果缓冲区内数据已经完整了将这些数据发送给上端数据处理程序处理。
如果你不想使用线程。那么可以使用超时机制来完成，就是发了命令后，等多少毫秒后去读取串口，如果不对就认为超时，进……
[/Quote]
两个线程都在同一个串口上做接收。
数据不会串吗？
3000sunqin 2010-10-16
- 打赏
- 举报
接收完全可以放到线程中去做
只要控制好发送代码即可，
起线程收ReadFile，循环一直收，如果收到了数据检查一下是否收到了完整帧数据，如果不完整将数据放入缓冲区内，如果缓冲区内数据已经完整了将这些数据发送给上端数据处理程序处理。
如果你不想使用线程。那么可以使用超时机制来完成，就是发了命令后，等多少毫秒后去读取串口，如果不对就认为超时，进行重发。
只要控制好发送代码即可，
起线程收ReadFile，循环一直收，如果收到了数据检查一下是否收到了完整帧数据，如果不完整将数据放入缓冲区内，如果缓冲区内数据已经完整了将这些数据发送给上端数据处理程序处理。
如果你不想使用线程。那么可以使用超时机制来完成，就是发了命令后，等多少毫秒后去读取串口，如果不对就认为超时，进行重发。
松花皮蛋 2010-10-16
- 打赏
- 举报
用MOXA 串口卡的 库，比较好用！
以专业开发人员为伍 2010-10-16
- 打赏
- 举报
[Quote=引用 1 楼 3000sunqin 的回复:]
接收完全可以放到线程中去做
只要控制好发送代码即可，
起线程收ReadFile，循环一直收，如果收到了数据检查一下是否收到了完整帧数据，如果不完整将数据放入缓冲区内，如果缓冲区内数据已经完整了将这些数据发送给上端数据处理程序处理。
如果你不想使用线程。那么可以使用超时机制来完成，就是发了命令后，等多少毫秒后去读取串口，如果不对就认为超时，进行重发。
[/Quote]
是这样的。
实际上接收工作可以跟解析分开为两个线程，这样就更准确清晰。接收者其实就是循环接收（如果能够由底层的某个消息触发异步接收则比简单地循环更可取）。如果分开两个线程，那么你完全不用担心因为处理命令太慢而丢失该接收的数据，也可以一下子就消除许多看似诡异的问题。
接收完全可以放到线程中去做
只要控制好发送代码即可，
起线程收ReadFile，循环一直收，如果收到了数据检查一下是否收到了完整帧数据，如果不完整将数据放入缓冲区内，如果缓冲区内数据已经完整了将这些数据发送给上端数据处理程序处理。
如果你不想使用线程。那么可以使用超时机制来完成，就是发了命令后，等多少毫秒后去读取串口，如果不对就认为超时，进行重发。
[/Quote]
是这样的。
实际上接收工作可以跟解析分开为两个线程，这样就更准确清晰。接收者其实就是循环接收（如果能够由底层的某个消息触发异步接收则比简单地循环更可取）。如果分开两个线程，那么你完全不用担心因为处理命令太慢而丢失该接收的数据，也可以一下子就消除许多看似诡异的问题。
以专业开发人员为伍 2010-10-16
- 打赏
- 举报
[Quote=引用楼主 jason176374 的回复:]
因为我每次发送的命令接受方都会
返回一个值，代表是否接收完毕校验是否通过的信息[/Quote]
因此，你的ReadFile就可以以此为根据，循环。
因为我每次发送的命令接受方都会
返回一个值，代表是否接收完毕校验是否通过的信息[/Quote]
因此，你的ReadFile就可以以此为根据，循环。
兔子-顾问 2010-10-16
- 打赏
- 举报
和这个无关。目前为止，mobile上，我只见过驱动不完整的或没做好的虚拟串口需要用api自己写。
serialport是很完善的。
你用api打开com1成功了么？用serialPort打开com1的错误提示是什么？
mobile设备中，到底哪些是可用的，我们可以在注册表中找到的。或是通过：
System.IO.Ports.SerialPort.GetPortNames()
获得
我的建议是尽量的尝试用SerialPort。
serialport是很完善的。
你用api打开com1成功了么？用serialPort打开com1的错误提示是什么？
mobile设备中，到底哪些是可用的，我们可以在注册表中找到的。或是通过：
System.IO.Ports.SerialPort.GetPortNames()
获得
我的建议是尽量的尝试用SerialPort。
jason176374 2010-10-16
- 打赏
- 举报
[Quote=引用 3 楼 wuyazhe 的回复:]
如果自己写api读取。那显然不只是用readfile。要先剔除错误数据，串口本身受到干扰时数据不是都正确的，函数名不记得了，不过，你为什么不用System.IO.Ports.SerialPort呢？
[/Quote]
最开始的时候我也想用System.IO.Ports.SerialPort。因为确实简单。
但是我现在做的这个是在WINCE上运行的。硬件本身只有3个串口，而三个
串口都要和下位机连接。
但是System.IO.Ports.SerialPort打开串口COM1的时候，就会报异常。
查了很多资料，没有准确说法。在MSDN论坛上，有人推测是因为一般WINCE的
COM1都是连接调试器的，因此不能打开（至少DEBUG时是这样）。
所以就改用API了，用API确实可以打开这个串口，
但是随之而来的就是自己要处理很多事情。
如果自己写api读取。那显然不只是用readfile。要先剔除错误数据，串口本身受到干扰时数据不是都正确的，函数名不记得了，不过，你为什么不用System.IO.Ports.SerialPort呢？
[/Quote]
最开始的时候我也想用System.IO.Ports.SerialPort。因为确实简单。
但是我现在做的这个是在WINCE上运行的。硬件本身只有3个串口，而三个
串口都要和下位机连接。
但是System.IO.Ports.SerialPort打开串口COM1的时候，就会报异常。
查了很多资料，没有准确说法。在MSDN论坛上，有人推测是因为一般WINCE的
COM1都是连接调试器的，因此不能打开（至少DEBUG时是这样）。
所以就改用API了，用API确实可以打开这个串口，
但是随之而来的就是自己要处理很多事情。
兔子-顾问 2010-10-16
- 打赏
- 举报
如果自己写api读取。那显然不只是用readfile。要先剔除错误数据，串口本身受到干扰时数据不是都正确的，函数名不记得了，不过，你为什么不用System.IO.Ports.SerialPort呢？
yudengchang 2010-10-16
- 打赏
- 举报
可以写一个函数,过多长时间进行接收,也就象我们设置邮箱多长时间查询是否有新邮件一样的,通过系统时间来控制.
