Re: Slightly unmatched UART frequencies

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