串行通信(RTS)和Windows 7

ThN*_*ThN 7 delphi serial-port windows-7

我正在Windows 7下的Delphi 2010 XE RAD Studio上开发Delphi应用程序.我的应用程序不停地在串口上进行讨论.我正在使用AsyncPro for Delphi 2010.串口通信和我开发的计算机上的所有其他工作都很好,没有任何问题.但是,当我的应用程序的发行版本在另一个Windows 7系统上运行时,串行通信完全失败.我们探测了串行通信本身的答案,发现在发送所有字节后不会丢弃请求发送(RTS)线,而在我的开发计算机上,RTS线被正确删除.

即使我明确地将RTS线丢弃到低或假状态,RTS线也不会立即下降,但是在15毫秒之后.因此,我的发布版本上的串行通信失败了.

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

更新:我刚刚发现我的Aysncpro 5.0 for Delphi XE的错误.真奇怪.当我的Delphi XE IDE打开或运行时,我的程序正在完美地进行通信.当我的程序运行时关闭或关闭我的Delphi XE IDE时,相同的程序不能很好地通信或超时.

如果你知道它为什么会发生,请编钟.

任何帮助将不胜感激.

谢谢,

War*_* P 5

最近几次我看到随机莫名其妙的废话,就像我尝试了一切,几个月都无法解决.

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

  1. ASYNC Professional有一些奇怪的故障,我无法解决,所以我放弃了它,并转移到TComPort.

  2. 我在USB驱动程序中发现了各种奇怪的流量控制错误.我发现FTDI芯片组USB到串口比其他更可靠.

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

  1. 某些时序更改会导致USB设备驱动程序失败,而不会失败.

  2. 你实际上有某种线程问题,比如竞争条件,导致你的ASync Pro组件变得混乱,看起来像你的端口正在发生的事情,但实际上它是ASYNC专业版.

最简单的方法是尝试使用不同的USB转串口适配器,如果这不能解决您的问题,我会想要拔出AsyncPro,我也有很多随机问题,并且要么自己编写串口类,或使用TComPort.我有一些使用TThread使用com端口"读/写"类的经验,并且发现这是最可靠的方法,因为你可以调整Win32重叠IO调用的低级元素,直接满足你的需求,并确保您没有一些额外的复杂性/开销妨碍您.(AsyncPro的复杂性和开销是错误的重要潜在来源.)


Nat*_*Nat 5

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

为了解决这个问题,我timeBeginPeriod(1)在线程中调用了最小系统范围的定时器分辨率.

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

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

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

N - [