串行通信(RTS)与Windows 7

Question

我是在Windows 7下在Delphi 2010 XE RAD Studio上开发Delphi应用程序的。我的应用程序是关于串口不间断的。我正在使用AsyncPro的德尔菲2010。串行通讯和我开发的电脑上的其他所有东西，工作都很好，没有任何问题。但是，当我发布的应用程序版本在另一个Windows 7系统上运行时，串行通信完全失败。我们对串行通信本身进行了探讨，发现发送请求( RTS )行在发送所有字节后并没有立即删除，而在我的开发计算机上，RTS行被正确删除。

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

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

更新:我刚刚在Delphi的Aysncpro5.0中找到了这个bug。这很奇怪。当我的Delphi打开或运行时，我的程序的通信就完美无缺。在我的程序运行时，当我关闭或关闭Delphi时，同一个程序不能很好地通信，否则就会超时。

如果你知道为什么会这样的话，就插话吧。

任何帮助都将不胜感激。

谢谢,

Answer 1

听起来像是计时器解决问题。我在使用基于事件的计时器与timeSetEvent()一起写入USB驱动程序时遇到了同样的问题.当Delphi加载时，它将计时器分辨率更改为小于20 my，这使我的应用程序正常工作。当IDE没有运行时，我无法在20 5ms +/- 5ms以下工作(我认为这是默认的Windows分辨率)。

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

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

所以，我的建议是，在AsyncPro代码的某个地方，它正在使用一些基于时间的事件或回调.这将受到Delphi在加载时对计时器解析的更改的影响。当应用程序启动时，尝试在应用程序的某个位置调用timeBeginPeriod(1)，并查看是否有更改。

哦，当你的应用程序关闭时，别忘了打电话给timeEndPeriod(1)。

N@

Answer 2

最近几次，我看到了像我试过所有东西一样的杂乱无章的垃圾，几个月来一直没能解决。

我发现了两种不同的共同原因：

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

没有问题的Debug构建可能有两件事：

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

。

最简单的方法是尝试使用与串行适配器不同的USB，如果这不能解决您的问题，我会尝试提取AsyncPro (我也有很多随机问题)，或者编写您自己的串口类，或者使用TComPort。我长期使用使用com端口"reader/writer“类的TThread，并且发现这是最可靠的方法，因为您可以直接调整Win32重叠的IO调用的低级别元素，以满足您的需求，并且确保您没有额外的复杂性/开销。(AsyncPro的复杂性和开销是bug的一个重要潜在来源。)

Answer 3

这一定是另一台机器的驱动问题，对吧？硬件流控制在我的W7测试盒(和Vista开发机器)上也能很好地工作。如果您的Apro设置了正确的DCB，听起来就像因为您的“手动”测试，驱动程序应该工作.

15毫秒的“手动”RTS从用户模式改变是可悲的，但并不是不寻常的Windows -这就是为什么驱动应该这样做。

雷格斯·马丁