虚拟 COM 通信问题答案

【问题标题】：Virtual COM Communications Issue虚拟 COM 通信问题
【发布时间】：2013-02-17 08:28:21
【问题描述】：

我正在开发用于嵌入式设备的通信设备类 (CDC) 驱动程序，即 USB 2.0 的全速实现。 COM 端口设置为 115200、8 位、无奇偶校验、1 个停止位、无流量控制。我们的 PC 应用程序（32 位、Windows 7、.NET 2.0）通过虚拟 COM 端口与目标设备进行通信，目标设备上的该端口可以连接到 FTDI（USB-to-SCI 桥接器）芯片或集成的 USB微控制器中的外围设备，具体取决于应用程序选择的端口。

两个虚拟 COM 端口在使用 Realterm 时都可以正常工作。然而，虽然我们的桌面应用程序使用通过 FTDI 芯片连接的虚拟 COM 端口工作，但在尝试使用通过微控制器的集成 USB 外围设备连接的虚拟 COM 时，它会挂起。

当使用集成 USB 通过虚拟 COM 端口连接时，应用程序在第二次调用 SerialPort.Write(...) 时始终挂起。使用Serial Monitor from HHD Software 我可以看到数据是在第一次调用SerialPort.Write(...) 时传输的。但是，目标设备永远不会收到该数据。

这很奇怪，因为我在以前的项目中唯一一次看到类似问题是总线两侧的流量控制设置不匹配。

其他信息...

这是在运行通过集成 USB 外围设备连接到目标设备的 PC 应用程序时从各种端口监控工具捕获的数据。任何见解将不胜感激。

对于那些感兴趣的人，我正在使用 CodeWarrior 10.2 和飞思卡尔的 MCF51JM128。

任何想法或建议将不胜感激。谢谢。

【问题讨论】：

您是否尝试跟踪 Realterm 的操作？必须有差异才能显示解决方案。
@jeb 我该怎么做？它是 Realterm 的功能之一吗？我承认我只熟悉它的一小部分功能。
不，但是像来自 sysinternals/microsoft 的 portmon 这样的工具可以显示端口的所有操作、打开/关闭以及读/写以及 Realterms 和您自己的其他程序的所有操作
这是什么uC？意思是“微控制器中的集成 USB 外围设备”中的一个。我见过的大多数虚拟 COM 东西似乎都不是很适合/优化。我怀疑UC在这里有问题。您必须记住，将它交给 uC 会增加很多开销。
我使用 FTDI 芯片组使用 COM 端口/USB 电缆开发了一个非常相似的产品...不确定我是否可以建议您尚未尝试过的任何东西，但是两个快速（可能是愚蠢的）问题：您是否尝试将 WriteTimeout 设置为某个大数字（例如 60 秒）？另外，您是否尝试在写入之间关闭/重新打开 COM 端口？后者是我发现效果极差的东西（因为关闭端口的请求的异步性质及其实际关闭）。

标签： embedded usb .net-2.0 serial-communication cdc

【解决方案1】：

从日志中可以清楚地看出，您犯了一个典型的错误，即不注意硬件握手信号。这只是偶然的结果，像 Realterm 这样的终端模拟器永远不会犯这个错误。

您必须将 DtrEnable 属性设置为 true。这将打开数据终端就绪信号。这很重要，因为 RS-232 是未端接的总线，因此当电缆断开或电源关闭时会受到电气噪声的影响。 DTR 使设备相信它实际上已连接到受电设备。这当然是在您的情况下模拟的，但驱动程序或固件通常仍会实现 RS-232 行为。

RtsEnable 属性很重要，用于与设备握手，防止应用程序未及时清空缓冲区时接收缓冲区溢出。您确实应该将 Handshake 属性设置为 Handshake.RequestToSend，这是设备实现它的最常见方式。然后它还负责打开 RTS。如果您出于某种原因必须使用 Handshake.None，那么您必须通过将 RtsEnable 设置为 true 来自行打开它。

这应该解决问题。如果您仍然遇到问题，请使用 PortMon 监视 Realterm 初始化驱动程序的方式。将您看到的命令与 SerialPort 类发送的命令进行比较。确保它们相同。在价值上，而不是在顺序上。

【讨论】：

汉斯，这就是问题所在！感谢您富有洞察力的回答，让我重回正轨！