🚀 go-pugleaf

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!