On Sun, 24 Oct 1999, der Mouse wrote:

> I'm not sure I like that, because it means you can ask for one output
> rate and get another.  For input, you're right, it doesn't matter so
> much, but if you're talking to something that wants exactly 115200,
> *it* may not be willing to tolerate 111709+ or 117029- or whatever,
> even if *you* are.

If it's doing asynchronous character i/o, then it probably won't really
matter. Because it will be doing all the same things on receive that the
8530 is doing, so it won't care for the same reasons. :-)

> They drive transmission off the same divisor chain?  How do they do
> split speeds?  Or don't they?

They only partially split speeds. The BRG, TRxC, and RTxC clocks are
independent clock sources. The transmit and receive sides can choose
any one of them, but 1x, 16x, 32x, and 64x is a per-channel parameter.
i.e. they don't split speeds well. :-)

Our driver doesn't split speeds. :-)

> I wouldn't *expect* them to, but in general, different things from
> different manufacturers are liable to be different.  When it's as
> simple as a 7400, perhaps, the differences will be limited to the logo
> on the case :-), but with something as complicated as a UART, it
> wouldn't surprise me that much if manufacturer B decided to "do it
> right".  Especially if manufacturer A's part has been around long
> enough to exasperate designers with its more exasperating "features".
> (I don't know whether any of this describes the 8530 except to the
> extent that what say certainly makes it sound as though it doesn't.)

While there are "features" which were modified in future versions of the
chip, they all entailed a chip number change - they weren't called 8530's
anymore. And there are a lot of other things higher on the "do it right"
list than supporting 1x asynch BRG mode. :-) Like making it so that you
can actually read what you wrote to the chip control registers. :-)

> It sounds as though SPARCs will just have to live with crippled serial
> chips.  Feh, and here I was hoping I could actually run the things fast
> enough to be useful.

Do they have DMA channels? _THAT_ would make them useful. :-)

> Well, perhaps X1 mode can be useful anyway; there are doubtless
> applications where its problems would be tolerable - anything
> output-only, for example, won't care.  I wonder if it's possible to run
> the transmitter with two stop bits and the receiver with only one; that
> would help with the drift problem, though not with the "sampling when
> the signal is changing" problem.

I'm not sure if the receiver cares about 1 vs 2 stop bits..

Also, about the drift problem, the bit-slip problem is the exact same
thing as the sampling when changing problem. i.e. the sampling problem
occurs right when the bits are slipping relative to each other.

Think about the two clock streams when they are synced up. There's a
relative phase difference of 0. As you move forward and backwards from
that point in time, the magnitude of the relative phase will increase,
getting negative one way and positive the other. As long as the relative
phase is less than 180 degrees (*) (1/2 a bit), the two streams are in
sync. When they get to 180 degrees out of phase, that's both when the bit
slip happens, and when the receiver's sampling at the same time as the
transmitter's changing.

(*) It won't be 180 degrees because this analysis has ignored the fact
that the transmitter requires a finite time to change state, and the
receiver needs the input stable for a finite time.

Take care,

Bill