tty-to-tty testing

DanKarron at UCBVAX.BERKELEY.EDU DanKarron at UCBVAX.BERKELEY.EDU
Fri Apr 26 16:07:37 AEST 1991


I like your idea of testing serial ports!

There are two limitations to using kermit for hardware handshaking.

They are not serious, and I will fix it when I get more at home in the
kermit source. In the mean time, as long as you are aware of it, it is
something I can live with.

There are two signals that the peripheral can send back to the host via
hardware handshaking on a ttyf{nn} port. They are RTS and DCD. Kermit correctly
recognizes a loss of DCD (carrier). When you do the 'set line ttynn', it will
try to open the port. If DCD is not held up, you will get a message
that it can't open the port. If DCD is dropped during a session, you will
get a 'communications disconnect' message, and get punted out.

Once DCD is dropped, you can not reconnect. I have to restart kermit, as 
not all of the flags are reset when you close the connection and try to remake
it. Kermit should not try to open the port so fast, i.e., when you set
the line. It should only do it when you attempt connect, and then when you 
disconnect, it should reset its state to that previous to your connect.     

RTS-CTS modulates character by character flow (or should) and you can
open a port with no CTS, but you can't get any characters through. Kermit
should make some diagnostic message, but it just hangs till CTS is 
asserted. If you loose CTS, it halts, and you have to kill kermit with a 
control backslash c or kill from another window. Some informative 
diagnostic would be appropriate here. 

As long as you are familier with these properties, you can tell exactly
what pins are doing what from kermit's behavior.

Hardware handshaking is much faster and generally more reliable than xon
and xoff. Many peripheral's xon/xoff is too slow at 38400 to be reliable.       

I hope that this helps, and if anyone has mods to kermit with regard to the
above properties, I would like to see them.

>From: "Ronald D. Anderson" (IBD) <andy at BRL.MIL>
>To: info-iris at BRL.MIL
>Subject:  tty-to-tty testing
>Message-Id:  <9104250933.aa26475 at IBD.BRL.MIL>
>
>|> From: Henrik Klagges <math.fu-berlin.de!opal!fauern!NewsServ!sunmanager!uh311ae at uunet.uu.net>
>|> Organization: Technische Universitaet Muenchen, Germany
>|> 
>|> Hello !
>|> I just wonder why there is a need for hardware handshakers (ttyf's).
>|> I have no problem running the standard 4DGifts kermit at 19200. I 
>|> couldn`t try 38k because I don't have a 2nd 38k thing.
>|>  BTW, if I want to make SGI-SGI serial line transfer, would I have to
>|> switch wires in the serial line ? Recently, I had some nice "Panic:....
>|> 
>
>for testing kermit baud rates and ttyf's, try defining two of the sgi serial
>i/o ports as having the same rates and characterisitcs (ttyf, etc.).
>then (a) cable together with null-modem signal swapping (rx-to-tx, tx-to-rx,
>etc.); (b) start kermit on the first tty and set it up to receive;
>(c) start kermit again from a second window on the other tty, where you can
>now send files to the first tty.  this scheme can be set up between two
>distinct machines, or can be done over two tty's on the same machine.
>(the second option is OK for testing the hardware and software links, but
>has little other usefulness.)
>
>a note:  don't try sending/receiving from two windows that reside in the
>same subdirectory, unless you are sure to put the (sent) file under a
>different filename.
>
>this is also a convenient way to test the uucp setup on a single local
>machine before connecting to a remote system.
>

Cheers!

dan.
| karron at nyu.edu (e-mail alias )         Dan Karron, Research Associate      |
| Phone: 212 263 5210 Fax: 212 263 7190  New York University Medical Center  |
| 560 First Avenue                       Digital Pager <1> (212) 397 9330    |
| New York, New York 10016               <2> 10896   <3> <your-number-here>  |



More information about the Comp.sys.sgi mailing list