Device control block (dcb) parameters, Bypassing the normal windows 32 apis, Real time issues – Comtrol Multiport Modems Windows 98 User Manual
Page 50

50
Device Control Block (DCB) Parameters
Device Control Block (DCB) Parameters
•
XonLim, XoffLim - The RocketPort and RocketModem series does not handle
flow control like traditional PC COM ports. Keep in mind the adapters have
large hardware input/output buffers, and any control strategy based on buffer
levels brings the following question: should the trip point be in reference to the
hardware buffer, or the driver software buffer, or both? And if the hardware
performs the flow control, you cannot consider the software buffer in the
equation. You also need to balance this with efficiency.
RTS/CTS flow control is handled by the adapter on a hardware level. The RTS
trip points are hardwired to about 7/8 full and empty in relation to the
hardware input buffer of 1,024 bytes.
DTR/DSR flow control is handled at the software driver level. The DTR trip
point is hardwired at the level at which the software input buffer becomes full
(the hardware input buffer of 1,024 bytes still remains). The low level is
XonLim, and is in relation to the drivers software buffer.
•
fOutX - If set, this cause data transmission to halt upon reception of a XOFF
character and resume when a XON character is received. The XON/XOFF
characters are specified by XoffChar and XonChar parameters and may be
changed by the application. The trip points are hardwired to 7/8 full and
empty in relation to the hardware input buffer of 1,024 bytes.
•
fInX - If set, when the receive buffer is near full, an XOFF character will be
sent out to stop the incoming flow of data. When the receive buffer empties,
the XON character is sent to resume incoming data. The fInX trip point is
hardwired at the level at which the software buffer becomes full (same as DTR
above).
•
fBinary - Leave this bit set on! ASCII mode (this value at zero) enables the EOF
character to be detected. After the EOF character has been detected, no more
data is allowed to be read, and an overflow error is displayed if more data is
received. While Non-Binary mode is supported, it should not be used.
Bypassing the Normal Windows 32
API
s
An application program cannot talk to the port driver directly, and must go
through the normal API calls. In the Windows 98/SE and ME environments it is
possible to write a VCOMM client to bypass the Win32 API layer, but this is not
recommended and is not portable to the Windows NT environment.
Real Time Issues
By default, the driver runs in a polled interrupt fashion; the system is interrupted
every poll period. The poll period default is 10 milliseconds (100 Hz). (In this
instance the Use IRQ option is not selected in the Advanced Board Options
dialog. See
on Page 16 for more information on the Use
IRQ option.)
What this means is that all Event processing is restricted to the poll period
interval. This will only be a problem for some applications that require very
precise synchronization with other hardware. In some cases, this may be worked
around by polling the queue counts through GetCommError().