23 Jan
2014
23 Jan
'14
8:41 p.m.
On Jan 23, 2014 8:54 PM, "David Riley" <fraveydank at gmail.com> wrote:
When I've done UARTs in FPGAS, I typically only do
the
sampling in the middle of the bit period.
I'm sure you are aware of it, but for the benefit of others, it should be
noted that this is the middle of the bit period from the receiving UART's
perspective, and may not match the transmitting UART's middle-of-stop-bit
time for two reasons:
1) There may be a timebase mismatch between the two ends. In the 1980s an
1990s, almost all async comms were locked to a crystal oscillator or at
least a ceramic resonator, so there was not much mismatch. Before that
there were mechanical async devices (e.g., Teletypes), and even some
electronic devices that used poor timebases such as RC oscillators (e.g.,
early PDP-11/05). It was considered acceptable to have a timebase error at
each end of more than +/- 1%. By the end of an 10-bit or 11-bit character,
the cumulative timebase error is significant. In recent year there are an
increasing number of async interfaces that are using various forms of
trimmed electronic oscillators, or even temperature-compensated RC
oscillators, so non-trivial rate mismatches are become more common again.
2) The receiving UART typically oversamples the receive data signal at 16x
the receive bit rate. The receiver uses the first sample that it detects a
space (vs mark) signal as the leading edge of the start bit, and samples
the bits at 8 +/- 16n clock cycles thereafter. That introduces a 1/16 bit
time uncertainty in the timing of the samples, though that is
non-cumulative and thus usually of little concern.
I do check for
a stop bit in order to detect framing errors, but slicing off
the last eighth of the stop bit would probably go entirely
unnoticed by any of my implementations, which seem
to follow most "best practices" as far as efficiency goes.
That's right. Normal UART receivers, once they've sampled the putative
middle of the stop bit, will look for a leading edge of a start bit at
every subsequent sample time, rather than delaying until the expected end
of that stop bit.
V.14 stop bit shaving aside, I suspect the uPD7201/8274 receiver would be
much less forgiving of a rate mismatch at the extreme of the normally
allowed timing tolerance than other UARTs.
The problem exists in the uPD7201/8274 and the uPD7201A. I don't know
whether NEC fixed it in the uPD72001.