'async serial tolerances (was Re: ceramic resonator'
> If you are using standard asynchronous serial with 10-bit frames
> (1 start bit, 8 data bits, 1 stop bit), then your cumulative clock
> mismatch for both ends can be almost 10% and still work correclty.
Russell McMahon replied:
> Actually you are only allowed about 5% relative error between the two
> ends as you can only get 1/2 a bit out (not one whole bit) before
> you are sampling in the wrong bit - the sampling starts in the middle
> of the 1st bit after the leading edge of the start bit and must still
> be inside the correct bit when the sample for the last data bit
> arrives, 8.5 bit times later.
> (1/2 bit) / (8.5 bits) ~ 5.8%
Actually it's worse than that. The reference point for receiver sampling
is the leading edge of the start bit, and needs to be within 1/2 bit time
by the middle of the stop bit, which is 9.5 bit times later (assuming
typical 8N1 settings).
(1/2 bit) / (9.5 bits) = ~ 5.3%
This is neglecting the fact that the receiving UART typically only samples
the serial line at 16x the bit rate. At that sample rate, you can be
up to 1/2 bit time fast, but no more than 7/16 bit time slow:
(7/16 bit) / (9.5 bits) = ~ 4.6%
And remember, this is the total mismatch between the ends. It doesn't
mean that one end can be 4% slow and the other 4% fast. If you apportion
the mismatch between the ends, they can each be off a smidgen over +-2%, but
good engineering practice suggests that they should be designed to a
tolerance of 1% or better.
My full duplex software UART for the PIC and Scenix SX samples at only 3x the
bit rate, and is designed to sample somewhere within the middle 1/3 of each
data bit. This allows a tolerance band of of -1/3 bit time after 9 1/3 bits,
and +1/3 bit time after 9 2/3 bits:
(1/3 bit) / (9 1/3 bits) = ~ 3.5%
(1/3 bit) / (9 2/3 bits) = ~ 3.4%
When I worked this out a few years ago, it surprised me how little margin
is lost in reducing from 16x sampling to 3x.
|My full duplex software UART for the PIC and Scenix SX samples at only 3x the
|bit rate, and is designed to sample somewhere within the middle 1/3 of each
|data bit. This allows a tolerance band of of -1/3 bit time after 9 1/3 bits,
|and +1/3 bit time after 9 2/3 bits:
|(1/3 bit) / (9 1/3 bits) = ~ 3.5%
|(1/3 bit) / (9 2/3 bits) = ~ 3.4%
|When I worked this out a few years ago, it surprised me how little margin
|is lost in reducing from 16x sampling to 3x.
The key is that "3x" is an odd number. Had you used 4x sampling,
you would have had to have been within 1/4 bit time, but with 5x
sampling your margin improves to 2/5 bit time.
Frankly, I find it almost puzzling that everyone does UARTs the
same way they've been doing them for millenia, when there are some
definite annoyances in the existing designs (e.g. the requirement
that the crystal clock by a multiple of 16x the baud rate). I've
divised a much better timing mechanism than the normal divide down
counter, though I've never seen anything like it used for a UART.
Also, another trick I once used in a software UART which seemed to
work quite well was to implement, basically, a 32-bit shift register
through which data was shifted at 3x the baud rate. Whenever the
pattern in the shifter was valid (i.e. it started out "10" and there
was a "1" the proper length of time later) it would grab the byte from
the shifter and clear it. Because framing errors don't clear the buf-
fer, the software UART has a chance to detect start bits that follow
right after a glitch (whereas hardware UARTs are totally lost in such
a case). Implementing such a trick using a 5x clock would require
about a 48-bit shift register, but would then allow for stability val-
idation on the incoming data bits; with my baud-rate generator tech-
nique generation of the 5x clock would pose no problem.
|At 17:02 29/10/98 -0600, you wrote:
You sample in near the middle or expected middle of the bit cell so that the
incoming data can be out by 1/3. That's OK, so long as the timer is
restarted at the end of each expected bit cell.
But one must ask is there a problem with this? Well yes there is, your
system is not noise tolerant, in fact there can be an error in the bit cell
after the test period that may change the actual bit value, but you would
not know this. Also do you test the entire period of the 1/3 cycle, or just
at the start, or at the end? The reason for the 16x clock rate is so that
the UART can time slice the bit into 16 portions, it then uses this as a
majority voting scheme to check the actual bit value, nominally 11 out of 16
must agree, and thus remove the "Glitch" before a start period, also note
that the start of a start bit will start the internal counter for the one
full expected bit cell period, if a valid start period is not received then
the framing error is generated, but a byte can still be received.
|Dennis Plunkett <RDD.NECA.NEC.COM.AU> wrote: dennis
> But one must ask is there a problem with this? Well yes there is, your
> system is not noise tolerant, in fact there can be an error in the bit cell
> after the test period that may change the actual bit value, but you would
> not know this.
All UARTs can be fooled by noise; some more easily than others.
> Also do you test the entire period of the 1/3 cycle, or just
> at the start, or at the end?
Since I sample at 3x, the start bit is detected somewhere within the
first 1/3 bit time. Thus taking the next sample 4/3 bit time later is
guaranteed to be somewhere within the middle 1/3 of the bit. All subsequent
samples are taken integral multiples of a bit time (3 sample periods)
> The reason for the 16x clock rate is so that
> the UART can time slice the bit into 16 portions, it then uses this as a
> majority voting scheme to check the actual bit value, nominally 11 out of 16
> must agree,
I have not even heard of any that require 11 samples to vote. Many UARTs
only use a single sample in the middle of the bit cell (actually, somwhere
between 8/16 and 9/16 of the cell, just as mine is between 1/3 and 2/3).
A few take three samples.
I never suggested that my 3x sampling technique was better than (or even as
good as) a typical hardware UART. But let's see you write a reasonably
reliable 9600 bps full-duplex UART in software on an 8 MHz PIC, and still have
cycles left to do other things. Hard enough at 3x; if you can do it at 16x,
more power to you.
The same code supports 115.2 Kbps full duplex on a 50 MHz Scenix SX (in
turbo mode) using less than 1/4 of the available CPU cycles.
Often I use this technique on a PIC or SX that is on the same board as
another processor with which it will communicate. The noise immunity is
generally not an issue in this case. However, I've had perfectly good
results using my 3x-sampling software UART with a MAX-232 and 25 feet of
cable to a PC. If you're not trying to design a system to operate in a
steel mill, the lack of majority voting on 16x samples is acceptable,
especially if you use error control at a higher protocol level.
'async serial tolerances (was Re: ceramic resonator'
Peter L. Peres
On Sat, 31 Oct 1998, Eric Smith wrote:
Strange, I also wrote my own receiver code, and I use a H->L flank-locking
on the start bit followed by a 3 x sampled start bit and every successive
bit is sampled in the middle once only. It has never occured to me to
oversample, as my signals are often garbled (remote control audio etc) so
the areas near the flanks are not such a good idea to check anyway.
More... (looser matching)
- Last day of these posts
- In 1998
, 1999 only
- New search...