串行通信 (RTS) 和 Windows 7答案

【问题标题】：Serial Communication (RTS) and Windows 7串行通信 (RTS) 和 Windows 7
【发布时间】：2011-09-02 14:24:00
【问题描述】：

我正在Windows 7 下的Delphi 2010 XE RAD Studio 上开发Delphi 应用程序。我的应用程序不停地在串口上说话。我正在为 Delphi 2010 使用 AsyncPro。串行通信和我开发的计算机上的其他所有东西都可以正常工作，没有任何问题。但是，当我的应用程序的发布版本在另一个 Windows 7 系统上运行时，串行通信完全失败。我们探查了串行通信本身以寻找答案，并发现在发送所有字节后，请求发送 (RTS) 行没有立即被丢弃，而在我的开发计算机上，RTS 行被正确丢弃。

即使我明确地将 RTS 线降至低或假状态，RTS 线也不会立即下降，而是在 15 毫秒后下降。因此，我的发布版本上的串行通信失败了。

我是否遗漏了有关 Windows 7 和串行通信问题的重要信息？

更新：我刚刚发现我的 Aysncpro 5.0 for Delphi XE 的错误。真奇怪。当我的 Delphi XE IDE 打开或运行时，我的程序可以完美地通信。当我在我的程序运行时关闭或关闭我的 Delphi XE IDE 时，同一程序不能很好地通信或超时。

如果您知道为什么会发生这种情况，请加入。

任何帮助将不胜感激。

谢谢，

【问题讨论】：

正如我所说，AsyncPro 就是正在发生的事情。 :-) 现在您知道这是 async pro 中的一个错误。您无法让 TComPort 演示工作可能很简单，而且很容易克服。提出一个问题，我会为你发布一个工作演示。
您的应用程序是否使用 BPL（运行时包）？

标签： delphi windows-7 serial-port

【解决方案1】：

对我来说，这听起来像是一个计时器分辨率问题。我在尝试使用带有timeSetEvent() 的基于事件的计时器写入 USB FTDI 驱动程序时遇到了同样的问题。当 Delphi 加载时，它将计时器分辨率更改为小于 20 毫秒，这使我的应用程序工作正常。当 IDE 没有运行时，我无法在 20 毫秒 +/- 5 毫秒（我相信的默认 Windows 分辨率）以下工作。

为了解决这个问题，我在线程中调用timeBeginPeriod(1) 来设置最小系统范围的计时器分辨率。

我相信这会影响其他基于时间的事件的分辨率，因为当我使用 timeBeginPeriod() 时，我的应用程序中的其他（非多媒体计时器）等待事件的准确度优于 +/-5ms。

所以，我的建议是，在 AsyncPro 代码的某个地方，它正在使用一些基于时间的事件或回调……这将受到 Delphi 在加载时更改计时器分辨率的影响。尝试在应用启动时调用timeBeginPeriod(1)，看看是否有变化。

哦，当您的应用关闭时，别忘了致电timeEndPeriod(1)。

【讨论】：

有趣。在 Embarcadero 组中，还有另一个时间问题 - 线程似乎需要 15-30 毫秒才能在应用程序启动时安排好。我从来没有注意到这一点，因为我总是在启动时创建我的并且永远不会终止或再制作。只是出于兴趣，我将 GetTickCount 放在当前应用程序的线程 ctor 中，并将另一个 GTC 放在“执行”方法的顶部。果然，当我的 UI 显示差异时，我得到了“15”。最终，我尝试在 IDE 之外运行我的应用程序 - '0'。我从来没有对 D5 的系统时间进行过如此讨厌的摆弄！
嗯.. 我的串口代码没有使用任何明确的计时器，只是 COMMTIMEOUTS 的东西。我对硬件流控制没有任何问题，所以也许你是对的。是时候拆开 Apro 了吗？
@Martin - 不需要计时器，'Sleep(1)' 将在默认分辨率下等待 15.625 毫秒（使用普通硬件），在最高分辨率下等待约 1 毫秒。正如 Nat 指出的那样，它也与 Delphi 没有特别的关系，它是在系统范围内设置的。一旦应用程序设置了更高的分辨率，其他人也会使用它。 OP 可以与 f.i. 进行相同的观察。 MSN messenger 或 Windows Media Player 或其他任何东西，而不是 Delphi IDE。
真的很有趣。我从来没有玩过这个设置。即使提高计时器的分辨率也只会使 Windows 性能稍微有用一些。
@Sertac 实际上，任何更改分辨率的应用程序都可以创建相同的效果。它可能是应用程序可以更改的唯一可直接影响其他应用程序的 API 调用之一。不是很糟糕，但有时确实很难调试！

