gandrews@netcom.COM (Greg Andrews) (04/06/91)
In article <TMPP9FB@geminix.in-berlin.de> gemini@geminix.in-berlin.de (Uwe Doering) writes: > >This is a common misunderstanding of how RTSFLOW works under SCO UNIX (and >Xenix as well). SCO implemented a half duplex type of hardware flow >control, as it is described in the original RS232C standard. That is, >RTS signals the modem whether there are any characters in the _computer's_ >output buffer. If there are none, RTS is low, otherwise it's high. This >won't work at all if the modem is configured to use full duplex hardware >flow control. In this mode RTS signals the modem that the computer is >ready to receive characters. As far as I know, there is no way to get this >working with the original SCO sio driver, as it isn't designed for that >type of handshake. > Then why does RTS stay high all the time at slower speeds? If it behaved consistently, then the modem could simply be configured to use half duplex flow control (S58=1 S68=255) and be done with it. Unfortunately, in my version of SCO Unix (3.2.0 according to the kernel), RTS stays on all the time when getty is using the B9600 or slower entries in /etc/gettydefs. That violates the rules for half duplex RTS/CTS. RTS should be low while the computer is not transmitting. -- .------------------------------------------------------------------------. | Greg Andrews | UUCP: {apple,amdahl,claris}!netcom!gandrews | | | Internet: gandrews@netcom.COM | `------------------------------------------------------------------------'
gemini@geminix.in-berlin.de (Uwe Doering) (04/06/91)
gandrews@netcom.COM (Greg Andrews) writes: >In article <TMPP9FB@geminix.in-berlin.de> gemini@geminix.in-berlin.de (Uwe Doering) writes: >> >>This is a common misunderstanding of how RTSFLOW works under SCO UNIX (and >>Xenix as well). SCO implemented a half duplex type of hardware flow >>control, as it is described in the original RS232C standard. That is, >>RTS signals the modem whether there are any characters in the _computer's_ >>output buffer. If there are none, RTS is low, otherwise it's high. This >>won't work at all if the modem is configured to use full duplex hardware >>flow control. In this mode RTS signals the modem that the computer is >>ready to receive characters. As far as I know, there is no way to get this >>working with the original SCO sio driver, as it isn't designed for that >>type of handshake. >> > >Then why does RTS stay high all the time at slower speeds? If it behaved >consistently, then the modem could simply be configured to use half duplex >flow control (S58=1 S68=255) and be done with it. Yes, but half duplex flow control, per definition, is only for one direction (computer -> modem). This won't help you with receiving data. >Unfortunately, in my version of SCO Unix (3.2.0 according to the kernel), >RTS stays on all the time when getty is using the B9600 or slower entries >in /etc/gettydefs. That violates the rules for half duplex RTS/CTS. RTS >should be low while the computer is not transmitting. One detail I remember now is that the RTS/CTSFLOW flags have a meaning only if CLOCAL is cleared. That is, as far as I know, you can't use these flags on a dialout line (tty1a, tty1b etc.) because it has CLOCAL always set. And therefore RTS is always high. But I may be wrong here. And maybe there are other strange interactions between flags in the sio driver. I don't know. Uwe -- Uwe Doering | INET : gemini@geminix.in-berlin.de Berlin |---------------------------------------------------------------- Germany | UUCP : ...!unido!fub!geminix.in-berlin.de!gemini
gandrews@netcom.COM (Greg Andrews) (04/07/91)
In article <LVQPHKW@geminix.in-berlin.de> gemini@geminix.in-berlin.de (Uwe Doering) writes: >gandrews@netcom.COM (Greg Andrews) writes: > >>Then why does RTS stay high all the time at slower speeds? If it behaved >>consistently, then the modem could simply be configured to use half duplex >>flow control (S58=1 S68=255) and be done with it. > >Yes, but half duplex flow control, per definition, is only for one >direction (computer -> modem). This won't help you with receiving >data. > I'm afraid that's not the case. Half duplex data flow is defined as data flow in one direction at a time. Half duplex RTS/CTS signals when the computer is ready to receive, and when it is ready to transmit. By definition, when the computer is ready to transmit, it is not ready to receive. When RTS is asserted, the computer is signalling a 'ready to transmit' state, which means 'NOT ready to receive'. It does control the modem ---> computer data flow. Data is sent to the computer only when RTS is off. > >>Unfortunately, in my version of SCO Unix (3.2.0 according to the kernel), >>RTS stays on all the time when getty is using the B9600 or slower entries >>in /etc/gettydefs. That violates the rules for half duplex RTS/CTS. RTS >>should be low while the computer is not transmitting. > >One detail I remember now is that the RTS/CTSFLOW flags have a meaning >only if CLOCAL is cleared. That is, as far as I know, you can't use >these flags on a dialout line (tty1a, tty1b etc.) because it has CLOCAL >always set. And therefore RTS is always high. But I may be wrong here. >And maybe there are other strange interactions between flags in the sio >driver. I don't know. > That may be true for dialout, but the inconsistent behavior of RTSFLOW I reported was observed on dial-in, where CLOCAL is not set. -- .------------------------------------------------------------------------. | Greg Andrews | UUCP: {apple,amdahl,claris}!netcom!gandrews | | | Internet: gandrews@netcom.COM | `------------------------------------------------------------------------'
gemini@geminix.in-berlin.de (Uwe Doering) (04/07/91)
gandrews@netcom.COM (Greg Andrews) writes: >In article <LVQPHKW@geminix.in-berlin.de> gemini@geminix.in-berlin.de (Uwe Doering) writes: >>gandrews@netcom.COM (Greg Andrews) writes: >> >>>Then why does RTS stay high all the time at slower speeds? If it behaved >>>consistently, then the modem could simply be configured to use half duplex >>>flow control (S58=1 S68=255) and be done with it. >> >>Yes, but half duplex flow control, per definition, is only for one >>direction (computer -> modem). This won't help you with receiving >>data. >> > >I'm afraid that's not the case. Half duplex data flow is defined as >data flow in one direction at a time. Half duplex RTS/CTS signals when >the computer is ready to receive, and when it is ready to transmit. >By definition, when the computer is ready to transmit, it is not ready >to receive. When RTS is asserted, the computer is signalling a 'ready >to transmit' state, which means 'NOT ready to receive'. It does control >the modem ---> computer data flow. Data is sent to the computer only >when RTS is off. I don't agree. The term `half duplex' applies to the link between the two DCEs, that is, the modems. The link between the modem and the computer is, of course, full duplex, as there are individual data lines in the cable for receiving and transmitting. RTS signals the modem that the computer _likes_ to send some data. The _modem_ then decides when the actual direction switch on the DCE <-> DCE link will occure. If the switch is completed the modem signals the computer via CTS that it may send data. But this in no way implies that the modem has to stop the data transfer to the computer immediately when the computer raises RTS. It is the modem's decision when the transmission direction is switched. The computer can only request the modem to switch direction, but it can't force it to do so. Therefore, RTS has no direct (and immediate) influence on the receiver data flow, and can't be used to throttle it immediately in order to prevent a receiver buffer overflow. >>One detail I remember now is that the RTS/CTSFLOW flags have a meaning >>only if CLOCAL is cleared. That is, as far as I know, you can't use >>these flags on a dialout line (tty1a, tty1b etc.) because it has CLOCAL >>always set. And therefore RTS is always high. But I may be wrong here. >>And maybe there are other strange interactions between flags in the sio >>driver. I don't know. >> > >That may be true for dialout, but the inconsistent behavior of RTSFLOW >I reported was observed on dial-in, where CLOCAL is not set. Well, as I said, I don't know what other "features" SCO has built into their sio driver. But even if we discuss this issue for three more weeks, you still won't be able to convince sio to do full duplex RTS/CTS flow control, as it isn't designed to do that. That's a fact. Uwe -- Uwe Doering | INET : gemini@geminix.in-berlin.de Berlin |---------------------------------------------------------------- Germany | UUCP : ...!unido!fub!geminix.in-berlin.de!gemini
gandrews@netcom.COM (Greg Andrews) (04/09/91)
In article <XYRPT1D@geminix.in-berlin.de> gemini@geminix.in-berlin.de (Uwe Doering) writes: >gandrews@netcom.COM (Greg Andrews) writes: > >>I'm afraid that's not the case. Half duplex data flow is defined as >>data flow in one direction at a time. >> > >I don't agree. The term `half duplex' applies to the link between the >two DCEs, that is, the modems. The link between the modem and the >computer is, of course, full duplex, as there are individual data lines >in the cable for receiving and transmitting. > Guess we'll just have to agree to disagree on this one, Uwe. As I said earlier, I consider the term "half duplex" to describe the way data flows through the channel. Not the way data COULD flow, but the way data DOES flow. The interaction through the RS232 cable would also be half duplex since that's how the data flows. I don't have an authoritative reference (EIA or V.24) to check, so I'll have to leave it at that. -- .------------------------------------------------------------------------. | Greg Andrews | UUCP: {apple,amdahl,claris}!netcom!gandrews | | | Internet: gandrews@netcom.COM | `------------------------------------------------------------------------'