RS232（Com 端口）RTS/CTS/DTR/DSR 的低级控制可能吗？
我想知道是否以及如何可以直接从 win32（旧的 C-API）控制 RS-232 握手线。
我想与外部硬件连接，两条简单的数据线就足以满足我的需求。
那么 - win32 是否有一个 API 可以让我读取和写入四个状态行的状态？ 在正常串行通信中，握手线由 UART 自动驱动（如果启用了硬件握手）。
我记得在DOS下这是微不足道的。 只需直接对 UART 进行编程即可。 这个功能在 win32 中是否还存在？
I wonder if and how it's possible to control the RS-232 handshaking lines directly from win32 (the old C-API).
I'd like to interface with an external piece of hardware, and two simple data-lines would be sufficient for my needs.
So - is there a API for win32 that lets me read and write the state of the four status lines? In normal serial communication the handshaking lines are driven by the UART automatically (if hardware handshaking is enabled).
I remember that it was trivial under DOS. One just had to program the UART directly. Has this functionality survived in win32 somehow?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
您可以使用
SetCommState()控制RTS和DTR。 您还可以进行设置，让硬件或驱动程序处理硬件流控制（CTS 和/或 DSR），或者您可以使用 SetCommMask() 进行设置，以便在这些信号发生变化时收到事件。一个不错的概述在这里：http://msdn.microsoft.com/en-us /library/ms810467.aspx
请注意，Win32 串行通信 API 和/或驱动程序可能很挑剔，因此请准备好对线路上发生的情况进行一些调试。
You can control RTS and DTR using
SetCommState(). You can also set things up to have hardware or the driver handle hardware flowcontrol (CTS and/or DSR), or you can set things up usingSetCommMask()so you get events when those signals change.A decent overview is here: http://msdn.microsoft.com/en-us/library/ms810467.aspx
Note that the Win32 Serial Comm API and/or driver can be finicky, so be prepared to have to do some debugging of what's going on on the wire.
我遇到了这个当我必须做一个与 RS232 端口通信的项目时的教程。 这是一个关于如何打开端口、设置一些属性（包括超时）、读/写和关闭端口的完整示例。 即使你的项目现在可能已经结束，我希望这仍然有用，因为它仍然保留在 SO 档案中。
I ran across this tutorial when I had to do a project to communicate with the RS232 port. It's a complete example on how to open the port, set some properties including the timeouts, read/write and close the port. Even though your project is probably over by now, I hope this will remain useful as it remains in the SO archives.
您仍然可以进行类似类型的编程，只是为了获得实现设备驱动程序所需的受保护硬件。 我认为自 20 世纪 80 年代以来，当我从事相同类型的工作时，这已经变得更容易了。
You can still do similar types of programming only to get to protected hardware you will need to implement a device driver. I assume that this has gotten easier since the 1980s when I was doing the same type of work.
微软现在真的在进行硬件握手吗？ 多年来NT、win2000和XP都没有在硬件上做握手。 相反，当 fifo 到达某个点时，设备驱动程序将手动更改 cts 线。 这意味着导致设备驱动程序丢失数据非常简单，例如用鼠标抓取一个窗口并在屏幕上绕圈（确保在所有或部分通道中将该窗口从屏幕左侧移开） ）。 Alt-Enter 将命令提示符切换到全屏或从全屏切换是一种导致数据丢失的简单方法。 或者任何其他导致足够中断延迟的事情。 基本上，微软的硬件流控制不是硬件，而是软件流控制，即使硬件确实具有硬件流控制功能，微软的驱动程序也没有设置该位。 SeaLevel 最终确实支持了这一点，好吧，您必须在 SetCommState() 中放置正确的不相关设置才能启用它。
至于控制信号的程序，请使用 SetCommState()。
Is microsoft actually doing hardware handshaking now? For many years NT, win2000 and XP did not do handshaking in the hardware. Instead when the fifo reached a certain point the device driver would manually change the cts line. Which means it was incredibly simple to cause the device driver to lose data, grab a window with the mouse and do circles around the screen for example (making sure you take that window off the left side of the screen on all or some of the passes). Alt-enter to take a command prompt to/from full screen was an easy way to cause a data loss. Or anything else that causes enough of an interrupt latency. Basically microsofts hardware flow control is not hardware but software flow control, even if the hardware does have hardware flow control capabilities microsft's drivers were not setting that bit. SeaLevel eventually did support that bit, well sorta, you had to put the right unrelated settings in SetCommState() to enable it.
As far as your program controlling the signals, use SetCommState().
有一些 USB 转串行适配器不支持 DTR/DSR/DCD 流控制。
所以这可能就是你的情况。
http://www.digi.com/support/kbase/kbaseresultdetl?id=588
There are some USB to Serial adapters that do not support the DTR/DSR/DCD flow control.
So may be this is your case.
http://www.digi.com/support/kbase/kbaseresultdetl?id=588