Re: Slightly unmatched UART frequencies

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" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> 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.
>
>
>