holbrook@apollo.HP.COM (Alan R. Holbrook) (03/09/91)
In article <7134@emory.mathcs.emory.edu>, km@mathcs.emory.edu (Ken Mandelberg) writes: |> Is there a way to get at least partial support for CTS/RTS external to |> the program? For example, while I think doing flow control on incoming |> data is inherently a software issue for the DCE (drop RTS if you can't |> buffer any more data), outgoing flow control is more a hardware issue |> for the DCE. The UART on the DCE can told not to transmit (and thus not |> go ready) unless it sees CTS from the DTE. Whoa up a minute, thar, podner... If I remember my basic modem control stuff from years ago when I was working for Racal Milgo, you've got some very basic misconceptions of how data comm works. RTS (Request to Send)is a control signal from either the DTE or DCE to the modem, saying "I have data to transmit." CTS (Clear to Send) is a signal back from the modem saying "I'm ready to send the data for you." What you want to say in the first case... |> data is inherently a software issue for the DCE (drop RTS if you can't |> buffer any more data), outgoing flow control is more a hardware issue ... is really "for the DCE (drop DTR if you can't buffer any more data),..." and in the second case... |> for the DCE. The UART on the DCE can told not to transmit (and thus not |> go ready) unless it sees CTS from the DTE. ... is really "unless it sees CTS from the modem attached to the DTE." Basic modem flow control to transmit data: DTE/DCE raise DTR wait for DSR raise RTS wait for CTS transmit Basic modem flow control to receive data: watch for DCD rcv There are subtleties based on what dux and what protocol, but those are the basics. Alan Holbrook DataComm techie to Noah on the ark...
asfy@vax5.cit.cornell.edu (03/10/91)
In article <503f6ae3.20b6d@apollo.HP.COM>, holbrook@apollo.HP.COM (Alan R. Holbrook) writes: > > In article <7134@emory.mathcs.emory.edu>, km@mathcs.emory.edu (Ken Mandelberg