【解决方案2】：

最近几次我看到随机的莫名其妙的废话，就像我尝试了所有方法一样，但几个月都无法解决。

我发现了两个不同的常见原因：

ASYNC Professional 有一些我无法解决的奇怪故障，所以我放弃了它，并移至 TComPort。
我在USB驱动中发现了各种奇怪的流量控制错误。我发现 FTDI 芯片组 USB 转串口比其他芯片组更可靠。

没有问题的调试版本可能是两件事：

某些时序更改会导致 USB 设备驱动程序失败，而不是失败。
您实际上遇到了某种线程问题，例如竞态条件，导致您的 ASync Pro 组件出现混乱，看起来好像您的端口发生了什么事，但实际上是 ASYNC pro。

最简单的做法是尝试使用不同的 USB 转串口适配器，如果这不能解决您的问题，我会很想拔出 AsyncPro，我也遇到过很多随机问题，或者编写自己的串口类，或使用 TComPort。我在使用使用 com 端口“读取器/写入器”类的 TThread 方面有一些长期的经验，并且发现这是最可靠的方法，因为您可以直接调整 Win32 重叠 IO 调用的低级元素以满足您的需求，并且还要确保您不会遇到一些额外的复杂性/开销。（AsyncPro 的复杂性和开销是一个重要的潜在错误来源。）

【讨论】：

问题是，Warren P，在过去的 7 年中，我们一直使用 AsyncPro，直到 Windows 7 都没有出现问题。我们的软件已经非常成熟。因此，我们预计 Asyncpro 2010 不会出现任何问题。事实上，Aysncpro 在我的 Windows 7 开发计算机上完美运行，而不是任何其他 Windows 7 系统，这意味着驱动程序或硬件存在差异。我只是在寻找解决方案的建议或想法。谢谢。
+1 用于 TComPort。我已经使用 AsyncPro 多年，但开始遇到 W7 问题。
改变它的不是 Windows 7，而是内置串行端口的终结，以及无处不在的 USB 到串行适配器。我从来没有遇到过 AsyncPro 的问题，直到它处理流量控制信号和其他类似问题的变迁与易碎的 USB 驱动程序混合在一起。由于 USB 电缆损坏而出现问题也并非闻所未闻。我在更换 USB 电缆时遇到了问题。
好吧，我尝试了 TComport，但该演示甚至无法在我的 Windows 7 计算机上运行。我认为 TComport 对我的应用程序来说太简单了。我的程序在 RS485 模式下进行通信，并在 SerialPort 上启用了 DTR。该程序不是发送和接收 acii 字符，而是字节或十六进制值。就 Asyncpro 而言，是否有可能因为登录的用户不是管理员而导致通信有问题。在我的 PC 上，我是唯一的用户，也是管理员。
TComPort 实际上非常适合 RS485，而这正是我使用它的目的。更复杂的代码（AsyncPro）只会导致 RS485 出现问题。

【解决方案3】：

这肯定是另一台机器上的驱动程序问题吧？硬件流控制在我的 W7 测试盒（和 Vista 开发机器）上也能正常工作。如果您的 Apro 已正确设置 DCB，并且由于您的“手动”测试听起来确实如此，则驱动程序应该工作...

从用户模式“手动”更改 RTS 需要 15 毫秒，这很可悲，但在 Windows 上一点也不稀奇 - 这就是驱动程序应该这样做的原因。

Rgds, 马丁

【讨论】：

经过至少一整天的测试和测试。我发现了这个错误。我的程序在 Delphi IDE 运行时可以正确通信，但在关闭时不能正确通信。不知何故，链接到 Delphi IDE 的重要库或文件在执行开始时被加载。我的程序也需要该文件才能正确通信。重新启动系统后，我启动了我的应用程序，它无法自行运行，除非 Delphi IDE 正在运行。你认为是什么原因。
另一个有趣的 IDE:( 除了从 IDE 进行实际手动调试之外，我已经停止运行任何东西。我过去常常在一天结束时按“F9”，看看我的应用程序是否早上还在运行。现在我找到带有资源管理器的 EXE 并从那里运行它。IDE 肯定会在“F9”上注入几个带有线程的 DLL，但它们可能会影响 COM 端口的功能性我不知道，我很害怕。不过，我还要提防一件事，所以谢谢，即使我没有答案！