> At 08:40 AM 5/30/97 +0000, you wrote:
> >Different UART's behave differently things when they receive an
> >incorrectly-framed packet.  The approach I took in my interrupt-driven
> >software UART (which I personally would like to see done in hardware) is
> >to hold the last 32 bits that came in [sampled with a 3xbaud clock] and
> >grab a byte whenever a properly-aligned byte has been shifted in.  IMHO,
> >this should allow the UART to correctly-align itself after a framing error
> >much faster than the conventional techniques (other approaches include
> >delaying start-bit detect until the next *falling edge*, or regarding the
> >missing stop bit as the next byte's start bit).  Does anyone know if any
> >hardware designer has ever done a UART this way?
>
> Nice concept, but 3x might not be too much fun to implement in h/w.

I'll admit that a shift register wired this way will be three times (or
five times, or whatever) times as large as the one in a conventional UART.
The extra 20/40/whatever bits of shifter should be offset, however (IMHO)
by the simpler framing logic: rather than having to count the incoming
bits, you can just look for the proper pattern:

   100--d--d--d--d--d--d--d--d--1

When the shifter contains the leaidng "100" and the final "1", then sample
all of the "d"'s and clear the shifter.  Should be quite simple and
effective, and would allow recovery of many framing errors conventional
units can't handle (for example, many uarts will *never* resync if fed an
endless stream of ASCII text and they mistakenly sync on bit 7 of a byte).

Personally, I'd think there would be two logical methods of UART design:
one would be to use a shift register and look for a pattern.  The other
approach would be to have the transmit and receive use seperate
clock/counter circuits and have the receive clock run at either 1/2 or 1/3
the bit rate *when there is actually data there* (otherwise keep the clock
zeroed).  If "1/2 the bit rate" is chosen, then sample the start bit after
the first clock, and data bits after clocks three, five, seven, etc.  If
"1/3 the bit rate" is chosen, then time could be divided into "stable" and
"transition" zones; if the signal changes during a time it's supposed to
be stable, an error could be flagged.

While this latter approach would require seperate programmable dividers
for transmit and receive, this would have the benefit of allowing distinct
TX/RX rates and also allow the divide-by-16 in most UARTs to be replaced
with a divide-by-two.  In addition, the idle current for a UART that was
waiting to transmit/receive data could be reduced because the divider
wouldn't have to be running except when transmission or reception was in
progress.