🚀 go-pugleaf

In article <1992Aug7.200957.125@tvnews.tv.tek.com> dougs@tvnews.tv.tek.com
(Doug Stevens) writes:
>-------
>We're having a disagreement about how 'standard' use of hardware flow
>control (that is, RTS-CTS signalling) is for serial communications.

there are 2 major varieties, so you may well both (all?) be right.  the
first type is what you generally hear about when talking about RS-232,
which is the simple case where RTS (Request To Send) is raised when the
DTE (i.e., the computer/terminal) wants to send data to the DCE (i.e.,
modem, etc).  the DCE then raises CTS (Clear To Send) when it is prepared
to receive the data.

very simple, but with one major problem:  how does the computer tell the
modem when *IT* isn't ready to receive data?  thus, the more recent (and
greatly superior) bi-directional hardware flow control.

in this mode, RTS and CTS are independent of each other.  RTS high means
that the DTE is ready to receive data (in this mode, its real name is
RFR, Ready For Receiving, but that isn't used much since nobody would know
what you're talking about).  CTS high means that the DCE is ready to
receive data, except that here, again, it is independent of RTS.

>We need to be able to operate to 115 Kbaud and transfer binary data. Does
>anyone know whether packages that operate at this speed and do binary
>transfer [...] use hardware flow control?

if not, I'd be very concerned about what other mistakes their authors
might have made....  in fact, I'd expect the above bi-directional hardware
flow to be used exclusively, especially at those speeds, where it's pretty
much no longer optional.  this is true once you exceed 19.2 to 38.4,
depending on the computer, the serial port hardware (16550 vs other), etc.

>Do any packages use xon/xoff to do this?

not if they're worth 10 cents.  in addition to the obvious problem of
eliminating data transparency, software flow control may not be able to
keep up at higher speeds, and you could see dropped bits.

in general, software flow control should only be used as an ABSOLUTE last
resort if and only if nothing else is available.

>The statement has been made that many communication packages commonly
>used on the PC have no provision for dealing with hardware flow control.
>How true is this?

I've never seen *ANY* communications package for the PC that doesn't
provide support for both of the above types of hardware flow control.
whoever told you this must be looking at the absolute most pitiful
examples of 300 year old public domain stuff (not to be confused with
the top-notch PD and shareware comm software that also exists).

if the people you're talking to paid for comm software that doesn't provide
these, tell them to ask for their money back.

>Another statement was made that QuickBASIC has no provision for using
>hardware flow control. I don't use BASIC; is this true?

I don't use BASIC either, but I can't see this as being true.  after all,
you could always use either inline assembly or direct access to the
hardware from within basic, right?  again, I don't use basic --- I use C.
but I've been told by a few people who swear by basic that anything I can
do in C they can do in basic faster, cleaner, and with less code....so if
that's true (big if, IMHO), you can do it.  :-)

if you have further questions on this, please feel free to e-mail me.
   --jim

\input std_disclaimer                     % 73 DE N5IAL (/9)
------------------------------------------------------------------------------
"[...] the plural of `mongoose' ought to be `polygoose'." [Jargon file 2.9.10]

INTERNET:  jim@n5ial.chi.il.us  |  grahj@gagme.chi.il.us  |  j.graham@ieee.org
UUCP:  gagme!n5ial!jim@clout.chi.il.us
AMATEUR RADIO:  n5ial@n9hsi (Chicago.IL.US.Earth)
------------------------------------------------------------------------------