观察：WIN32串口API [英] Observations: WIN32 serial port API

问题描述

这是一个观察而不是一个查询，但我会很感激我对错误的反馈。多年来，我的软件工作涉及与外部设备的通信，并且大部分时间连接方法是RS232 /串行。目标
设备通常用低级语言编程，并且通信涉及直接访问UART（16550& al）寄存器。当Win32 API出现时，串行端口被视为'文件'，我惊讶地发现当处理
串行读取的线程被阻塞时，该端口的串行写入也被阻止。这是没有意义的，因为UART上的Tx和Rx线除了一些常见元素（如数据速率）之外是有效独立的。它似乎导致一些相当不合逻辑的要求，
，例如必须为端口读取分配足够低的超时，以允许执行写操作而不会有不适当的延迟，从而产生无意义的线程CPU流失。

This is an observation rather than a query, but I would appreciate feedback on anything I’ve got wrong. For many years my software work has involved comms with external devices, and for much of that time the connection method was RS232/serial. The target devices were generally programmed in low level languages, and the comms involved directly accessing the UART (16550 &al) registers. When the Win32 API came out, with serial ports treated like a ‘file’, I was surprised to find that when a thread handling serial read blocked, the serial write for that port also blocked. That makes no sense, given that the Tx and Rx lines on a UART are effectively independent aside from some common elements such as data rate. It seems to lead to some rather illogical requirements, such as having to assign low enough timeouts to port reads to allow writes to be actioned without undue delays, accordingly creating senseless thread CPU churn.

使用赛普拉斯API转移到USB是一件非常大的事情 - 发现USB端口上的两个方向是真正独立的。我可以允许主机上的接收线程无限期地阻塞，在接收数据时发出信号（和循环），并且在
的同时自由地将数据传输到目标。

It’s been a great relief to move to USB – using the Cypress API – to find that the two directions on a USB port are truly independent. I can allow a receive thread on a host machine to block indefinitely, signal (and loop) when it receives data, and at the same time transmit data to the target freely.

我看不出串行API无法按照USB运行的逻辑原因。我绝望的一件事是打开一个串口两次，有两个文件句柄，一个用于GENERIC_READ，另一个用于GENERIC_WRITE。不幸的是，Windows不允许这样做。

I can see no logical reason why the serial API could not function as per USB. One thing I tried in desperation was to open a serial port twice, with two file handles, one for GENERIC_READ and one for GENERIC_WRITE. Unfortunately, Windows doesn’t allow that.

RS232几乎肯定会一路走来，所以我想不可能有任何改变。我在这里遗漏了一些基本的东西 - 即。是否有可能以一种方式阻塞串口并保持另一种方式打开？当前以文件为中心的
API设计是否反映了对硬件如何工作的错误解释？

RS232 is almost certainly on the way out, so I guess it’s unlikely that anything will change on its behalf. Am I missing something fundamental here – ie. is it possible to block a serial port one way and leave the other way open? And is the current file-focussed API design a reflection of a misinterpretation of how the hardware works?

bv

推荐答案

如果使用重叠的I / O打开文件，则不会阻止ReadFile。 他们没有理由让串行端口的ReadFile API工作方式与其他设备不同。

ReadFile does not block if you open the file using overlapped I/O.  There was really no reason for them to make the ReadFile API work differently for serial ports than it is for other devices.

这篇关于观察：WIN32串口API的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！