串行通信RTS和Windows 7

问题描述

| 我正在Windows 7下的Delphi 2010 XE RAD Studio上开发Delphi应用程序。我的应用程序不停地谈论串行端口。我在Delphi 2010中使用AsyncPro。我开发的计算机上的串行通信和其他所有东西都运行良好，没有任何问题。但是，当我的应用程序的发行版在另一个Windows 7系统上运行时，串行通信完全失败。我们探究了串行通信本身的答案，发现发送完所有字节后，“发送请求”（RTS）行并没有被丢弃，而在我的开发计算机上，“ RTS”行被正确地丢弃了。 即使我将RTS线显式降低为低电平或错误状态，RTS线也不会立即掉线，而是会在15毫秒后掉线。因此，我的发行版上的串行通信失败。 我是否缺少有关Windows 7和串行通信问题的重要信息？ 更新：我刚刚在Delphi XE的Aysncpro 5.0中发现了该错误。真奇怪。当我的Delphi XE IDE打开或运行时，我的程序可以正常通信。当我在程序运行时关闭或关闭Delphi XE IDE时，同一程序无法很好地通信或超时。 如果您知道为什么会发生，请拨入。 任何帮助将不胜感激。 谢谢，     

解决方法

对我来说，这听起来像是计时器分辨率问题。尝试使用基于事件的计时器将ѭ0to写入USB FTDI驱动程序时，我遇到了同样的问题。当Delphi加载时，它将计时器分辨率更改为小于20ms，这使我的应用程序可以正常工作。当IDE不运行时，我无法在20ms +/- 5ms（我认为是默认的Windows分辨率）下工作。 为了解决这个问题，我在线程中调用ѭ1来设置最小的系统范围计时器分辨率。 我相信这会影响其他基于时间的事件的解析度，因为当我使用ѭ2I时，我的应用程序中的其他（非多媒体计时器）等待事件的准确度优于+/- 5ms。 因此，我的建议是AsyncPro代码中的某个地方正在使用基于时间的事件或回叫...这可能会受到加载时Delphi对计时器分辨率的更改的影响。尝试在应用启动时在应用中的某个地方调用

timeBeginPeriod(1)

，看看是否有变化。 哦，别忘了在应用关闭时调用call4ѭ。 N @     ,上几次，我看到随机莫名其妙的废话，就像我尝试了一切一样，几个月后都无法解决。 我发现了两种不同的常见原因： ASYNC Professional遇到了一些我无法解决的怪异故障，因此我放弃了该故障，转而使用TComPort。 我在USB驱动程序中发现了各种奇怪的流控制错误。我发现FTDI芯片组USB转串口比其他芯片更可靠。 没有问题的Debug版本可能是两件事： 某些时间更改会导致USB设备驱动程序出现故障，而不是失败。 实际上，您遇到了某种线程问题，例如竞争状况，导致您的ASync Pro组件混乱，看起来好像端口上正在发生某些事情，但实际上是ASYNC Pro。 最简单的方法是尝试使用其他USB到串行适配器，如果那不能解决您的问题，我很想退出AsyncPro，而我也遇到了很多随机问题，然后写一个拥有自己的串行端口类，或使用TComPort。我在使用使用com端口“ reader / writer”类的TThread方面有很长的经验，并且发现这是最可靠的方法，因为您可以调整Win32重叠IO调用的底层元素，直接满足您的需求，并确保您不会遇到一些额外的复杂性/开销。 （AsyncPro的复杂性和开销是潜在的重要漏洞来源。）     ,当然，这一定是另一台计算机上的驱动程序问题吗？硬件流控制在我的W7测试箱（和Vista开发机器）上也能正常工作。如果您的Apro正确设置了DCB，并且听起来像是通过“手动”测试所做的，则驱动程序应该可以工作... 从用户模式对“手动” RTS进行15ms的更改是令人遗憾的，但在Windows上一点也不罕见-这就是驱动程序应该这样做的原因。 Rgds， 马丁