Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!asuvax!mcdphx!mcdchg!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.sys.att
Subject: Re: serial printer problem on 3b2-600
Message-ID: <1990Aug29.142139.17537@chinet.chi.il.us>
Date: 29 Aug 90 14:21:39 GMT
References: <587@otello.sublink.org> <506@mtndew.Tustin.CA.US>
Organization: Chinet - Chicago Public Access UNIX
Lines: 35

In article <506@mtndew.Tustin.CA.US> friedl@mtndew.Tustin.CA.US (Steve Friedl) writes:
[XOFF skid on 3B2 EPORTS...]
>     At 19200bps it is reportedly 16 or 32 character times (don't
>remember which), and for some devices -- the HP LaserJet comes to
>mind again -- this is just too much.  The only solutions are to
>slow down the printer, use hardware flow control, or get a real
>computer like an NCR Tower :-).

Another way that should work would be to add one of those serial buffer
boxes that are commonly used between PC's and printers.  They can
be found for <$100 in the smaller buffer sizes, which should be cheaper
than dumping the computer (at least in the short run). 

>     To really do this right would require that the UART have
>special "watch" character so it would issue an interrupt if the
>mentioned character arrived in the port.  Then the onboard CPU
>could do scanning as usual with occasional forays to service a
>port that just got XOFFed.  Alas, this wasn't done on EPORTS.

No, to do it right the on-board CPU should have sufficient capacity
to service the received character interrupt from the UARTs under
all conditions.  Micro-CPU's are not prohibitively expensive for
this.

[...software/hardware flow control are mutually exclusive]

>    If anybody out there knows of ANY reason why this is the
>case, even a bad reason, I would love to hear it.  I want very
>much to believe that AT&T is not full of sh*t, but so far that's
>the only conclusion I'm able to come to. 

Well they do have that reputation to maintain.

Les Mikesell
  les@chinet.chi.il.us