Re: Slightly unmatched UART frequencies

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

---Joel Kolstad