Serial Communication (RTS) and Windows 7_问答_开发者

I am developing Delphi application on Delphi 2010 XE RAD Studio under Windows 7. My application talks on the serial port non-stop. I am using AsyncPro for Delphi 2010. Serial communication and everything else on the computer I develop with works great without any problem. However, when my release version of my application is run on another Windows 7 system, serial communication completely fails. We probed the serial communication itself for an answer and found out that Request to Send (RTS) line is not dropped right after sending all the bytes, whereas on my development computer RTS line is dropped correctly.

Even when I explicitly drop the RTS line to low or false state, RTS line doesn't drop right away but after good 15 milliseconds. Thus, serial communication on my release version is failing.

Am I missing important information about Windows 7 and serial comm开发者_如何学运维unication issues?

UPDATE: I just found the bug with my Aysncpro 5.0 for Delphi XE. It is weird. When my Delphi XE IDE is open or running, my program is communicating flawlessly. When I shutdown or close my Delphi XE IDE while my program is running, the same program doesn't communicate very well or it times out.

Chime in if you have any idea why it is happening.

Any help will be appreciated.

Thank you,

Sounds like a timer resolution problem to me. I had the same problem trying to write to a USB FTDI driver using an event based timer with timeSetEvent()... When Delphi loads, it changes the timer resolution to less than 20ms, which made my app work fine. When the IDE wasn't running I couldn't get things to work below 20ms +/- 5ms (the default Windows resolution I believe).

To fix the problem, I call timeBeginPeriod(1) in the thread to set the minimum system wide timer resolution.

I believe this affects the resolution of other time based events, because I get better than +/-5ms accuracy on other (non-multimedia timer) wait events in my app when I use timeBeginPeriod().

So, what I'm suggesting is that somewhere in the AsyncPro code it's using some time based event or call back... That would be affected by Delphi's change to the timer resolution when it is loaded. Try calling timeBeginPeriod(1) somewhere in your app when it starts and see if there is a change.

Oh, and don't forget to call timeEndPeriod(1) when your app shuts down.

Last few times I saw random inexplicable crap like I tried everything, and was unable to solve it for months.

I found two different common causes:

ASYNC Professional has some weird glitches that I was unable to solve, so I dropped it, and moved to TComPort.
I found all kinds of strange flow control bugs in USB drivers. I found FTDI chipset USB-to-serial more reliable than others.

The Debug build not having the problem could be two things:

Certain timing changes cause the USB device driver that was failing, not to fail.
You actually have some kind of a thread problem, like a race condition, leading to your ASync Pro components messing up in a way that looks like something's happening to your port, but really it's ASYNC pro.

The easiest thing to do is to try it with a different USB to serial adapter, and if that doesn't solve your problem, I would be tempted to pull out AsyncPro which I have also had many random problems with, and either write your own serial port class, or use TComPort. I have some long experience using a TThread that uses a com port "reader/writer" class and have found this the most reliable way to go, because you can tweak low level elements of the Win32 overlapped-IO calls, directly to meet your needs, and also be sure that you don't have some extra complexity/overhead getting in your way. (AsyncPro's complexity and overhead, are a significant potential source of bugs.)

This has to be a driver problem on the other machine, surely? Hardware flow control works fine on my W7 test box as well, (and Vista development machine). If your Apro has set the DCB correctly, and it sounds like it does because of your 'manual' tests, the driver should work...

15ms for a 'manual' RTS change from user mode is sad, but not at all unusual on Windows - that's why the driver should do it.

Rgds, Martin