Slightly unmatched UART frequencies

Philip, 
<BR><BR> 
after thinking about the problem once more, I hate to admit that, yes, you are right. 
<BR><BR> 
I still do not believe, though, that inserting idle time one way or the other (including cutting the transmitter's stop bit) is a solution. Consider the following: 
<BR><BR> 
Left side: Slow (9600 Baud) <BR>
Right side: Fast (9700 Baud) 
<BR><BR> 
Both sides use e.g. 8N2 for Tx and 8N1 for Rx. 
<BR><BR> 
At some point in time, Left see's its buffer filling up and hence skips a few stop bits here and there (using 8N1) in order to compensate this. Left is now faster that Right, despite of the clock rates. 
<BR><BR> 
As a consequence, Right sees its buffer filling up and skips stop bits (using 8N1) as well. 
<BR><BR> 
This continues until both sides transmit with 8N1 all the time; at this time Left will loose data. 
<BR><BR> 
Thus, there must be some kind of understanding between Left and Right, which of the two is the "clock master", that ultimately controls the transmission speed. Unfortunately this is sometimes not possible, for instance in symmetric configurations. 
<BR><BR> 
/// Juergen

Philip Freidin wrote:
> The following solutions can be made to work:

<A to F snipped>

G) copy the scheme used in the TI MSP430, effectively a DDS.
   Using this arrangement gets you a lot more speed, and you
   can take the TI documentation as a spec and save a ton of
   time...

If you do it, please forward the results to Xilinx for a
writeup as an App Note ;-)

Hal Murray <hmurray@suespammers.org> wrote:
>> You bright up a good subject, and you're absolutely correct that if you
>> continuously send data from one serial port at 9600.01bps to a receiver
>> at 9600, sooner or later there must be a buffer overflow. ...
>
> I think you are missing a key idea.  The receiver has to make
> sure that it will tolerate early start bits.  That is the receiver
> has to start looking for a new start-of-start-bit right after
> it has checked the middle of the stop bit rather than wait unitl
> the end of the stop bit to start looking.

Unless your (slightly slower) transmitter also has the capability of
producing shortened start (or stop) bits, how those this approach 'fix' the
problem?  If the date rates are, say, 9601 received BPS and 9600 transmitted
BPS, detecting early start bits just buys you one extra bit interval before
your overrun your buffers, doesn't it?

---Joel

juergen Sauermann wrote:

(snip)

> I still do not believe, though, that inserting idle time one way or the 
> other (including cutting the transmitter's stop bit) is a solution. 
> Consider the following:
> 
> Left side: Slow (9600 Baud)
> Right side: Fast (9700 Baud)
> 
> Both sides use e.g. 8N2 for Tx and 8N1 for Rx.
> 
> At some point in time, Left see's its buffer filling up and hence skips 
> a few stop bits here and there (using 8N1) in order to compensate this. 
> Left is now faster that Right, despite of the clock rates.
> 
> As a consequence, Right sees its buffer filling up and skips stop bits 
> (using 8N1) as well.
> 
> This continues until both sides transmit with 8N1 all the time; at this 
> time Left will loose data.

As far as I know, asynchronous transmission was intended to be between 
two devices, such as a terminal and a computer, though more likely two 
terminals in the early days.

The two stop bits were required by machines that mechanically decided 
the bits.  (The Teletype (R) ASR33, for example.)  Using stop bits as 
flow control seems unusual to me.

Electronic UARTs (no comment on mechanical ones) sample the bit at the 
center of each bit time.  For a character with no transitions (X'00' or 
X'FF') timing error can accumulate for the duration of the character. 
The STOP bit is the receivers chance to adjust the timing, and start 
over with the new START bit.

With a 5% timing error, which is very large for a crystal controlled 
clock, the stop bit could start 0.45 bit times early, but the receiver 
will still detect it at the right time, and be ready to start the next 
character.

The timing for each character is from the leading edge of the START bit.

This allows for difference in the bit clock rate between the transmitter 
and receiver.   It is unrelated to any buffering or buffer overflow 
problems that may occur.

-- glen

"Philip Freidin" wrote
>
<snip>
> And Philip writes:
> Modifying the local transmited character to be a non-standard length
> by changing the length of the stop bit on the fly as buffer
> over-run is about to occur is not a good idea, as you don't
> know the details of how the receiver that is listening to it was
> designed, and it may not be very happy to see the next start bit
> before it is finished with what it expects is a full length stop
> bit, but it is not.

UARTs look for the START edge, from the _middle_ of the STOP bit.
With x16 clocking, typically that gives 8 possible time slots for earlier
start.

 I would agree that a half-bit jump in STOP, as the OP first suggested,
is NOT a good idea, but fractional (1/16 quantized ) STOP changes are
valid and safe.

<snip>
>
> BUT this is not a solution to the original poster's problem!
> The problem still exists because the remaining .5 bit is still
> going to arrive, the data is being sent with a slightly faster
> clock than the transmitter is able to retransmit the character.
> If there is no line idle time between the end of the inbound
> stop bit and the next inbound start bit, the system will
> eventually have an over-run problem, no matter how big the
> input buffer. The closer the two clock rates, and the bigger
> the buffer, the longer it takes to happen, but it will happen.

 Yes, true if the stop bit is 'whole bit' quantized.
CAN be avoided if  the TX can move the START edge as
needed, both left and right, in 1/16 steps. Something like
+/-4 sixteenths would leave design margin.

> F)
> Be sneaky. Most UARTs can be set for 1 , 1.5 , or 2 stop bits.
> Set the far end transmitter for 8N2 (1 start, 8 data, 2 stop).
> Set your receiver and transmitter for 8N1 (1 start, 8 data, 1 stop).
> This works, because stop bits look just like line-idle. This
> effectively implements (B), but is localized to the initialization
> code for the far end transmitter.

