hays@apollo.UUCP (03/13/87)
In article <25784@rochester.ARPA> stuart@rochester.ARPA (Stuart Friedberg) writes: >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. Some of us really need hardware flow control! -- John D. Hays, Consultant UUCP: ...!decvax!wanginst!apollo!hays Corporate Systems Engineering ...!uw-beaver!apollo!hays Apollo Computer Inc. CIS: 72725,424 {weekly} !MY OPINIONS, NOT Apollo's!