serial printer problem on 3b2-600

[Steve Friedl]

Paolo Venta writes:
> Hello, maybe some1 of you knows the trick to make a serial printer
> work correctly on a 3b2-600.

Hi folks,

     One of the most common things that I do is make printers
work after others give up [ pats self on back ], and flow control
is one of the biggest reasons why things don't work.  Rather
than answer him in email I thought I would post to maybe give
you folks some tips on dealing with flow control issues.

     First, we assume here that he is using the EPORTS card,
which has eight serial ports plus.  This is contrasted with the
older PORTS board that has four serial and one parallel port.
EPORTS has hardware flow control and much faster processors than
PORTS.

     When doing any significant RS-232 work, it is really handy
to have a breakout box or (better) a data line monitor.  Being
able to view the serial data stream is a major, major win when
trying to get it all to work.  I highly recommend the Datacomm
Technologies DataTool 5500 -- I'd be useless without it.

     First, some printers are really fussy about their incoming
control lines (usually DSR, DCD, and CTS).  Some printers will
refuse to print at all if the required combination of control
lines is not high, and others will simply refuse to issue an XOFF
(for instance, Okidatas).  If you have a breakout box, send a big
job and watch the data line from the printer and look for the
XOFF to go back.  If you don't see it, try asserting all inputs.

     Next, be careful when selecting the proper stty options.
Paolo's interface is using:

> stty -parity -tabs -hupcl cread -ixany ff1 ixon -ocrnl onlcr -onocr
> opost 9600 0<&1

     If it were me, I would probably add something like `cs8' to
specifically mention the wordsize and `istrip' to remove any stray
parity bits being set by the printer.

     I also notice that he has disabled `ixany' -- this is a good
thing.  As you'll recall, ixany means that any character can
restart control after an XOFF, and this will be Big Troubles when
the printer uses "robust XOFF".  This is when the printer sends
XOFF at regular intervals (say, once a second) while flow is
stopped, and it is done to compensate for the occasional XOFF
that gets lost.

     The problem is that the second XOFF will *restart* the flow if 
ixany is set, and it ends up being a real mess.  HP LaserJets can be
set up for robust XOFF, among others.

.nf
> I tried both short and long buffer on the printer. Same results,
> at different times (longest the buffer, latest the problem, but it
> always occurs).
.fi

     When testing flow control problems, reduce the size of the
printer's buffer as much as possible (disable it if possible).
There is no need to burn off a dozen pages to see that your flow
control is not happening -- disbale the buffer and find out
forthright.

     I further recommend that smaller buffers are better for
normal operation anyway.  These buffers are not the big win that
they are on a single-tasking operating system like MS-DOS, and
about the only thing a big printer buffer will buy you under UNIX
is a much longer time from killing an lp job to the time that it
actually stops.


     Now onto 3B2-specific problems.  The EPORTS card has
problems running XON/XOFF at high speed with some kinds of
devices.  Each of the input ports on the card has its own RAM
buffer, and data goes right from the UART to the RAM via a DMA
channel.  The onboard CPU scans these input queues at regular
intervals and transfers the data to the 3B2.  This is a really
great mechanism for getting VERY fast input/output rates.

     Let's say that the onboard CPU scans the input queue for
channel one and finds nothing.  At this time the output queue is
busy burning off characters to the printer, and at this very
moment an XOFF arrives.  The CPU has just finished with this
queue and has moved onto the next one.  While it is doing this,
characters are still blowing out channel one, and the printer is
getting nervous: "is it ever gonna stop?"  In time, the onboard
CPU gets around to channel one again and it sees the XOFF
deposited there.  It immediately stops the output flow right
away, but at high speeds it can be quite a significant time.

     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 :-).

     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.

     My understanding of AT&T's fix to this was to scan the
queues at a faster rate, allowing each channel to be serviced at
more regular intervals.

     Hardware flow control is a big win in any case.  Stop times
are very fast -- half a character time? -- because it doesn't rely on
scanning of the input queues.  I am not sure whether dropping of
CTS causes an interrupt or if the UART just inhibits the
transmit-buffer-empty signal (or disables DMA), but in any case
it is much much better than software flow control.  If you know
how to do it, use it.

     Note that printers are the only thing that hardware flow
control is good for on EPORTS.  For reasons that seem to escape
even the EPORTS support people, software and hardware flow
control are mutually exclusive, and this cause Many Big Problems
for people who want to use their cards for real things in the
real world.

    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.  It makes me want to
trade in my "3B2 UNIX" license plate :-(

     Steve

-- 
Stephen J. Friedl, KA8CMY / I speak for me only / Tustin, CA / 3B2-kind-of-guy
+1 714 544 6561  / friedl at mtndew.Tustin.CA.US  / {uunet,attmail}!mtndew!friedl

Steve's bright idea #43: put TV Guide on CD-ROM for quick access