WARNING: long message, filled with personal experience and my version of the
"facts". If you feel inclined to skip it, please make sure you read the last
screen before you do so. -Geoff
> >I recommend that you try replacing the 8250 or 16450 chips with National
> >NS16550 chips, which have 16-level FIFOs built into the receiver and
> >These chips function just like 8250s unless they are explicitly put into
> >FIFO mode by software.
> Do you mean I can physically replace the 8250 on my serial board with
> a 16550? Wouldn't there be some trouble with the difference between
> edge and level triggered interrupts?
In its powerup default mode, the NS16550A acts identically to the 8250 and
16450 - all registers and signals are identical. Enabling the 16-byte FIFO
buffers doesn't change much except that:
(1) You can set the "trigger" level (i.e. generate received data interrupt
request when there are 1, 4, 8, or 14 bytes in the FIFO);
(2) When the driver reads data from the receive data register, it should check
the "byte waiting" flag and loop back to fetch the next byte from the FIFO
(good software will do this anyway, since a byte could arrive on an 8250
immediately after the last was removed);
(3) When servicing a "transmit register empty" interrupt, you may write 16
bytes to the transmit data register in stead of one (they will be latched into
the FIFOs automatically).
[The following is a GUESS, since a colleague has my 16550 spec book from NS]
As long as the driver clears all waiting received bytes, the interrupt
request line should go false again, meaning that edge-triggerred devices
should have no problem detecting the next interrupt request.
I don't think you should expect any troubles using a 16550 anyplace a 16450
or 8250 was used, with one proviso: Lord only knows what'll happen if you
enable DMA mode on a card that doesn't support it. (Yes, folks, the NS16550A
is also a slave DMA device, in case you want to build a card that runs serial
ports much faster than interrupts could service properly).
> Has anyone actually tried this, and how did the 16550 perform compared
> to the 8250?
I have always used NS16550As as an "instant solution" when:
(1) the client's CPU can't keep up with the interrupts;
(2) the client refuses to part with his Perstor controller <grin>;
(3) the client insists on accessing 286-extended memory under DOS;
(4) the client insists on using OS/2 (esp. with compatibility box!);
(5) the client's system gets bogged down with too many tasks.
I have observed only three possible outcomes (keep in mind that "no
difference" means that the 16550 reacted as an 8250 did; in the majority of
cases, that indicates that the problem was NOT solved, since I wouldn't have
been called upon if the 8250/16450 had operated without a hitch!)
(1) The software thwarts me (i.e. it insists on setting up the "8250" from
scratch and, in doing so, shuts off the FIFOs). Result: no difference.
(2) The software does not set up the "8250" from scratch (allowing me to
enable the FIFOs using an external utility, if necessary), but doesn't fetch
more than one character at a time. Result: ranges from characters lost (i.e.
no difference, remember?) to characters no longer lost, but no overhead saved.
(3) Either the software recognizes the 16550 (DSZ and Telix do, for instance)
or it works fine when the 16550 is externally enabled. Result: no characters
lost, overhead reduced somewhat (exact amount of overhead reduction depends on
how well the driver makes use of the FIFOs and how well the 16550 trigger
level is tuned to the response time of the CPU; ideally the driver should
write 16 bytes to the transmit data register at a time and the 16550 should be
timed so that the driver responds just as the FIFOs are reaching 16 bytes, so
that more bytes can be transferred in a single interrupt)
There are two important gains to dropping this chip in for an 8250:
(1) No need to worry about characters being lost because of the 16-byte
(2) No need to incurr full interrupt overhead for every byte when it can be
reduced to one interrupt for every 16 bytes.
> I am interested in this because we use KA9Q as an SLIP-Ethernet IP router
> here and it runs wonderfully at 2400 but not at all at 9600, and we would
> like to run it at the higher speed.
That's exactly the situation I am often called to look at. I bring a 16550
along and drop it in for the 8250. I try the software with and without using
an external utility to enable the FIFOs beforehand and, most of the time, the
However, you may be jumping the gun. If the problem lies not with the
system losing the characters in the UART but rather because of improper
handshaking configuration, a 16550 will not help. Guaranteeing that the CPU
won't miss any characters doesn't gain you anything at all if your driver is
out of buffer space and the modem is ignoring the driver's plea (RTS, XOFF,
whatever) to stop sending data!
Geoffrey Welsh - via FidoNet node 1:221/171