A while ago I posted a message asking for suggestions to solve a problem I was having in getting XP to load software into an embedded device I had worked on. Win98 worked fine. The priorities changed for a bit and wasn't able to get back to it until recently. Since there were many helpful responses I owe the solution back to the group. XP will transmit serial data freely, but will not receive data unless DSR is set. Win98 doesn't seem to care.
Thanks again,
bosch
I am using Delphi. In your case, was the comm bi-directional?
-bosch
That cannot be true because I transmited data from one COM port to another COM port and I only had Rx, Tx and GND lines connected to the ports and it worked as expected. That was all done on Windows XP, by using pure Win32 in Visual Studio 6.
BTW, what program (VB, VC++, Delphi) are you programming in for Windows?
Not quiet, there seems to be a problem, but it's depending on the OS, the hardware and the wheather ;-) Although is from a specific commport component, I've seen similar effects with other drivers.
Many users reported a problem : when there isn't any device connected to the COM port, the ReadFile/WriteFile APIs hang the system (or at least slow down it). It seems that the Win32 kernel always waits for the DSR line to be set. To prevent hangs, set CheckLineStatus to TRUE before calling Connect. When CheckLineStatus is TRUE, the TCommPortDriver component never calls ReadFile/WriteFile APIs if none of the following are true:
for ReadFile : 1. at least one must be set (CTS, DSR, RING, RLSD) 2. or: (RX queue is not empty)
for WriteFile: 1. at least one must be set (CTS, DSR, RING, RLSD) 2. and (TX queue is not full)
Checking the state of CTS, DSR, RING and RLSD signal doesn't work if you are using a three wire cable (RX, TX and GND).
Stef Mientki
Visual Studio, ... ... isn't that from M$ ? Well they have the advantage of knowing where the bugs are, and so they can write an (invisible) wrapper around it. Stef Mientki
Make sure you're specifying "No DSR Sensitivity" for the device with SetCommState() (DCB.fDsrSensitivity = FALSE) just after the CreateFile().
The ports were bidirectional, and I'm pretty sure that your problem is caused by Component you are using, because when I used pure Win32 programming with standard Win APIs (Win XP) I had no problems reported by other (when no device is connected or so ...).
Others have written about those components so I hope that helps you.
Best regards, Mickey.
Jonathan Bosch wrote in news: snipped-for-privacy@corp.supernews.com:
Windows?
If you are doing it in straight WinAPI, make sure to do the following:
const dcb_Binary = $00000001; var dcb: TDCB;
fillchar( dcb, sizeof(dcb), 0 ); // Setup dcb (Device Control Block) fields dcb.DCBLength := sizeof(dcb); // dcb structure size // set baud, etc... // code snipped
Handle := CreateFile(Port, GENERIC_READ or GENERIC_WRITE, 0, // Not shared nil, // No security attributes OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0 // No template ) ;
If Handle $FFFFFFFF then Begin // Set fBinary: Win32 does not support non binary mode transfers // (also disable EOF check) dcb.Flags := dcb_Binary OR DTR_CONTROL_DISABLE OR RTS_CONTROL_DISABLE; SetCommState( Handle, dcb ); // code snipped...
The dcb.Flags and SetCommState are the important bits. I set all dcb properties directly. You could also use GetCommState and just modify the ones you want to change.
HTH. Jeff.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.