Byte OS/2 Programmer's Cookbook/OS2TOOLS.ISO/ibminfo/16550.doc

Text File | 1992-09-11 | 18KB | 341 lines

Area Os2, Msg#1586, Sep-09-92 09:52PM
   From: Wilson Navarro
     To: All
Subject: 16550 under os2

I found this message on internet. I hope it helps someone understand com
ports under OS/2. ------------------------------------------------------------
------------ Article 11617 (102 more) in comp.os.os2.misc: From: [e-mail]
(David Bolen)

Subject: COM performance hints with 16550 Date: Thu, 3 Sep 1992 20:18:53 GMT
Organization: Advanced Network & Services, Inc. - Elmsford, NY Lines: 325

Warning: This is pretty long, but there's a summary at the end.  If you just
         want to see a brief statement now:

     If you have a 16550, have a serial device that keeps DSR high while
     it is on (I think most modems do this by default, or are configurable),
     doesn't do hardware flow control, or doesn't mind getting up to 15
     characters after dropping CTS and/or DSR, make sure you set BUFFER=ON
     when configuring your COM port with the MODE command.  With default
     settings, BUFFER=AUTO is really no different than BUFFER=DISABLED.

         - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

I recently obtained a copy of the OS/2 physical device driver reference and
was reading through the information about the async drivers (COM/VCOM.SYS).

From the number of posts on the subject (some from myself), it seems that a
number of people are confused about what the various MODE COM settings mean,
and what sort of setup was the most efficient use of COM ports when a 16550
UART was present (which seems to be universally regarded as a good idea to
have in order to gain good performance).  I normally use OS/2 COM programs
with the RTS=HS,BUFFER=AUTO settings (as is normally recommended on the net
and in the FAQ) and wondered if I was fully exploiting the capabilities of my
16550.  In addition, I was still having problems with DOS environment
programs (notably kermit 3.11 that just dies a horrible death) and hoped to
learn a bit about how that might be improved.

After reading a bit, and performing some experimentation, I've come up with
the following information and conclusions that may help other people with the
16550s.  I don't place any guarantees on this information, other than that it
is accurate to the best of my knowledge and seems to be backed up by my
experimental results.  I hope it proves helpful, or at least helps to explain
the relationship between some of the MODE parameters and the use of the FIFO
buffers provided by the 16550.

(in the following, when I use the term 16550, the OS/2 drivers actually
 require an NS-16550A or compatible chip, and I believe the current level
 chips as discussed previously in the OS/2 groups are 16550AFN or 16550AF)

         - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Introduction:
------------

The 16550 provides for a 16-character receive hardware buffer that can be set
to generate an interrupt every 1, 4, 8 or 14 characters.  It can also hold up
to 16 characters in a transmit buffer, generating an interrupt only when that
buffer is empty.  In other words, in its most efficient mode, the 16550 can
handle transmission and receipt of data in roughly 16-byte chunks, only
interrupting the CPU at the end of each chunk.

Note that even if you don't make use of the extended buffering from the point
of view of interrupt handling, but still receive an interrupt for every
character received or transmitted, the 16550 buffer can be helpful, as it can
buffer received characters if the COM handler misses an interrupt, thereby
preventing receive overruns.

The OS/2 COM driver can fully exploit these capabilities of the 16550
depending on how it is configured.  Here's the rub though - if you take the
default COM settings, and even if you use MODE to set the BUFFER parameter to
AUTO, the COM driver is only partially using the capabilities of the UART. In
other words, the settings that are normally posted to these groups, and are
in the FAQ are not the most efficient settings.  In fact, from what I can
tell, a BUFFER value of AUTO is no better than DISABLED with the other
defaults for the modem signaling values.


COM Driver Settings (MODE):
--------------------------

The extended hardware buffering mode of the async driver can be controlled
via the BUFFER parameter of the MODE command.  It can take on three values:

     ON         Set transmit/receive triggers to fully exploit buffering.
                (16-character transmit/receive queues for 16550).
     OFF        Set transmit/receive triggers to a single character.
     AUTO       "Automatic Protocol Override".  Adjust the transmit/receive
                triggers according to handshaking protocols in effect.

The "handshaking protocols" for AUTO mode use the following signals:

        RTS = Request To Send           ( Signals FROM OS/2 COM Driver )
        DTR = Data Terminal Ready
        CTS = Clear To Send             ( Signals TO OS/2 COM Driver )
        DCD = Data Carrier Detect
        DSR = Data Set Ready

and refer to the following:

   * Input Sensitivity using DSR
        - MODE option IDSR, default ON
        - If this setting is ON, then the driver will only accept data from
          the device while the DSR line is active.
   * Output Handshaking using CTS, DSR, DCD
        - MODE options OCTS, ODSR, default is both ON
        - No MODE option for DCD - MODE always sets it OFF
        - This setting controls whether CTS, DSR or DCD are used to control
          the flow of data to the modem.  If any of these settings are ON,
          the driver stops giving data to the transmit hardware as soon as
          the corresponding control signal drops.
   * RTS Control Mode
        - MODE option RTS, default is ON.  Can be one of the following:
            + Enabled                                              [MODE=ON]
            + Disabled                                             [MODE=OFF]
            + Input Handshaking (RTS drops on input queue full)    [MODE=HS]
            + Toggling on Transmit (RTS drops unless transmitting) [MODE=TOG]
        - This setting controls how the RTS signal is controlled by the
          driver.  If ON, DTR is used to signal when the COM port is
          active, while if HS, DTR is used to control the flow of data
          from the modem.
   * DTR Control Mode
        - MODE option DTR, default is ON.  Can be one of the following:
            + Enabled                                              [MODE=ON]
            + Disabled                                             [MODE=OFF]
            + Input Handshaking (DTR drops on input queue full)    [MODE=HS]
        - This setting controls how the DTR signal is used to control
          the flow of data.
        - This setting controls how the RTS signal is controlled by the
          driver.  If ON, DTR is used to signal when the COM port is
          active, while if HS, DTR is used to control the flow of data
          from the modem.

A typical default configuration for the COM port is (ignoring some of the
MODE parameters not relevant to this post):

        IDSR = ON               ODSR   = ON
        OCTS = ON               DTR    = ON
        RTS  = ON               BUFFER = AUTO

And most suggestions for configuring the COM port for better control
explicitly set RTS=HS, and BUFFER=AUTO, so I expect that many people are
running with the above settings, except with RTS=HS, allowing full hardware
flow control (RTS/CTS) to the modem.


Setting Interaction:
-------------------

For the purposes of this post (getting the most performance out of the
16550), the only settings that are really important from the above discussion
are the "Extended Hardware Buffering" (BUFFER), "Input Sensitivity using DSR"
(IDSR), and "Output Handshaking using CTS, DSR, DCD" (OCTS,ODSR).

Here's the basic problem.  In order to accomplish the latter two settings in
their default mo