stuart@rochester.UUCP (03/11/87)
In article <453@ll-xn.ARPA>, singer@ll-xn.ARPA (Matthew R. Singer) writes: > > Does any know of any bugs in the TOS rs232 handler regarding the > usage of CTS/RTS flow control? ... when CTS/RTS is enable via the > RSCONF call, the system appears to hang as soon as io to the AUX > device begins. This problem also appears with the Avatex modem and most printers you might try to drive over the RS-232C port. It is due to an ST hardware limitation. The chips that handle the RS-232C interfaces treat these signals as EDGE-TRIGGERED. The Avatex (and obviously the US Robotics) modem asserts CTS as a CONTINUOUS signal until its buffering fills up (because the ST is sending characters faster than the modem can ship them over the phone line). It does not flicker or toggle CTS for every character. This is a legitimate RS-232C behavior, I believe. The reason for the lock-up behavior is that the ST hardware will only generate an interrupt for the software to handle for the FIRST character in outgoing buffer-full. The modem will continue to wait for the next character, with CTS asserted, and the ST will continue to wait for an interrupt to ship out the next character, because its interface hardware is waiting for a TRANSITION on the CTS signal, not a logic level. I think this might be fixable even without a hardware change, but would require more messing around with the device registers and interrupt handlers than I care to deal with. I avoid the problem by running at 1200 baud, which never overruns the capabilities of my modem's buffering or line quality, and simply don't use RTS/CTS flow control. Stu Friedberg {seismo, allegra}!rochester!stuart stuart@cs.rochester.edu
wheels@mks.UUCP (03/13/87)
In article <25784@rochester.ARPA>, stuart@rochester.ARPA (Stuart Friedberg) writes: > The chips that handle the RS-232C interfaces treat these > signals as EDGE-TRIGGERED. I remember reading that, I think in the Abacus book, but then I also heard that was only in the early versions and had been changed for TOS in ROM. > The Avatex (and obviously the US Robotics) > modem asserts CTS as a CONTINUOUS signal until its buffering fills up > (because the ST is sending characters faster than the modem can ship > them over the phone line). Now just a second. As far as I know, none of these modems has buffering. If the ST is sending at 1200 bps, and the modem is sending to the phone line at 1200 bps, why should there be? Ditto for 2400 bps. > It does not flicker or toggle CTS for every > character. This is a legitimate RS-232C behavior, I believe. It is the only legitimate RS-232C behaviour. -- Gerry Wheeler {seismo,decvax,ihnp4}!watmath!mks!wheels Mortice Kern Systems Inc.
stuart@rochester.UUCP (03/15/87)
In article <228@mks.UUCP>, wheels@mks.UUCP writes: > In article <25784@rochester.ARPA>, I write: > > The chips that handle the RS-232C interfaces treat these > > signals as EDGE-TRIGGERED. > > I remember reading that, I think in the Abacus book, but then I also heard > that was only in the early versions and had been changed for TOS in ROM. Your source misinformed you. I have a 1040STf with TOS in ROM. It exhibits exactly the behavior I described. The interface chip is STILL a MC68901, which is STILL edge-triggered. You do have your choice of positive or negative transitions, which is why I said that I thought the problem was fixable with fancier software (in a nutshell look for the absence of the negative transition, and keep transmitting). It may well be that the Avatex and the UR Robotics do not have significant buffering (they have at least one character of buffering of course, since the register from which they shift out bits on the the telephone line is obviously not the register in which they store the latest character from the ST). That is a quibble, because the behavior I described with the sustained CTS signal is not dependent of modem buffer length, only on the absence of overrun from the host. Let's not quibble. Stu Friedberg