Re: Slightly unmatched UART frequencies

"Joel Kolstad" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Simon Peacock <[EMAIL PROTECTED]> 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