🚀 go-pugleaf

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. I know that the
>the RS232 'standard' is not really a standard (in the sense of having all 
>details fully specified), but how off-the-wall is use of hardware flow control?

	Hardware flow control is mentioned in the RS-232 standard.  However, 
	the methods most often used in the real world 'violate' the standard
	in some manner or another.

	RTS-CTS handshaking is used in the standard for half-duplex communica-
	tion (that is, only one side or the other 'talks' at a time).  If your
	application will run in half-duplex mode, no 'violation' of the stand-
	ard will occur.

	The most ideal option for implementing full-duplex hardware handshak-
	ing, IMO, is to use CTS and SCTS (Secondary Clear to Send - don't re-
	call off the top of my head which pin SCTS is assigned to - pin 19?).
	However, it is quite common for peripheral manufacturers to use DTR
	to indicate whether the peripheral is ready to receive data or not.  In
	such cases, I wire DTR of the peripheral to CTS of the computer.  The
	use of DTR in this manner 'violates' the standard.

	(Throughout this reply, I have put 'violates' in quotes, because RS-232
	is a *Recommended Standard* only.  Embodied within the standard itself
	is the possibility for _all_ signal lines to be redefined by a vendor.
	RS-232 really only deals with the electrical interface and suggested
	pin assignments and usages.)

>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
>(LapLink and Commute come to mind as examples) use hardware flow control?
>Do any packages use xon/xoff to do this?

	I have no explicit knowledge, but I can make a guess: at such a high
	rate of data-transfer, hardware handshaking is preferred due to the
	low latency time (that is, the hardware responds _immediately_ to a
	'not clear to send' condition while in the software side, the XON/XOFF
	must be received, removed from the UART, processed, and the correspon-
	ding action taken).

>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? Another statement was made that QuickBASIC has no provision for using
>hardware flow control. I don't use BASIC; is this true?

	Unknown.

>Thanks for any facts you can give me.

	I hope this helps.


We read the world wrong		| Phil Buckland
and say that it deceives us.	| psb@eece.ksu.edu
Tagore, from Stray Birds	| psb@matt.ksu.ksu.edu