Hi,
I am working on a legacy NT modem device driver, which sits between the real
modem DSP and NT upper level services. I am not familiar with the UART
serial interface handshaking. So here I am with a question about CTS/DSR.
I found in the driver that NT upper layer only waits on DSR state change not
CTS. So when the modem DSP’s xmit buffer is full, and the driver needs to
temporarily stop the DTE from continiously sending data, it can only flags
the DSR state.
NT upper layer then comes back with a DTR CLEAR, which, based on the current
driver implementation, disconnects the modem connection. That’s the problem.
So my questions are:
- Is there a way to let NT also wait on CTS change?
- DTR is used to indicate DTE is powered on and ready. But in this case,
DTR CLEAR appreantly doesn’t mean DTE is down and not ready. So can I say
that, in the middle of a connection, DTR CLEAR would mean DTE temporily
stops sending?
- Can someone point me to a place where talks more about Windows NT serial
flow controls or modem device driver implementations.
Thanks.
Lee
There are at least three forms of flow control that the user of a com device
can specify, and some of these involve CTS/RTS in various ways. However, it
is up to the user program to specify the correct form of handshaking for the
current communications path and device. All the driver can do is obey what
it is told to do.
Loren
I found in the driver that NT upper layer only waits on DSR state change
not
CTS. So when the modem DSP’s xmit buffer is full, and the driver needs to
temporarily stop the DTE from continiously sending data, it can only flags
the DSR state.
NT upper layer then comes back with a DTR CLEAR, which, based on the
current
driver implementation, disconnects the modem connection. That’s the
problem.
So my questions are:
- Is there a way to let NT also wait on CTS change?
Yes.
- DTR is used to indicate DTE is powered on and ready. But in this case,
DTR CLEAR appreantly doesn’t mean DTE is down and not ready. So can I say
that, in the middle of a connection, DTR CLEAR would mean DTE temporily
stops sending?
You have to decide if you are DCE or DTE, which isn’t always that obvious.
Then you should use the appropriate signals as they have been defined, if
the external device will let you do that. If not, you have to hack until
you find out how it has been mis-implemented and work with that.
- Can someone point me to a place where talks more about Windows NT
serial
flow controls or modem device driver implementations.
Look up SetCommState. It isn’t real obvious from the documentation how to
use this if you don’t know quite a lot about serial stuff, but it is the
function that does it. Also check out SetCommTimeouts.
I assume your “modem device driver” is a user mode application.
Can someone point me to a place where talks more about Windows NT serial
flow controls
Allen Denver, ‘Serial Communications in Win32’, Microsoft Windows Developer
Support, December 11, 19951.
Is there a way to let NT also wait on CTS change?
Search for EV_CTS in the above document.
DTR CLEAR would mean DTE temporily stops sending
By convention, the DTR line is used to signal if the device is turned on or
off (but this is application dependent). If you want the serial driver (not
your “modem driver”) to stop sending data when the receive buffer on the
other side is full, set up hardware or software flow control. The other side
of the serial line needs to use the same type of flow control for this to
work. Look for the “Flow control” section in the above document. I am not
sure exactly how it works with modems.
Slawek
“Li Hao” wrote in message news:xxxxx@ntdev…
> Hi,
>
> I am working on a legacy NT modem device driver, which sits between the
real
> modem DSP and NT upper level services. I am not familiar with the UART
> serial interface handshaking. So here I am with a question about CTS/DSR.
>
> I found in the driver that NT upper layer only waits on DSR state change
not
> CTS. So when the modem DSP’s xmit buffer is full, and the driver needs to
> temporarily stop the DTE from continiously sending data, it can only flags
> the DSR state.
> NT upper layer then comes back with a DTR CLEAR, which, based on the
current
> driver implementation, disconnects the modem connection. That’s the
problem.
>
> So my questions are:
> 1. Is there a way to let NT also wait on CTS change?
> 2. DTR is used to indicate DTE is powered on and ready. But in this case,
> DTR CLEAR appreantly doesn’t mean DTE is down and not ready. So can I say
> that, in the middle of a connection, DTR CLEAR would mean DTE temporily
> stops sending?
> 3. Can someone point me to a place where talks more about Windows NT
serial
> flow controls or modem device driver implementations.
>
> Thanks.
>
> Lee
>
>
>
> By convention, the DTR line is used to signal if the device is turned on or
Usually, putting DTR low means - total reset of the attached device, if not
powering it down.
Mice are powered off the DTR line.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Thanks for the reply. In my case, the user mode app is NT’s
Dialup-Networking, and I have turned on the Hardware Flow Control at the
modem’s advanced setting. However, even after all those, I still only
see 0x4B2 in my driver’s WaitMask set by NT through
IOCTL_SERIAL_SET_WAIT_MASK, and according to bitmask definitions in
ntddser.h, CTS is not monitored. That explained why the driver contined
to receive packets even after it toggled the CTS state by returning
SERIAL_EV_CTS to its upper layer.
So to better phrase my question, why does the WaitMask not include CTS
when the Modem’s Hardware Flow Control is turned on? What did I miss?
Thanks.
Loren Wilton wrote:
There are at least three forms of flow control that the user of a com device
can specify, and some of these involve CTS/RTS in various ways. However, it
is up to the user program to specify the correct form of handshaking for the
current communications path and device. All the driver can do is obey what
it is told to do.
Loren
>I found in the driver that NT upper layer only waits on DSR state change
not
>CTS. So when the modem DSP’s xmit buffer is full, and the driver needs to
>temporarily stop the DTE from continiously sending data, it can only flags
>the DSR state.
>NT upper layer then comes back with a DTR CLEAR, which, based on the
current
>driver implementation, disconnects the modem connection. That’s the
problem.
>So my questions are:
>1. Is there a way to let NT also wait on CTS change?
Yes.
>2. DTR is used to indicate DTE is powered on and ready. But in this case,
>DTR CLEAR appreantly doesn’t mean DTE is down and not ready. So can I say
>that, in the middle of a connection, DTR CLEAR would mean DTE temporily
>stops sending?
You have to decide if you are DCE or DTE, which isn’t always that obvious.
Then you should use the appropriate signals as they have been defined, if
the external device will let you do that. If not, you have to hack until
you find out how it has been mis-implemented and work with that.
>3. Can someone point me to a place where talks more about Windows NT
serial
>flow controls or modem device driver implementations.
Look up SetCommState. It isn’t real obvious from the documentation how to
use this if you don’t know quite a lot about serial stuff, but it is the
function that does it. Also check out SetCommTimeouts.
>why does the WaitMask not include CTS
when the Modem’s Hardware Flow Control is turned on?
Why do you think the application should monitor the state of CTS when the
hardware flow control is on? Most likely you reason like this: I tell the
driver to use hardware flow control, and when the CTS goes low the driver
signals that fact to the application so that it knows it should stop
submitting the WriteFile requests to prevent the overflow of the transmit
buffer.
In fact, flow control is about preventing the overflow of the receive buffer
on the other side, not the transmit buffer on your side (I assume you
transmit characters and the other side is receiving). When you set up
hardware flow control you tell the driver to stop transmitting characters
(putting them out on the wire) when the CTS goes low. The application
typically does not need to monitor the state of CTS pin for hardware flow
control purposes, it is done on the driver level (sometimes even in hardware
if your chip supports that).
You may ask how the application knows to stop submitting the WriteFile
requests when the driver can not transmit because CTS is low?
I don’t think the aplication will send your driver a new WriteFile request
until the previous one is completed. It can be completed either after all
characters are transmitted after it times out.
If your driver keeps seeing IRP_MJ_WRITE Irps even though it does not
transmit any characters, it most likely means that the application is seeing
its WriteFile requests timing out and is resubmitting them. So you even if
you do not tell your app. to “stop … from continiously sending data”, no
data are lost.
Slawek
“L. Hao” wrote in message news:xxxxx@ntdev…
> Thanks for the reply. In my case, the user mode app is NT’s
> Dialup-Networking, and I have turned on the Hardware Flow Control at the
> modem’s advanced setting. However, even after all those, I still only
> see 0x4B2 in my driver’s WaitMask set by NT through
> IOCTL_SERIAL_SET_WAIT_MASK, and according to bitmask definitions in
> ntddser.h, CTS is not monitored. That explained why the driver contined
> to receive packets even after it toggled the CTS state by returning
> SERIAL_EV_CTS to its upper layer.
>
> So to better phrase my question, why does the WaitMask not include CTS
> when the Modem’s Hardware Flow Control is turned on? What did I miss?
> Thanks.
>
Slawek:
Thanks for the explaination. It actually confirms my observation in
terms of how NT’s RRAS handles transmitting buffers. I found that it
won’t send down another packet of data to my kernel-mode modem driver
until the driver completes the previous request.
Now on the CTS hardware control flow, I don’t think I quite get what you
mean. I guess my question or confusion is how the CTS/RTS is used if the
two modems are connected through phone lines. If I understand you
correctly, the far receiving end should somehow notify my side to stop
sending by pulling the CTS low. How is it achieved?
Thanks again for taking the time to answering my question.
Lee
Slawek wrote:
>why does the WaitMask not include CTS
>when the Modem’s Hardware Flow Control is turned on?
Why do you think the application should monitor the state of CTS when the
hardware flow control is on? Most likely you reason like this: I tell the
driver to use hardware flow control, and when the CTS goes low the driver
signals that fact to the application so that it knows it should stop
submitting the WriteFile requests to prevent the overflow of the transmit
buffer.
In fact, flow control is about preventing the overflow of the receive buffer
on the other side, not the transmit buffer on your side (I assume you
transmit characters and the other side is receiving). When you set up
hardware flow control you tell the driver to stop transmitting characters
(putting them out on the wire) when the CTS goes low. The application
typically does not need to monitor the state of CTS pin for hardware flow
control purposes, it is done on the driver level (sometimes even in hardware
if your chip supports that).
You may ask how the application knows to stop submitting the WriteFile
requests when the driver can not transmit because CTS is low?
I don’t think the aplication will send your driver a new WriteFile request
until the previous one is completed. It can be completed either after all
characters are transmitted after it times out.
If your driver keeps seeing IRP_MJ_WRITE Irps even though it does not
transmit any characters, it most likely means that the application is seeing
its WriteFile requests timing out and is resubmitting them. So you even if
you do not tell your app. to “stop … from continiously sending data”, no
data are lost.
Slawek
“L. Hao” wrote in message news:xxxxx@ntdev…
>
>>Thanks for the reply. In my case, the user mode app is NT’s
>>Dialup-Networking, and I have turned on the Hardware Flow Control at the
>>modem’s advanced setting. However, even after all those, I still only
>>see 0x4B2 in my driver’s WaitMask set by NT through
>>IOCTL_SERIAL_SET_WAIT_MASK, and according to bitmask definitions in
>>ntddser.h, CTS is not monitored. That explained why the driver contined
>>to receive packets even after it toggled the CTS state by returning
>>SERIAL_EV_CTS to its upper layer.
>>
>>So to better phrase my question, why does the WaitMask not include CTS
>>when the Modem’s Hardware Flow Control is turned on? What did I miss?
>>Thanks.
>>
>
>
>
>
>
>I guess my question or confusion is how the CTS/RTS is used if the
two modems are connected through phone lines
What I wrote about the flow control related to two devices connected with an
RS-232 serial line. Long time ago modems used to be external and connected
to the COM port on the host machine. This is why the applications comunicate
with modems with serial API.
I am guessing that your situation is different in that there is no real COM
port to which your modem is physically connected. Your driver exposes the
telephone line and some telecomunication protocol as a virtual COM port to
applications for backwards compatibility. This is quite common idea, one
can do similar thing for 1394 or USB connections.
In this case how you emulate hardware flow control depends on
telecommunication protocol. Most likely there are no real CTS/RTS signals
there, but maybe some other means to achieve flow control. Your may
“translate” the application request to setup hardware flow control into the
equivalent in the telecommunication protocol. Or, if the protocol does not
have any means of signaling the impending overflow on the receive side (I
doubt that would be the case), you just ignore the requests for flow
control.
Slawek
“L. Hao” wrote in message news:xxxxx@ntdev…
> Slawek:
>
> Thanks for the explaination. It actually confirms my observation in
> terms of how NT’s RRAS handles transmitting buffers. I found that it
> won’t send down another packet of data to my kernel-mode modem driver
> until the driver completes the previous request.
>
> Now on the CTS hardware control flow, I don’t think I quite get what you
> mean. I guess my question or confusion is how the CTS/RTS is used if the
> two modems are connected through phone lines. If I understand you
> correctly, the far receiving end should somehow notify my side to stop
> sending by pulling the CTS low. How is it achieved?
>
> Thanks again for taking the time to answering my question.
>
> RS-232 serial line. Long time ago modems used to be external and connected
to the COM port on the host machine.
Proper modems are still such.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com