Windows 不刷新 COM 缓冲区
我在 Windows 中看到一些与我的 COM 缓冲区有关的非常奇怪的行为。
我使用带有 FTDI 芯片的 3 USB 串行转换器。我使用 CreateFile 打开 com 端口，一切正常。除波特率外，所有 3 个端口的配置均相同。 2 个在 38400 工作，一个在 9600 工作。
这是奇怪的部分：
我能够成功地写出 9600 端口和 38400 端口之一。第二个38400端口似乎正在缓冲数据。我已使用超级终端连接到此端口，并看到在工作端口上我立即得到响应，而在“奇怪”端口上我只有在关闭应用程序时才能获取数据......
还有其他人经历过这种情况吗？你是如何解决这个问题的？
I'm seeing some pretty odd behaviour from windows regarding my COM-Buffers.
I use 3 USB-Serial Converter with FTDI chips. I open the com ports with CreateFile and it all works fine. All 3 ports have the same configuration except for the baud rates. 2 work at 38400 and one at 9600.
Here is the odd part:
I am able to successfully write out of the 9600 port and one of the 38400 port. The second 38400 ports seems to be buffering the data. I have connected to this port with Hyperterminal and see that on the working ports i immediately get a response and on the "weird" port i only get the data when i close my application...
Has anyone else experienced this? How did you resolve this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这有点像黑暗中的尝试……但是。
检查“奇怪”连接两端的流量控制设置。当流量控制不匹配时，我见过这样奇怪的事情。关闭端口的操作会清除这些位并允许缓冲的数据流动。
This is kind of a shot in the dark... but.
Check the flow control settings for both ends of the "weird" connection. I've seen strange things like this when the flow control is mismatched. The act of closing the port clears the bits and allows the buffered data to flow.
在使用过 FTDI 芯片之后，我建议您检查每个端口的高级驱动程序设置。该驱动程序支持缓冲和延迟控制，以便您在高吞吐量和低延迟之间进行折衷。因此，请检查有效的设置，并对无效的设置使用相同的设置（如果它们不相同）。
顺便说一句，通过使用 FTDI:s 自己的 API< /a> 您不必跟踪 COM 端口重新分配等。该 API 与普通的 Win32 API 非常相似，但公开了更多配置选项。
Having worked a bit with FTDI chips, I would suggest you check out the advanced driver settings for each port. The driver supports both buffering and latency control in order to allow you to compromise between high throughput and low latency. So check the settings that work and use the same for the one that doesn't (if they're not the same).
On a side note, by using FTDI:s own API you don't have to keep track of COM-port reassignment and the like. The API is quite similar to the normal Win32 one but exposes more configuration options.