Re: Dropping chars on 16550

Igmar Palsenberg
2000-12-14T13:58:10Z

> there are many situations in which a 16550 is KNOWN to be overrunable, all
> of which can occur in your common PPP connection.
>
> More importantly - if you have 2 16550's talking together (Which is
> EXACTLY what you have, when you hook it to a modem) there are even MORE
> overrun possibilities. (For instance, when you fill the transmitter up to
> 16 bytes - on a uart, and then the receiving side suddenly drops RTS,
> there is *NO* way for that 16550 to stop its transmitter. Once the bytes
> are in its fifo, it HAS TO SEND THEM.)

Indeed. I saw this behaviour some years ago when I was debugging a
controller that went beserk when been talked to at a 115k2 buad rate.

My modem isn't on 115k2 now, so I don't see the problem often. I'm gonne
setup a second machine with remote kernel debugging, since I'm sick of
rebooting when I want to scan something.

> This is where a 654 or an 854 (I'm only listing startech design chips.
> there are others that would do the job.) come in handy. They can pause
> their transmitter WITH bytes in their fifo. (Automated hardware/software
> flow control.)

Indeed. Most chips I've seen are 1 16550, or pretend to be. Probably an
issue of cost (At least, I think :))

> I have no idea why the 16550 caught on as the "De facto standard" like it
> did. there are UARTS out there that are more efficient, yet cost only a
> few dollars more to manufacture.

Well.. Why is the i386 the defacto standard ? There architectures that are
a lot better. Reason it is that the some big company used it, and it got
populair.

> (Your common QUAD 16654 chip costs $20 to an end user, nowadays. Your
> common QUAD 16554 costs about $15.)
>
> Imagine what the 2-UART chips would cost. (or, mass-produced all-in-1
> sets even.)
>
> Really makes you think.

Indeed.. Why do they save $15 bucks on a modem chipset, and replace it
with a buggy software driven solution... Making things as cheap as
possible, to make sure the're chaper then their compatitor.

> Chad

Igmar