guardian@laidbak.UUCP (Harry Skelton) (08/17/87)
In article <2849@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: >In article <192@caeco.UUCP> murf@caeco.UUCP (Steve Murphy) writes: >> The Sun 3/160 (and all the sun 2's and the 3/110's also) cannot hardware >> handshake AT ALL. [...] Now, if I worked for Sun, I'd blush, because this is > > Arghhhhh! Maybe the reason Sun's RS-232 ports don't do RTS/CTS >handshaking is because if they did, it wouldn't be RS-232. As defined in the >standard, RS-232 has no flow-control. Granted, hardware flow contol is nice, >and you might reasonably argue that the lack of such flow control is a major >mis-feature of RS-232, but the thing to do is to define a new standard which I don't suppose that anyone though how a PC/AT controls communications? I think that the term here is simply 'protocol' since many other versions 'handshaking' occur on a RS-232. I must agree, having something hardware control data flow does have problems and would provide a real bugger to find any problems with short of a breakout box or scope. Harry Skelton guardian@laidbak.UUCP
daveb@geac.UUCP (Brown) (08/18/87)
In article <2849@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: >In article <192@caeco.UUCP> murf@caeco.UUCP (Steve Murphy) writes: >> The Sun 3/160 (and all the sun 2's and the 3/110's also) cannot hardware >> handshake AT ALL. [...] Now, if I worked for Sun, I'd blush, because this is > > Arghhhhh! Maybe the reason Sun's RS-232 ports don't do RTS/CTS >handshaking is because if they did, it wouldn't be RS-232. As defined in the >standard, RS-232 has no flow-control. Well, I remember programming half-duplex modems, and they did handshake bidirectionally using CTS/RTS. I won't say that they did it *elegantly*, but they did do the following. Talk, talk, talk... <------------ *CTS I'd like to talk. RTS ------------> <------------ CTS Ok, you talk. *RTS ------------> Huh? Oh, flow control... <------------ *CTS Talk, talk, talk... Talk, talk, talk... <------------ *CTS I'd like to talk. Ok, you talk *RTS ------------> Huh? Flow control! <------------ CTS [this isn't kosher] RTS ------------> Talk, talk, talk... Note that asserting CTS without RTS is not part of the standard, and so is subject to misinterpretation and non-implementation. And its forgotten later, so we have to re-invent it... I *DO NOT* know the meaning later (4XX) standards applied to these lines. dave (I HATE reinventing wheels) collier-brown -- David Collier-Brown. | Computer Science Geac Computers International Inc., | loses its memory 350 Steelcase Road,Markham, Ontario, | (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.
jc@piaget.UUCP (John Cornelius) (08/21/87)
In article <1172@geac.UUCP> daveb@geac.UUCP (Dave Collier-Brown) writes: >In article <2849@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: >>In article <192@caeco.UUCP> murf@caeco.UUCP (Steve Murphy) writes: >>> The Sun 3/160 (and all the sun 2's and the 3/110's also) cannot hardware >>> handshake AT ALL. [...] Now, if I worked for Sun, I'd blush, because this is >> >> Arghhhhh! Maybe the reason Sun's RS-232 ports don't do RTS/CTS >>handshaking is because if they did, it wouldn't be RS-232. As defined in the >>standard, RS-232 has no flow-control. > >Well, I remember programming half-duplex modems, and they did handshake The Systek MTI-16 which is used on the Sun-3/160 does indeed observe rts/cts flow control and it says so in the manual. I have recently connected a plotter to one port of ours and it works marvelously. Perhaps you should check your cables. -- John Cornelius (...!sdcsvax!piaget!jc)
rick@pcrat.UUCP (08/22/87)
In article <419@piaget.UUCP>, jc@piaget.UUCP (John Cornelius) writes: > >In article <2849@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: > >> > >> Arghhhhh! Maybe the reason Sun's RS-232 ports don't do RTS/CTS > >>handshaking is because if they did, it wouldn't be RS-232. As defined in > >>the standard, RS-232 has no flow-control. True enough, the original use of RTS/CTS is for modem turnaround in a half-duplex environment. However, this also gives you one direction flow control (The 'DCE' side can stop the 'DTE' side from transmitting by deasserting CTS). > The Systek MTI-16 which is used on the Sun-3/160 does indeed > observe rts/cts flow control and it says so in the manual. I > have recently connected a plotter to one port of ours and it > works marvelously. Plotters, usually, only need one direction flow control. However, what I think we were originally discussing is the defacto standard of using RTS/CTS in a *full duplex* environment to provide *two way* flow control. In this scheme, CTS is still used by the DCE to flow control the DTE. However, there is no relationship between RTS and CTS anymore. Instead, RTS is given a new meaning. When the DTE wants to flow control the DCE, it deasserts RTS. Think of RTS as "Receiver Ready" and it makes good sense. I don't know how many vendors implement this in their products, but I know that AT&T does in some of its product line. -- Rick Richardson, President, PC Research, Inc. (201) 542-3734 (voice, nights) OR (201) 834-1378 (voice, days) seismo!uunet!pcrat!rick
robert@pvab.UUCP (Robert Claeson) (08/24/87)
In article <374@pcrat.UUCP> rick@pcrat.UUCP (rick) writes: ..... >However, what I think we were originally discussing is the defacto standard >of using RTS/CTS in a *full duplex* environment to provide *two way* flow >control. In this scheme, CTS is still used by the DCE to flow control >the DTE. However, there is no relationship between RTS and CTS anymore. >Instead, RTS is given a new meaning. When the DTE wants to flow control >the DCE, it deasserts RTS. Think of RTS as "Receiver Ready" and it >makes good sense. I don't know how many vendors implement this in >their products, but I know that AT&T does in some of its product line. ..... Aren't there pins named "Secondary DCD, CTS, RTS" and some others at pin 12, 13, and 19? Can't they be used to provide a "real" two-way flow control without violating the RS232 standard? I can't find any documentation on the RS422/RS423 standards. Doesn't one of those standards provide full-duplex handshaking? -- SNAIL: Robert Claeson, PVAB, P.O. Box 4040, S-171 04 Solna, Sweden UUCP: {seismo,mcvax,munnari}!enea!pvab!robert ARPA: enea!pvab!robert@seismo.arpa
guy%gorodish@Sun.COM (Guy Harris) (08/25/87)
> A. The Sun 3/160 (and all the sun 2's and the 3/110's also) cannot > hardware handshake AT ALL. They say they do, but in one > direction only, usually so the external device can shut up > the CPU, but not vice-versa. OK, so what is the proper protocol by which the CPU can control the flow of data from the external device? RTS/CTS handshaking permits a DCE to control the flow of data from a DTE; how does the DTE control the flow of data from the DCE? Now maybe some boxes listend to RTS and stop sending data when it drops. IF this is a commonly-adhered-to (if non-RS-232-compliant) protocol, it might get implemented in a future release; however, you'll definitely have to TURN IT ON because it's rather non-standard, to say the least. > And, as far as I know, this is available as a special kernel fix > (zs_asynch.o) for some $$$. But, you have to TURN IT ON. A future release may provide the ability to enable RTS/CTS handshaking on individual ports with an "ioctl", but if it's implemented you're still going to have to TURN IT ON. That's because some hardware and/or cabling doesn't hold CTS high; you shouldn't be forced to jumper RTS and CTS (see below). (Turning it on also requires you to provide DCD; see below.) > Even more Ludicrous: Sun OEM's MTI 8/16 port asynch port cards > --which have hardware handshake capability; SUN DISABLES THIS > FEATURE IN IT'S DRIVER. Sun is very philosophical about this. I don't know who from Sun was "very philosophical about this", but they were also very WRONG about this. You *CAN'T* disable RTS/CTS handshaking on the Systech board from software. PERIOD. The bloody Signetics 2661 *chip* on the board doesn't let you turn it off, and there's no extra hardware on the Systech board to fake CTS. We have several cables here at Sun with RTS and CTS jumpered, attesting to that fact and yes, it's a pain; when I wanted to do some testing on a Systech board, I had to dig up such a cable. Oh yes, one more thing. Both the Zilog 8530 SCC chip on the Sun CPU serial ports, and the Signetics 2661 on the Systech board, will, when doing RTS/CTS flow control, *also* shut the receiver *off* when DCD is dropped! You can shut this off on the SCC, by turning off the bit that enables both RTS/CTS outgoing flow control and DCD/receiver-enable switching; however, you can't control them independently. This is another reason not to forcibly turn RTS/CTS flow control on. You're STUCK with this behavior on the 2661; this is handled by forcing DCD high and wiring the DCD line on a cable to the DSR pin, and using DSR as a "fake" carrier. This requires the driver to know about this; perhaps this is what the alleged disabling of RTS/CTS handshaking in the software reall refers to? Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
jhc@mtune.ATT.COM (Jonathan Clark) (08/25/87)
In article <305@pvab.UUCP> robert@pvab.UUCP (Robert Claeson) writes: >Aren't there pins named "Secondary DCD, CTS, RTS" and some others at pin >12, 13, and 19? Can't they be used to provide a "real" two-way flow control >without violating the RS232 standard? No. One of the (demonstrably) little-known facts about the full RS-232 interface is that there are *two* independant data channels in there, called Primary and Secondary (would you believe). The Secondary channel has a full set of control pins (those which don't refer to the physical state of the modem, logically enough [sic]). Actually there is or was at least one modem which implemented a tertiary channel! Anyway, the whole point of this is that while RTS/CTS full-duplex flow control does violate the letter of the RS-232 standard, it is a de facto standard because it is too useful to give up. Personally I'll take any sort of out-of-band flow control, I almost don't care what it is. -- Jonathan Clark [NAC,attmail]!mtune!jhc An Englishman never enjoys himself except for some noble purpose.
rick@pcrat.UUCP (rick) (08/26/87)
In article <26425@sun.uucp>, guy%gorodish@Sun.COM (Guy Harris) writes: > RTS/CTS handshaking permits a DCE to control >the flow of data from a DTE; how does the DTE control the flow of data from the >DCE? See my previous postings on this. In a nutshell, RTS is renamed "Receiver Ready". > Now maybe some boxes listend to RTS and stop sending data when it drops. IF > this is a commonly-adhered-to (if non-RS-232-compliant) protocol, it might get > implemented in a future release; however, you'll definitely have to TURN IT ON > because it's rather non-standard, to say the least. Yeah, you got it. It's non-standard, but its elegant. > Oh yes, one more thing. Both the Zilog 8530 SCC chip on the Sun CPU serial > ports, and the Signetics 2661 on the Systech board, will, when doing RTS/CTS >flow control, *also* shut the receiver *off* when DCD is dropped! You can shut > this off on the SCC, by turning off the bit that enables both RTS/CTS outgoing >flow control and DCD/receiver-enable switching; however, you can't control them > independently. This is another reason not to forcibly turn RTS/CTS flow > control on. You'll either have to do RTS/CTS in software, or trade up to a newer model UART. May I suggest AT&T's 'ARTI', which has three modes of RTS/CTS operation (including the non-standard full-duplex EIA flow control), and autobaud (speed matching) as an extra bonus? -- Rick Richardson, President, PC Research, Inc. (201) 542-3734 (voice, nights) OR (201) 834-1378 (voice, days) seismo!uunet!pcrat!rick