Slightly unmatched UART frequencies

[valentin tihomirov]

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.

I have developed a simple UART. It's receiver and transimtter run at 9600
bps with 16x oversampling. Both receiver and transmitter have 1-byte buffer.
To test the design I've created an echo device; it merely mirrors all the
bytes sent to it back to the sender. It works fine with one of COM ports on
my PC. Another COM port has its crystal running at a bit faster fundamental
frequency. This causes a problem when it sends a long stream of bytes to my
UART. In fact, sender and recepient cannot synchronize at falling edge of
start bit because one of them is slower and is processing a previous byte
wrile sender proceeds to next byte transmitting start bit. Despite of the
fact, my receiver still works fine beacuse it is ready to receive next byte
right after a first half of stop bit is received. Just to clarify, receiver
acquares values from serial input at the middle of each data bit slice; it
reports BYTE_READY in the middle of stop bit and from this moment is ready
to accept next byte, i.e. ready fror synchronization. Therefore, if data is
coming slightly faster and falling edge of start bit is located within stop
bit (according to my UART's clock) receiver is still capable not to overlook
the data.
On the other hand, transmitter should transmit all 10 bits (start + 8 data +
stop) @ 9600 bps. Consider for instance an UART forwarder or an echo device.
If data is coming faster than I forward it I get a buffer overrun
ultimately. That is, receiver is ready with a byte in its buffer to be
copied into transmitter to forward but slow transmitter is still shifting
data out and its buffer is blocked.
I have a "fast" solution for my UART echo device; if transmitter has
transmitted > half of stop bit and sences that there is a next byte received
it stops sending current stop bit and starts transmitting a start bit for
next byte. Untimely ceasing transmission is not good solution because
transmitter may be connected to a good matched or slightly slower running
UART. Design may be not a forwarder thus data provider may differ from 9600
bps receiver. In this case, starting early transmission of next byte while
remote peer is still receiving stop bit causes stop bit error.

What is interesting in this situation is the fact I can build a good echo
device from any industrial manufactured UART (I've used standalone 16c750
and ones built into i8051). They never have a buffer overrun issue despite
sending port is slightly faster than receiving (like sending data from my
fast COM port to slow one). Note, no flow control is used, buffers are
always 1-byte long. Which trick do they use? Again, 10% frequency
dereviations between sender and receiver are considered permittable and no
flow control is not required since sender and receiver both run at formal
9600bps.

I feel this should be a well-known problem (solution) and just wonder why I
did not encounter this consideration before.

Thanks.

 

[rickman]

valentin tihomirov 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.

I have developed a simple UART. It's receiver and transimtter run at 9600
bps with 16x oversampling. Both receiver and transmitter have 1-byte buffer.
To test the design I've created an echo device; it merely mirrors all the
bytes sent to it back to the sender. It works fine with one of COM ports on
my PC. Another COM port has its crystal running at a bit faster fundamental
frequency. This causes a problem when it sends a long stream of bytes to my
UART.

When you say "your" UART, is this a design you did yourself in an FPGA?
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?

The max mismatch is not 10%, but a bit less that 5%. In the field I
find that 2 to 3% mismatch is reliable, but any more and you can start
getting errors. I guess the difference in theory and practice is
perhaps skew caused by the drivers.

Does this make sense?


--

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

 

[valentin tihomirov]

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.

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. 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?

 

[Joel Kolstad]

Valentin,

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. There's no way
around this -- but keep in mind that RS-232 (or most any protocol, for that
matter) isn't designed to send a truly continuous stream for days, months,
or years at a time without a break! With a typical RS-232 device, there are
MANY breaks, and keep in mind that something like a PC often has a pretty
generous software buffer (many kilobytes) backing up the hardware so that it
would take a 'long' time to create an overflow. I can't explain your
observation that an, e.g., 8031-based data forwarder -- supposedly -- works
other than to say I suspect that perhaps you didn't really do the type of
torture test that could produce an overrun. (I.e., did you look with a
scope or logic analyzer to make sure there was NEVER a idle bit time that
might have allowed the receiver to 'catch up'?)

One solution that you can use for protocols such as 8B/10B -- where you get
a bazillion data bytes interspersed with an occasional 'comma' character --
is to use a form of compression where you assign 9 bits to ever received
byte and 'swallow' any comma you get by setting the high bit. You can then
sit down and work out how often you need to insert a comma into your
bitstream to avoid buffer overflow. We had a gigabit fiber interface that
used this approach, and with a 16 byte FIFO for buffering and a +/-100PPM
clock at 1.0625Gbps, the numbers worked out to many thousands of bytes
before overflow would be a concern.

To build a data repeater that never suffers from potential buffer overflow
under any circumstances whatsoever, I don't think you have many options
other than locking the re-transmit bit rate to that of the received data
using, e.g., a PLL. You could try this in software as well, I suppose, if
you have a bit rate generator that's 'finely tunable' -- most in
microcontrollers aren't!

A few other comments:

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.

'Permissible,' yeah, I suppose, although 10% wouldn't be anything to write
home about!

I have developed a simple UART. It's receiver and transimtter run at 9600
bps with 16x oversampling.

Nothing wrong with 16x oversampling (it will definitely help -- a little),
but keep in mind that you _can_ get away with no oversampling at all and get
quite reasonable results if you position the sample point at the middle of
each bit interval.

---Joel Kolstad

 

[Hal Murray]

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.

[Interesting thread. Thanks. I didn't know about that trick.]

--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.

 

[Jim Granville]

"Hal Murray" <hmurray@suespammers.org> wrote in message
news:vs6612g8rso066@corp.supernews.com...

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.

Correct. If you really must tolerate continuous streams, with no data loss,
and only a single stop bit, then you must actually be able to 'pass on' data
at whatever average rate it comes in at.
Some UARTS have the idea of fractional TX stop bits to allow this, most just
choose
2 stop bits to give margin.
Receive should ALWAYS start looking for START at the middle of STOP.
( but chips do not always get this right

The OP's idea of a full half bit is a coarse example, that can force an
error, as it
jumps right to the limit

Since this was using 16x BAUD clocking, you can quantize to 1/16 of bit
time,
or in appx 0.625% steps. 4 of these is 2.5%, or 1/4 bit, that tolerates to
9840 Baud
If you don't want to use up all the error budget at one end, that's about
the limit.
( 1/4 bit at each end, or a tad less, if you use 3 slot vote sampling )

This is why most uC with trimmed on-chip OSCs specify 2.5% or 2% precision.

Since this a PLD device, you could watch for TX buffer phase, and nominally
send
a full STOP bit, but if the phase indicates margin problems (incomming
faster than outgoing)
you can decrement the STOP bit in 1/16 fractions - or you could force 15/16
wide STOP bit
and use a crystal, and keep the logic simpler. (tolerates to 9660 Baud, 100%
traffic )

A purists design would also extend STOP bits fractionally, (17/16 at ip
<9600Bd true)
so a sudden whole bit jump did not occur. That could cause problems if a
number
of these are in a chain, and a system with phase jitter, that averages 9600,
but is
sometimes faster, sometime slower might also exist.

Makes the idea of a Continuous BAUD test pattern generator interesting -
one that can
generate controlled errors on both sides of true, and with dithering.

Good student project

-jg

 

[GPG]

MAXIMUM error is .5 bit over one frame. In your case frame = 10 bits.
..5/10 = 5%

 

[Joel Kolstad]

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

 

[Allan Herriman]

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.

 

[rickman]

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

 

[rickman]

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

 

[rickman]

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?

I think I just understood what is wrong with my thinking. I was only
looking at one direction. The problem the OP has is that he is looping
back the received data and retransmitting it at the same slow(er) rate
the receiver is using. Since the transmitter must use a full 10 bits,
then the buffer between the receiver and transmitter will overflow at
some point.

This is a problem that is found in communications systems. All units
must run at the same rate, but may use a different reference. So if
they receive data at 8.0000 kHz and try to DAC it at 7.9999 kHz, about
once per ten seconds there will be a byte too many and a sample will
have to be dropped. This will cause a noticable click or other
distortion of the voice.

Some systems try to buffer this out, but that only postpones the
problem. Most systems use a common reference that is very accurate and
stable. Then the ADC and DAC clocks must be sync'd to the reference. I
worked on a system that used a bendable VCXO to establish the 8 kHz
rate. As the buffer data count varied from half full, the VCXO rate was
increased or decreased by small amounts to keep the average rates
matched.

In the case of the OP, the first channel can use two stop bits and the
echo channel can use one stop bit. This may not be pretty, but it will
work.

--

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]

Hi Rick et al.,

rickman <spamgoeshere4@yahoo.com> wrote:

Since the transmitter must use a full 10 bits,
then the buffer between the receiver and transmitter will overflow at
some point.

I'm glad someone else agrees with me! I think we'd all agree now, then,
that either you need an adjustable output clock or the part to transmit with
a shortened stop (or start) bit, which is effectively the same thing as
adjusting your output clock rate anyway.

This is a problem that is found in communications systems. All units
must run at the same rate, but may use a different reference.

Some systems try to buffer this out, but that only postpones the
problem. Most systems use a common reference that is very accurate and
stable.

....or they force the data to be encoded with its clock so that a PLL can
extract the exact frequency reference and work with that.

In the case of the OP, the first channel can use two stop bits and the
echo channel can use one stop bit. This may not be pretty, but it will
work.

It certainly will but the price is a reduction of ~10% of the average
throughput! Of course, that may be negligible depending on the system.

---Joel

 

[Jean Nicolle]

Hi all,



I've posted some code to do a UART last week on the fpga4fun site...

http://www.fpga4fun.com/SerialInterface.html



For the receiver, the bits are sampled in the middle - with the sampling
point configurable.

Also, the receiver starts checking for a "start" as soon as the "stop"
mid-point bit is detected, so that should be consistent with the
recommendations posted earlier.

Jean



"valentin tihomirov" <valentinNOMORESPAM@abelectron.com> wrote in message
news:bpum8f$1srj32$1@ID-212430.news.uni-berlin.de...

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.

I have developed a simple UART. It's receiver and transimtter run at 9600
bps with 16x oversampling. Both receiver and transmitter have 1-byte
buffer.
To test the design I've created an echo device; it merely mirrors all the
bytes sent to it back to the sender. It works fine with one of COM ports
on
my PC. Another COM port has its crystal running at a bit faster
fundamental
frequency. This causes a problem when it sends a long stream of bytes to
my
UART. In fact, sender and recepient cannot synchronize at falling edge of
start bit because one of them is slower and is processing a previous byte
wrile sender proceeds to next byte transmitting start bit. Despite of the
fact, my receiver still works fine beacuse it is ready to receive next
byte
right after a first half of stop bit is received. Just to clarify,
receiver
acquares values from serial input at the middle of each data bit slice; it
reports BYTE_READY in the middle of stop bit and from this moment is ready
to accept next byte, i.e. ready fror synchronization. Therefore, if data
is
coming slightly faster and falling edge of start bit is located within
stop
bit (according to my UART's clock) receiver is still capable not to
overlook
the data.
On the other hand, transmitter should transmit all 10 bits (start + 8 data
+
stop) @ 9600 bps. Consider for instance an UART forwarder or an echo
device.
If data is coming faster than I forward it I get a buffer overrun
ultimately. That is, receiver is ready with a byte in its buffer to be
copied into transmitter to forward but slow transmitter is still shifting
data out and its buffer is blocked.
I have a "fast" solution for my UART echo device; if transmitter has
transmitted > half of stop bit and sences that there is a next byte
received
it stops sending current stop bit and starts transmitting a start bit for
next byte. Untimely ceasing transmission is not good solution because
transmitter may be connected to a good matched or slightly slower running
UART. Design may be not a forwarder thus data provider may differ from
9600
bps receiver. In this case, starting early transmission of next byte while
remote peer is still receiving stop bit causes stop bit error.

What is interesting in this situation is the fact I can build a good echo
device from any industrial manufactured UART (I've used standalone 16c750
and ones built into i8051). They never have a buffer overrun issue despite
sending port is slightly faster than receiving (like sending data from my
fast COM port to slow one). Note, no flow control is used, buffers are
always 1-byte long. Which trick do they use? Again, 10% frequency
dereviations between sender and receiver are considered permittable and no
flow control is not required since sender and receiver both run at formal
9600bps.

I feel this should be a well-known problem (solution) and just wonder why
I
did not encounter this consideration before.

Thanks.

 

[glen herrmannsfeldt]

Jean Nicolle wrote:

I've posted some code to do a UART last week on the fpga4fun site...

http://www.fpga4fun.com/SerialInterface.html

For the receiver, the bits are sampled in the middle - with the sampling
point configurable.

Also, the receiver starts checking for a "start" as soon as the "stop"
mid-point bit is detected, so that should be consistent with the
recommendations posted earlier.

I finally found from another post that the OP was trying to build a loop
back device that would send back everything it received. Since it is
possible to receive a character in (about) 9.5 bit times, but it takes
10 to send it, (8N1), an unbuffered device could quickly lose data.

It seems that this is not one of the cases the protocol was designed to
handle. As far as I know, the popular full duplex with remote echo
would not have been considered when the protocols were defined.

Also, as far as I know both the popular XON/XOFF and RTS/CTS flow
control are relatively recent inventions. RTS/CTS is from the real half
duplex days, where only one side could transmit at a time.

Part of the asynchronous protocol is that both ends have their own clock.

For T1 and related protocols, one end synchronizes its clock to the
other, so that there is no speed matching problem.

For ethernet, the receiver synchronizes to the transmitter from clock
information in the data stream.

It should be possible to build a device with a UART and PLL to
synchronize the transmit clock to the incoming data rate. There should
probably be some buffer to last until the PLL locks.

-- glen

 

[Watson A.Name - "Watt Sun]

In article <bpum8f$1srj32$1@ID-212430.news.uni-berlin.de>,
valentinNOMORESPAM@abelectron.com mentioned...

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.

I have developed a simple UART. It's receiver and transimtter run at 9600
bps with 16x oversampling. Both receiver and transmitter have 1-byte buffer.
To test the design I've created an echo device; it merely mirrors all the
bytes sent to it back to the sender. It works fine with one of COM ports on
my PC. Another COM port has its crystal running at a bit faster fundamental
frequency. This causes a problem when it sends a long stream of bytes to my
UART. In fact, sender and recepient cannot synchronize at falling edge of
start bit because one of them is slower and is processing a previous byte
wrile sender proceeds to next byte transmitting start bit. Despite of the
fact, my receiver still works fine beacuse it is ready to receive next byte
right after a first half of stop bit is received. Just to clarify, receiver
acquares values from serial input at the middle of each data bit slice; it
reports BYTE_READY in the middle of stop bit and from this moment is ready
to accept next byte, i.e. ready fror synchronization. Therefore, if data is
coming slightly faster and falling edge of start bit is located within stop
bit (according to my UART's clock) receiver is still capable not to overlook
the data.
On the other hand, transmitter should transmit all 10 bits (start + 8 data +
stop) @ 9600 bps. Consider for instance an UART forwarder or an echo device.
If data is coming faster than I forward it I get a buffer overrun
ultimately. That is, receiver is ready with a byte in its buffer to be
copied into transmitter to forward but slow transmitter is still shifting
data out and its buffer is blocked.
I have a "fast" solution for my UART echo device; if transmitter has
transmitted > half of stop bit and sences that there is a next byte received
it stops sending current stop bit and starts transmitting a start bit for
next byte. Untimely ceasing transmission is not good solution because
transmitter may be connected to a good matched or slightly slower running
UART. Design may be not a forwarder thus data provider may differ from 9600
bps receiver. In this case, starting early transmission of next byte while
remote peer is still receiving stop bit causes stop bit error.

What is interesting in this situation is the fact I can build a good echo
device from any industrial manufactured UART (I've used standalone 16c750
and ones built into i8051). They never have a buffer overrun issue despite
sending port is slightly faster than receiving (like sending data from my
fast COM port to slow one). Note, no flow control is used, buffers are
always 1-byte long. Which trick do they use? Again, 10% frequency
dereviations between sender and receiver are considered permittable and no
flow control is not required since sender and receiver both run at formal
9600bps.

I feel this should be a well-known problem (solution) and just wonder why I
did not encounter this consideration before.

Thanks.

UARTs are almost always crystal controlled, so the tolerance is less
than 1 percent, and there shouldn't be a problem with this. When a
serial data stream is run through a multiplexer, where the sampling
rate is less than 10x per bit, then you might see such large
deviations ("dereviations").


--
@@F@r@o@m@@O@r@a@n@g@e@@C@o@u@n@t@y@,@@C@a@l@,@@w@h@e@r@e@@
###Got a Question about ELECTRONICS? Check HERE First:###
http://users.pandora.be/educypedia/electronics/databank.htm
My email address is whitelisted. *All* email sent to it
goes directly to the trash unless you add NOSPAM in the
Subject: line with other stuff. alondra101 <at> hotmail.com
Don't be ripped off by the big book dealers. Go to the URL
that will give you a choice and save you money(up to half).
http://www.everybookstore.com You'll be glad you did!
Just when you thought you had all this figured out, the gov't
changed it: http://physics.nist.gov/cuu/Units/binary.html
@@t@h@e@@a@f@f@l@u@e@n@t@@m@e@e@t@@t@h@e@@E@f@f@l@u@e@n@t@@

 

[valentin tihomirov]

Error accumulates. 1% means that receiver accepts 9.9bit long farmes while
transmitter transmits 10.0 bit-long frames. After re-transmitting 100 bytes
(frames) we get 10-bit error. 10 bit is one byte, so 1-byte buffer is not
enaught. The longer the stream the lager the buffer required. Infinite
buffer is required for continous stream. As masters stated, UART was not
designed for this purpose.

 

[Jim Granville]

"valentin tihomirov"

Error accumulates. 1% means that receiver accepts 9.9bit long farmes while
transmitter transmits 10.0 bit-long frames. After re-transmitting 100
bytes
(frames) we get 10-bit error. 10 bit is one byte, so 1-byte buffer is not
enaught. The longer the stream the lager the buffer required. Infinite
buffer is required for continous stream. As masters stated, UART was not
designed for this purpose.

Some UARTs are designed for this purpose
- look at the data for Philips 26C94 families, and esp. the
area of Sending fractional stop bits.
-jg

 

[Simon Peacock]

you guys seem to miss the point.. Async RS232 ALWAYS has mismatched clocks
.... ALL async UARTs MUST be capable of handling this.. that's why there's
flow control.

You will find that 99.9% of them start looking for the start bit 1/2 way
thru the stop bit. If you want to build a repeater then you will need a
fractional stop bit generator OR you can over spec the crystal by 1.5% (or
the baud rate generator) OR you add RTS / CTS flow control like everybody
else.

Simon

"valentin tihomirov" <valentinNOSPAM@abelectron.com> wrote in message
news:bqd493$1ter3o$1@ID-212430.news.uni-berlin.de...

Error accumulates. 1% means that receiver accepts 9.9bit long farmes while
transmitter transmits 10.0 bit-long frames. After re-transmitting 100
bytes
(frames) we get 10-bit error. 10 bit is one byte, so 1-byte buffer is not
enaught. The longer the stream the lager the buffer required. Infinite
buffer is required for continous stream. As masters stated, UART was not
designed for this purpose.

 

[Joel Kolstad]

Simon Peacock <nowhere@to.be.found> wrote:

you guys seem to miss the point.. Async RS232 ALWAYS has mismatched clocks
... ALL async UARTs MUST be capable of handling this.. that's why there's
flow control.

There are a lot of systems in the world that don't use flow control and
simply rely on a 'mutual agreement' between the interconnected devices that
large streams of unbroken serial data isn't produced. This is especially
the case of, e.g., sensors that produce real-time RS-232 output data with no
buffering of their own -- in such a case flow control would just throw data
away, so it's often not implemented to begin with. (I have a motto
something to the effect of... if detecting an error does no more good than
just ignoring it, you might as well ignore it... Although unfortunately this
idea is often perverted into, 'if detecting an error takes effort, even if
ignoring it causes the machine to rip off someone's arm, you might as well
ignore it because otherwise the customer will immediately be able to pin the
blame on you rather than having to guess whose fault it is.' :-( )

You will find that 99.9% of them start looking for the start bit 1/2 way
thru the stop bit. If you want to build a repeater then you will need a
fractional stop bit generator OR you can over spec the crystal by 1.5%
(or the baud rate generator) OR you add RTS / CTS flow control like
everybody else.

1 -- The fractional stop bit generator is a good idea, and is apparently
implemented in -- some -- commercial devices. This was news to me, but it
does seem to be a very good solution.
2 -- Overclocking by 1.5% strikes me as a poor idea because the 'solution'
is inherently non-scalable -- I can't connect together a dozen of these
repeaters unless each one is progressively 1.5% faster, which isn't viable.
3 -- I'd agree that flow control is the 'proper' or 'textbook' solution,
just that the real world doesn't always play by those rules.

---Joel Kolstad