Hi,
I have a driver which communicates with a modem over serial (V.24) or USB ports.
The driver is a little like Unimodem. With the V.24 (COM) port implementation,
I’m having problems reading after the modem goes into ‘data mode’ (i.e. after
a call is connected). RAS is using this driver for dial-up networking so a PPP
conversation ensues after the connection. A tx/rx sequence should occur (LCP
negotiation) but instead I see the RAS times-out the first tx request (after
2 seconds) and retransmits (so I get a tx/tx sequence) and then the serial port
driver beneath me sends me a double response (2 LCP responses from the remote
side of the connection). The double-response is usually in or around the 180
byte mark. I would expect to receive a 90 byte (-ish) response but it seems
that the device (or the serial port driver) is holding back until it has accumulated
some data before delivering the incoming data to my async read complete. This
would seem to be the case but after this initial blocking, I’m able to receive
read buffers < 180 bytes. It just seems to be the initial read after going into
data mode.
I’m not seeing any of this behaviour with the USB implementation which works
fine. I see the expected tx/rx sequence.
Can anyone give me a hint as to what would be causing the serial driver to hold
back? I’ve set the following parameters after opening the COM port with ZwCreateFile:
Queue size: 512 (read) 512 (write)
Handshake: RTS/CTS
XonLimit: 128
XoffLimit: 0
Read time out: 20 msecs
Baud: 115200
Line control: 1 stop bit, No parity, 8 data bits
Thanks,
Lee
*************************** ADVERTISEMENT ******************************
For ALL the latest Soccer news on your club, GAA sports results and the
latest on your F1 stars plus much more check out
http://sport.iol.ie/sport. Sport On-Line… It’s a passion
> response but it seems
that the device (or the serial port driver) is holding back
until it has accumulated
some data before delivering the incoming data to my async
read complete.
Do you create your read IRP inside your unimodem-like driver?
If so, how many characters you require, and which read timeout
handling you set before sending the read Irp to the serial driver
(i.e. how exactly you set all members of the SERIAL_TIMEOUTS
structure)?
Carlo
Thanks for the interest Carlo.
Do you create your read IRP inside your unimodem-like driver?
Yes.
If so, how many characters you require,
I send down 4 IRP_MJ_READ buffers with 512 byte buffers.
and which read timeout handling you set before sending the read Irp
to the serial driver (i.e. how exactly you set all members of
the SERIAL_TIMEOUTS structure)?
SERIAL_TIMEOUTS serialTimeouts;
serialTimeouts.ReadIntervalTimeout = 0x14;
serialTimeouts.ReadTotalTimeoutMultiplier = 0;
serialTimeouts.ReadTotalTimeoutConstant = 0;
serialTimeouts.WriteTotalTimeoutMultiplier = 0;
serialTimeouts.WriteTotalTimeoutConstant = 0xffffffff;
Can you see anything wrong? It’s just the initial read that it seems to choke
on. Afterwards I can see smaller (80 and 40 byte) reads arriving in my completion
routine.
Thanks again,
Lee
*************************** ADVERTISEMENT ******************************
For ALL the latest Soccer news on your club, GAA sports results and the
latest on your F1 stars plus much more check out
http://sport.iol.ie/sport. Sport On-Line… It’s a passion
> serialTimeouts.ReadIntervalTimeout = 0x14;
serialTimeouts.ReadTotalTimeoutMultiplier = 0;
serialTimeouts.ReadTotalTimeoutConstant = 0;
serialTimeouts.WriteTotalTimeoutMultiplier = 0;
serialTimeouts.WriteTotalTimeoutConstant = 0xffffffff;
With this setting, the read should wait (without timeouts) until
the first char is received, then continue waiting until
- all requested chars are received
or
- 20 mSec elapse without receiving characters (after at least one
has been received)
Is this behavior what you want? (the setting of the timeouts is
quite tricky; one good reference is the SERIAL.SYS sample in the
Win2K DDK, check out how the SERIAL_TIMEOUTS are handled by the
SerialStartRead() in READ.C)
Also, be sure to set serialTimeouts *before* the answer has been
received (with a half-duplex protocol I would, in sequence, set
the Tx/Rx timeouts, send out the data and wait for the answer)
HTH
Carlo