Delphi 串行通信（RTS）和Windows 7
我正在Windows7下的Delphi2010 XE RAD Studio上开发Delphi应用程序。我的应用程序在串行端口上不间断地通信。我正在使用AsyncPro for Delphi 2010。串行通信和我开发的计算机上的其他一切都很好，没有任何问题。但是，当我的应用程序的发布版本在另一个Windows 7系统上运行时，串行通信完全失败。我们探测了串行通信本身，寻找答案，发现发送请求（RTS）线路并没有在发送所有字节后立即被丢弃，而在我的开发计算机上，RTS线路被正确丢弃 即使我显式地将RTS线置于low或false状态，RTS线也不会立即下降，而是在15毫秒后下降。因此，我发布版本上的串行通信失败 我是否缺少有关Windows 7和串行通信问题的重要信息 更新：我刚刚在Delphi XE的Aysncpro 5.0中发现了错误。这很奇怪。当我的Delphi XE IDE打开或运行时，我的程序可以完美地通信。当我在程序运行时关闭或关闭Delphi XE IDE时，同一程序通信不畅或超时。 如果你知道为什么会这样，请插嘴 任何帮助都将不胜感激Delphi 串行通信（RTS）和Windows 7,delphi,windows-7,serial-port,Delphi,Windows 7,Serial Port,我正在Windows7下的Delphi2010 XE RAD Studio上开发Delphi应用程序。我的应用程序在串行端口上不间断地通信。我正在使用AsyncPro for Delphi 2010。串行通信和我开发的计算机上的其他一切都很好，没有任何问题。但是，当我的应用程序的发布版本在另一个Windows 7系统上运行时，串行通信完全失败。我们探测了串行通信本身，寻找答案，发现发送请求（RTS）线路并没有在发送所有字节后立即被丢弃，而在我的开发计算机上，RTS线路被正确丢弃 即使我显式地将R
谢谢，这肯定是另一台机器上的驱动程序问题，对吗？硬件流控制在我的W7测试箱（和Vista开发机器）上也运行良好。如果您的Apro已经正确设置了DCB，并且由于您的“手动”测试，它听起来像是正确的，那么驱动程序应该可以工作 从用户模式“手动”RTS更改为15毫秒是令人伤心的，但在Windows上一点也不奇怪-这就是为什么驱动程序应该这样做 Rgds，
马丁最近几次，我看到了随机的令人费解的废话，好像我什么都试过了，好几个月都没能解决 我发现了两种不同的常见原因：
最简单的方法是使用不同的USB-to-serial适配器进行尝试，如果这不能解决您的问题，我会尝试退出AsyncPro，我也遇到过很多随机问题，或者编写您自己的串行端口类，或者使用TComPort。我在使用使用使用com端口“reader/writer”类的TThread方面有很长的经验，并且发现这是最可靠的方法，因为您可以直接调整Win32重叠IO调用的低级元素以满足您的需要，并且还可以确保不会有额外的复杂性/开销。（AsyncPro的复杂性和开销是bug的一个重要潜在来源。）对我来说，这听起来像是一个计时器分辨率问题。我在尝试使用基于事件的计时器写入USB FTDI驱动程序时遇到了相同的问题，
timeSetEvent（）timeBeginPeriod（1）timeBeginPeriod（）timeBeginPeriod（1）timeEndPeriod（1）N@问题是，Warren p，在Windows 7之前，我们使用AsyncPro已经7年了，没有出现任何问题。我们的软件已经相当成熟了。因此，我们并不期待Asyncpro 2010会出现任何问题。Aysncpro在我的windows 7开发计算机上工作得非常好，而不是在任何其他windows 7系统上，这意味着驱动程序或硬件方面存在差异，这是失败的。我只是在寻找解决方案的建议或想法。谢谢。+1用于t导入。我使用AsyncPro已有多年，但W7开始出现问题。对我来说，改变它的不是Windows 7，而是内置串行端口的终结，以及USB到串行适配器的普及。我从来没有遇到过AsyncPro的问题，直到它处理流量控制信号的变化，以及其他类似的问题，与脆弱的usb驱动程序混合在一起。它也不是闻所未闻的问题，因为一个坏的USB电缆。我在更换USB电缆时遇到了一些问题。我尝试了导入，但演示在我的windows 7电脑上都不起作用。我认为导入对于我的应用程序来说太简单了。我的程序以RS485模式与串行端口上启用的DTR通信。程序发送和接收的不是acii字符，而是字节或十六进制值。就Asyncpro而言，是否可能因为登录的用户不是管理员而导致通信出现问题。在我的电脑上，我是唯一的用户，也是管理员。事实上，导入非常适合RS485，这正是我所使用的