windows下串口读取的时序
我正在尝试在 Windows（xp）机器上通过串行端口实现协议。 问题是协议中的消息同步是通过消息中的间隙来完成的，即发送字节之间的 x 毫秒间隙表示一条新消息。 现在，我不知道是否有可能准确地检测到这个差距。
我正在使用 win32/serport.h api 读取我们服务器的众多线程之一。来自串行端口的数据会被缓冲，因此如果我们的软件中有足够的（并且将会有足够的）延迟，我将在一个读取序列中从端口缓冲区获取多条消息。
有没有一种方法可以从串行端口读取数据，以便我可以检测接收到特定字节时的间隙？
I'm trying to implement a protocol over serial port on a windows(xp) machine.
The problem is that message synchronization in the protocol is done via a gap in the messages, i.e., x millisecond gap between sent bytes signifies a new message.
Now, I don't know if it is even possible to accurately detect this gap.
I'm using win32/serport.h api to read in one of the many threads of our server. Data from the serial port gets buffered, so if there is enough (and there will be enough) latency in our software, I will get multiple messages from the port buffer in one sequence of reads.
Is there a way of reading from the serial port, so that I would detect gaps in when particular bytes were received?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如果您想对 Windows 串行端口进行更多控制，则必须编写自己的驱动程序。
我看到的问题是 Windows 可能正在执行其他任务或程序（例如病毒检查），这将导致您的应用程序出现计时问题。您的应用程序不会知道它何时被替换为另一个应用程序。
如果可能的话，我建议您的程序在最后一条消息的末尾添加时间戳。当下一条消息到达时，将采用另一个时间戳。时间戳之间的差异可能有助于检测新消息。
我强烈建议更改协议，以便时间不再是一个因素。
If you want more control over a Windows serial port, you will have to write your own driver.
The problem I see is that Windows may be executing other tasks or programs (such as virus checking) which will cause timing issues with your application. You application will not know when it has been swapped out for another application.
If possible, I suggest your program time stamp the end of the last message. When the next message arrives, another time stamp is taken. The difference between time stamps may help in detecting new messages.
I highly suggest changing the protocol so that timing is not a factor.
我过去也曾做过类似的事情。尽管所讨论的协议没有使用任何分隔符字节，但它在某些位置确实有一个 crc 和一些固定值字节，因此我可以推测性地解码该消息以确定它是否是完整的单独消息。
当我遇到这些没有上下文信息的协议时，我总是感到惊讶。
查找具有预期消息长度相应指示的 crc 字段、长度字段、类型字段或具有可预测值的任何其他固定偏移字段，这些字段可以帮助您确定何时拥有单个完整消息。
另一种方法可能是使用 CreateFile、ReadFile 和 WriteFile API 函数。您可以使用 SetCommTimeouts 函数更改一些设置，该函数允许您在遇到特定时间间隙时停止 I/O 操作。
这样做以及一些推测性解码可能是您最好的选择。
I've had to do something similar in the past. Although the protocol in question did not use any delimiter bytes, it did have a crc and a few fixed value bytes at certain positions so I could speculatively decode the message to determine if it was a complete individual message.
It always amazes me when I encounter these protocols that have no context information in them.
Look for crc fields, length fields, type fields with a corresponding indication of the expected message length or any other fixed offset fields with predictable values that could help you determine when you have a single complete message.
Another approach might be to use the CreateFile, ReadFile and WriteFile API functions. There are settings you can change using the SetCommTimeouts function that allows you to halt the i/o operation when a certain time gap is encountered.
Doing that along with some speculative decoding could be your best bet.
没有一种数据格式可以描述来自设备的“消息”，这听起来很奇怪。我使用过的每个串行端口设备都有某种形式的标头来描述它传输的数据。
只是把它扔在那里，但是您可以使用 Win32 异步 ReadFileEx() 和 WriteFileEx() 系统调用吗？它们允许您附加回调函数，然后您可以在回调中管理计时器。然而，计时器只能为您提供粗略的估计。
如果您需要编写自己的驱动程序，Windows 驱动程序工具包有一个示例，演示如何编写串行端口驱动程序。我无法想象您将能够覆盖 Windows 串行端口总线驱动程序（直接控制 Windows 计算机上的串行端口的驱动程序），但您也许可以编写一个位于总线之上的驱动程序司机。
It sounds odd that there is no sort of data format delineating a "message" from the device. Every serial port device I've worked with has had some form of a header that described the data it transmitted.
Just throwing this out there, but could you use the Win32 Asynchronous ReadFileEx() and WriteFileEx() system calls? They allow you to attach a callback function, and then you might be able to manage a timer within the callback. The timer would only provide you a rough estimation, however.
If you need to write your own driver, the Windows Driver Kit has a sample that shows how to write a serial port driver. I can't imagine that you'll be able to override the Windows serial port bus driver(the driver that directly controls the serial port on your Windows machine), but you might be able to write a driver that sits on top of the bus driver.
我是这么想的。你们都是伴随着网络长大的，而我却不是，尽管我在网络诞生时就在场。我猜一下，一个字节是1（SOH）还是2（STX）？ IMVEO 这已经足够了。你只需要跳出框框思考。
您会收到 message_delimiter，后跟 4（作为长度），然后是 4 个字节的数据。有效消息不是这 6 个字节。
有效的消息始终受 message_delimiter 限制，因此它看起来像
I thought so. You all grew up with the web, I didn't, though I was present at the birth. Let me guess, the one byte is 1(SOH) or 2(STX)? IMVEO it is enough. You just need to think outside the box.
You receive message_delimiter followed by 4 (as length) and then 4 bytes of data. A valid message is not those 6 bytes.
A valid message is always bounded by the message_delimiter, so it would look like