Yes, by far the simplest, and most practical solution.

However, this is comp.arch.fpga, and here we can design any UART we like,
including one that can handle 100% traffic loading, single stop bits, and
1-2% region clock skews. !  :)

 To illustrate this, look at the SC28C94 UART data, this from info
on their 16 possible STOP BIT options:

MR2[3..0] = Stop Bit Length
0 = 0.563
1 = 0.625
2 = 0.688
3 = 0.750
4 = 0.813
5 = 0.875
6 = 0.938
7 = 1.000
8 = 1.563
9 = 1.625
A = 1.688
B = 1.750
C = 1.813
C = 1.875
E = 1.938
F = 2.000

-jg

Here is my simple analysis:
There are two very different situations:

If the transmitter clocks slower than the receiver, there is no problem
on the receive end, as long as the error inside the word does not exceed
half a bit time.

If the  transmitter clocks faster than the receiver, the receiver has to
be able to resynchronize after only half a stop bit (which may be touchy).

Peter Alfke
==============================
glen herrmannsfeldt wrote:
> 
> juergen Sauermann wrote:
> 
> (snip)
> 
> > I still do not believe, though, that inserting idle time one way or the
> > other (including cutting the transmitter's stop bit) is a solution.
> > Consider the following:
> >
> > Left side: Slow (9600 Baud)
> > Right side: Fast (9700 Baud)
> >
> > Both sides use e.g. 8N2 for Tx and 8N1 for Rx.
> >
> > At some point in time, Left see's its buffer filling up and hence skips
> > a few stop bits here and there (using 8N1) in order to compensate this.
> > Left is now faster that Right, despite of the clock rates.
> >
> > As a consequence, Right sees its buffer filling up and skips stop bits
> > (using 8N1) as well.
> >
> > This continues until both sides transmit with 8N1 all the time; at this
> > time Left will loose data.
> 
> As far as I know, asynchronous transmission was intended to be between
> two devices, such as a terminal and a computer, though more likely two
> terminals in the early days.
> 
> The two stop bits were required by machines that mechanically decided
> the bits.  (The Teletype (R) ASR33, for example.)  Using stop bits as
> flow control seems unusual to me.
> 
> Electronic UARTs (no comment on mechanical ones) sample the bit at the
> center of each bit time.  For a character with no transitions (X'00' or
> X'FF') timing error can accumulate for the duration of the character.
> The STOP bit is the receivers chance to adjust the timing, and start
> over with the new START bit.
> 
> With a 5% timing error, which is very large for a crystal controlled
> clock, the stop bit could start 0.45 bit times early, but the receiver
> will still detect it at the right time, and be ready to start the next
> character.
> 
> The timing for each character is from the leading edge of the START bit.
> 
> This allows for difference in the bit clock rate between the transmitter
> and receiver.   It is unrelated to any buffering or buffer overflow
> problems that may occur.
> 
> -- glen

On Tue, 25 Nov 2003 06:36:03 +0200, "valentin tihomirov"
<valentinNOMORESPAM@abelectron.com> wrote:

>UART is used to transfer a byte in serial form bit-by-bit. I know that 10%
>deriviations in frequencies of transmitter and receiver are permissible. I
>was learnt that UARTs synchronyze at the falling edge (1to0) of start bit;
>hence, there should allow for transfer of a stream of bytes of arbitrary
>length.

ITU-T Recommendation V.110 (a.k.a. I.463) explains how to do
synchronous to asynchronous conversion (to get async serial signals
across ISDN).  This includes things like stop bit shaving.

http://www.itu.int/rec/recommendation.asp?type=items&lang=e&parent=T-REC-V.110-200002-I

Regards,
Allan.

> > As far as I know, asynchronous transmission was intended to be between
> > two devices, such as a terminal and a computer, though more likely two
> > terminals in the early days.
> > 
Originally developed by Emille Baudot (google) for telex. Hence Baud.
Buffer overflows are irrelevant in the modern world since the
terminals will be handling the data far faster than the transmission
rate. All that is required is the receiving uart detect the start bit
reliably. Longer stop bits help.

valentin tihomirov wrote:
> 
> > When you say "your" UART, is this a design you did yourself in an FPGA?
> Yes, you're right I have my design runs on CPLD. However, the qestion is
> more in logic rather than implementation. The value 10% I have got from
> www.8052.com's forum where "Software Uart" is a hot topic.

Well, this is not correct.  Analyze the situation yourself and see at
what point the receiver will not sample the data at the correct time. 
You will find the allowed slip is half a bit over the whole word which
is about 5% give or take.  


> > If so you may not have designed the logic correctly.  In order for the
> > receiver to synchronize to a continuous data stream, it has to sample
> > the stop bit in what it thinks is the center and then *immediately*
> > start looking for the next start bit.  This will allow a mismatch in
> > speed of almost a half bit minus whatever slack there is for the sample
> > clock rate.  BTW, you are sampling at at least 8x the bit rate, right?
> I use 16x oversampling and check input values at middle of a bit (SampleCnt
> = 7). You suggest exactly what I have done. I think receiver part will work
> under any condition. 

That assumption is where you are wrong.  There is nothing the
transmitter can do to change the way it works unless you *always*
transmit at a rate slower than your receiver.  

The transmitter can be either faster or slower than the receiver.  If
the transmitter is slower than the receiver, then the start bit
detection will simply happen a few clocks after the end of the stop bit
rather than right at the end.  If the transmitter is faster than the
receiver, then the start bit detection has to occur before the end of
the timing of the stop bit.  If the transmitter starts the start bit
early you make the problem worse.  If the transmitter delays the start
bit, then this will prevent any issues.  So you can eliminate the
problem by sending two stop bits and only looking for one at the
receiver, but clearly this is not how commercial units work.  

Commercial receivers start looking for a start bit leading edge as soon
as the middle of the stop bit has been timed and checked.  You need to
do the same thing.  You don't care when the end of the stop bit
happens.  You only care about the leading edge of the start bit which
may be a bit earlier than the end of the stop bit as timed by the
receiver.  

Others have posted in this thread by this point all the info you should
need.  If you still don't understand what is wrong with your
understanding of the problem, let us know and we will try to make it
more clear.  


> But I need to know what should I do with transmitter
> module. As I attempted to explain, this half-bit solution cannot be used to
> synchronize transmitters. It is a bad idea to start transmitting next byte
> at the middle of the stop bit. It may fail listening device with slow clock
> as it reaches center of stop bit when start bit of next byte is being
> transmitted. On the other hand, if data is coming slightly faster
> transmitter should do something, otherwise I face buffer overrun condition.
> I understand that I can ignore the problem with transmitter module, it is
> receiver that should synchronize with transmitter. However, I had got buffer
> overrun problem until I used a trick described in my message (early
> transmit). It is defenetely not the problem with receiver because I have
> solved it right before got problem with transmitter's buffer overrun. And I
> want to know how should function correct logic; there should be a solution
> as commertial UARTs work without any problems. My UART is the first one
> where I've realized that it is at all possible to get a problem with slowly
> transmitting uart.
> Is now the problem become clearer?

To us, yes.  Is it more clear to you as well?  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Joel Kolstad wrote:
> 
> Hal Murray <hmurray@suespammers.org> wrote:
> >> You bright up a good subject, and you're absolutely correct that if you
> >> continuously send data from one serial port at 9600.01bps to a receiver
> >> at 9600, sooner or later there must be a buffer overflow. ...
> >
> > I think you are missing a key idea.  The receiver has to make
> > sure that it will tolerate early start bits.  That is the receiver
> > has to start looking for a new start-of-start-bit right after
> > it has checked the middle of the stop bit rather than wait unitl
> > the end of the stop bit to start looking.
> 
> Unless your (slightly slower) transmitter also has the capability of
> producing shortened start (or stop) bits, how those this approach 'fix' the
> problem?  If the date rates are, say, 9601 received BPS and 9600 transmitted
> BPS, detecting early start bits just buys you one extra bit interval before
> your overrun your buffers, doesn't it?

No, by looking for the start of next word before the last word is
complete, the receiver can receive data faster than you would calculate
given the clock speed and the bit count.  The receiver can receive data
in 9.5 bit times per byte rather than the 10 bit times per byte the
transmitter takes to send them.  That is where the 0.5 bit or about 5%
rate mismatch numbers come from.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX