Slightly unmatched UART frequencies

[Simon Peacock]

"Joel Kolstad" <JKolstad71HatesSpam@Yahoo.Com> wrote in message
news:bqeqiq$654$1@news.oregonstate.edu...

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.

Actually you can

Data is only sent at the speed it arrives at.. so although you are 1.5%
fast.. you actually end up adding extra stop bits into the stream to
compensate .. is simple and oh so clever. This is exactly what modems did
for years to cope with the V.14 shaved bits when they couldn't do them.


Simon

 

[Joel Kolstad]

HI Simon,

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

Data is only sent at the speed it arrives at.. so although you are 1.5%
fast.. you actually end up adding extra stop bits into the stream to
compensate .. is simple and oh so clever.

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!

This is exactly what modems did
for years to cope with the V.14 shaved bits when they couldn't do them.

Interesting; I didn't know that either!

---Joel

 

[Simon Peacock]

"Joel Kolstad" <JKolstad71HatesSpam@Yahoo.Com> wrote in message
news:bqhflk$3nr$1@news.oregonstate.edu...

HI Simon,

Simon Peacock <nowhere@to.be.found> wrote:
Data is only sent at the speed it arrives at.. so although you are 1.5%
fast.. you actually end up adding extra stop bits into the stream to
compensate .. is simple and oh so clever.

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!

This is exactly what modems did
for years to cope with the V.14 shaved bits when they couldn't do them.

Interesting; I didn't know that either!

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

 

[Eric Smith]

"Joel Kolstad" <JKolstad71HatesSpam@Yahoo.Com> writes:

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.

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

There's no way around this

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

Nothing wrong with 16x oversampling (it will definitely help -- a little),

It helps a lot, if you do it right.

 

[Eric Smith]

"Joel Kolstad" <JKolstad71HatesSpam@Yahoo.Com> writes:

Unless your (slightly slower) transmitter also has the capability of
producing shortened start (or stop) bits,

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.

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, if the receiver works correctly this should be maintainable indefinitely
(provided there's nothing else in the receiving device that overflows).

 

[Allan Herriman]

On 04 Dec 2003 19:16:35 -0800, Eric Smith
<eric-no-spam-for-me@brouhaha.com> wrote:

"Joel Kolstad" <JKolstad71HatesSpam@Yahoo.Com> writes:
Unless your (slightly slower) transmitter also has the capability of
producing shortened start (or stop) bits,

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

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.

 

[Joel Kolstad]

Eric Smith <eric-no-spam-for-me@brouhaha.com> wrote:

"Joel Kolstad" <JKolstad71HatesSpam@Yahoo.Com> writes:
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.

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

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.

Nothing wrong with 16x oversampling (it will definitely help -- a
little),

It helps a lot, if you do it right.

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

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

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