Slightly unmatched UART frequencies

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.

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

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

right.

Sorry.

following:

The extra stop bit gives you about 9% margin, the difference between

9600 and 9700 is about 1%

I agree. More exactly, Left's RX is faster than Right's TX.

The examples I gave in my prior post help with unidirectional messages between a faster transmitter and a slower receiver, and assume the system at the slower receiver can process the received character in the local clock domain in 10 bit times. But if you retransmit the character with 2 stop bits in the slower clock domain, that takes 11 bit times, and the system will fail. So retransmitting with 11 bits throws away the advantage of the RX using 1 stop bit and the far end TX using 2 stop bits.

If you knew which system had the slower clock, you could set its transmitter for 1 stop bit and then the system would work. Unfortunately this is not normally possible.

This is not what I intended. I am assuming that the number of stop bits is fixed, and is dependent on which end has the faster clock.

Try this:

Left side: Slow (9600 Baud) RX: 1 + 8 + 1 TX: 1 + 8 + 1

Right side: Fast (9700 Baud) RX: 1 + 8 + 1 TX: 1 + 8 + 2

I believe you can send stuff continuously all day this way without over-run, in both directions. Only problem is that you need to know which end has the faster clock.

You could figur this out by running both TX at 1+8+1 and see which RX has over-run errors first, then adjust the other end's TX. Not pretty, but could be made to work. Maybe OK for a 1 off project, but not for production.

I agree. hence the need for flow control.

Philip

Philip Freidin Fliptronics

Hi all,

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

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

buffer.

on

fundamental

my

byte

receiver

is

stop

overlook

+

device.

received

9600 I

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

In article , snipped-for-privacy@abelectron.com mentioned...

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  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@@

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.

"valentin tihomirov"

bytes

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

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

bytes

Well, fair enough, if you KNOW that your data source is truly supposed to be 'nominally,' say, 9600bps, then you can be clever and get away with an internal nominal bit rate of 9600*1.015=9744bps. However, if you tell me you have such a device that you'd like to connect to one of my devices, you'd better be able to convince me there really is no way your device could start spewing data continuously at 9744 bps when my 9600 bps receiver isn't going to be able to hack it!

Interesting; I didn't know that either!

---Joel

be

could

isn't

if you start looking for a start bit 1/2 way thru the stop .. no problems :-)

Since modems often use embedded processors.. which don't do fractional stop.. you have to do something.. so they mostly fudge it. Rockwell, Intel, silicon systems.. all have done it.. maybe even still do.. wouldn't surprise me if they did.. the first Rockwell 33k6 modems just used a fast version of their 2400 processors.. 6802 or something like that

Simon

No, that will work just fine. When a real UART is set for one stop bit, it actually only needs just over 1/2 a stop bit (usually 9/16).

Certainly there are ways around it. Read ITU Rec. V.14.

It helps a lot, if you do it right.

An async transmitter should NEVER produce shortened start or stop bits!

It is the RECEIVER that should handle short stop bits, in order to deal with the exact sort of speed mismatch you're talking about.

No, if the receiver works correctly this should be maintainable indefinitely (provided there's nothing else in the receiving device that overflows).

cutting the stop bit in order to achieve a higher transmission rate.

If it's completely wrong, why did the ITU standardize it in the V.14 standard?

Admittedly shaving stop bits should only be used in certain limited circumstances. It is not intended to deal with sending data to a receiver that is running slightly slower than the transmitter. Rather, it is used when converting slightly overspeed data from a synchronous modem modulation to async (when no error control protocol like V.42 is in use).

Only a small number of commercially produced UARTs, such as the NEC uPD7201, fail to work correctly with slightly short stop bits. This problem was commonly seen on the AT&T 7300 Unix PC in the late 1980s.

Actually they usually start looking for a start transition 9/16 of the way into the previous stop bit. Some UARTs with noise detection sample the RX input at 7/16, 8/16, and 9/16 of the bit time, so those might not start looking for a start bit until 10/16 of the way into the previous stop bit.

Yes, with rare exceptions such as the NEC uPD7201, which actually requires a full stop bit on receive.

Some [well engineered] systems will not work in all cases unless they are able to use shortened stop bits.

I refer you to ITU-T recommendations V.110 and V.14. (You could argue that they aren't 'async', but still...)

Regards, Allan.

If you read further into the thread, you'll see that the 'problem' is that while, sure, you can receive all the characters coming in at 9600.01 bps correctly, if you're then only going to re-transmit them (a data buffer-type device) at 9600 bps, sooner or later you run out of storage for all the accumulating bits. That's what my 'there's no way around this' comment meant. In the interim, people have suggested lots of clever techiques to deal with mismatched frequencies.

I'll buy that I suppose -- I've done just fine with 1x or 3x sampling with software-based UARTs, but the mere fact that they were software-based meant that they were only at, e.g., 9600bps or less and they happened to be over short distances. I.e., the data signals were always 'nice and clean.'

Perhaps you should tell that to all the guys out there who've designed UARTs that do just that? Keep reading the thread -- if data comes into a data forwarder at 9600.01 bps, you have to 'effectively' re-transmit at

9600.01bps as well. You can do that by using a slightly faster clocking frequency and/or slightly shortening your data bits -- your choice.

---Joel Kolstad