Re: Why should I (not) use an internal oscillator for 8-bit micros

From: David Brown (david_at_no.westcontrol.spam.com)
Date: 08/16/04 

Date: Mon, 16 Aug 2004 13:06:48 +0200

"Alan" <me@somewhere.com.au> wrote in message
news:vmo0i0do3b73veve4ojrrrmt7lh8udae6d@4ax.com...
> On Mon, 16 Aug 2004 09:08:13 +0200, "David Brown"
> <david@no.westcontrol.spam.com> wrote:
>
> >
> >"Neil Bradley" <nb_no_spam@synthcom.com> wrote in message
> >news:10hvv8scv52i489@corp.supernews.com...
> >> "Doug Dotson" <dougdotson@NOSPAMcablespeed.NOSPAMcom> wrote in message
> >> news:ismdnTKuDKd_T4LcRVn-hQ@cablespeedmd.com...
> >> >I believe that UART stands for "Universal ASYNCRONOUS Receiver
> >> > Transmitter". You need to go back and study the difference between
> >> > sync and async.
> >>
> >> Nope, I understand the concept perfectly. When using a UART, it's
required
> >> that both sides of the serial transmission be synchronized. If you
don't
> >> believe me, try using a crystal at a low baud rate with a 20%
tolerance.
> >> Devices won't be able to talk to it. When the byte comes is the
> >asynchronous
> >> part, and that wasn't even the topic being discussed.
> >>
> >
> >The phrase "when you are in a hole, stop digging" springs to mind...
> >
> >In the context of serial communications, "synchronous" means there is a
> >clock line (or an "embedded clock" in the data signal) going between the
> >sender and receiver, while "asynchronous" means there is no directly
shared
> >clock, so each side uses its own time reference to clock the transfers.
A
> >"clock" signal does not have to be regular - for synchronous transfers,
it
> >can vary as much as you want. For asynchronous transfers, you normally
have
> >a regular clock - while you could theoreticly have a varying one, it
would
> >be a challange to implement reliably. But if the clocks on the two sides
> >are not joined directly to synchronize their clocks, they are not
> >synchronous - it doesn't matter if their speeds match at 0.00001%
accuracy.
> >
> >For standard uart asynchronous communication, the limit for communication
> >over a good line (noise-free, and nice sharp edges) is a 5% match between
> >sender and receiver, so that by the 10th bit they are no more than 50% of
a
> >bit in difference. Normally, that means ensuring that each side is
within
> >2.5% of the nominal baud rate. The absolute baud rate does not matter.
> >
> >
> >
> >
> >
> >> The question was in reference to the baud rate generating clock, not
when
> >> the data comes in. For the period of the byte transmission, both sides
> >must
> >> be synchronized. There is no common clock between them. If you have
> >separate
> >> clock and data lines, the clock can vary wildly with no adverse effect
on
> >> communication. No synchronization between devices needed. Is this a
hard
> >> concept to grasp?
> >>
> >> You do know that the words synchronous and asynchronous can mean
different
> >> things depending on the context, right?
> >>
> >> -->Neil
> >>
> >>
> >
> It's no wonder that there are so many framing errors on Async comms
> when some people don't understand the basic concepts of Async and
> Sync comms.
>
> Sync transmits the clock either directly (on a clock line) or
> indirectly (embedded in the data) so that the receiver know when to
> look at the data bits.
>
> Async uses the "start" bit of each byte to tell the receiver to start
> timing to look at the bits of this one byte only.
>
> The term Asynchronous here means that the sender can send data at
> anytime without having to worry about whether or not the receiver is
> in sync.
>

Not quite - the term "asynchronous" here means "not synchronous" - i.e., the
opposite of your correct definition of "synchronous". The receiver is
*never* in sync with the sender in async communication, since it does not
have a clock signal on which to sychronize.

> How many designers try to send or receive at say 5% tolerance instead
> of aiming for as close to 0% as possible. Makes for interesting
> interfacing when one unit is 5% high and the other 5% low because
> they've been designed by "prima donnas" who know better than the rest
> of the world.
>

5% tolerance is for the *total* error. Normally that means that you need to
be within 2.5% at each end, unless you happen to know for sure that one end
will be much tighter tolerance. Of course, only a fool would aim for
something that is only just within the theoretical limit of what was
possible! A realisitic rule of thumb would be to aim for 1% match - any
crystal or ceramic oscillator will do, but an internal oscillator or an R-C
oscillator would need trimming.

> As for crystal versus baud rate tolerances - if the crystal is 1% low
> then the baud rate is 1% low. Simple as that - always allowing for the
> fact that you are using the "correct" frequency crystal to start with
> and allowing for any division errors in the baud rate generator/clock.
>

That is, of course, correct - I'm slightly stunned that there are people
working in this field who apparently fail to grasp that. Hopefullly,
"apparently" is the operative word, and that it is merely the wording of
their posts that is ambiguous, rather than their understanding.

>
> Alan
>
> ++++++++++++++++++++++++++++++++++++++++++
> Jenal Communications
> Manufacturers and Suppliers of HF Selcall
> P O Box 1108, Morley, WA, 6943
> Tel: +61 8 9370 5533 Fax +61 8 9467 6146
> Web Site: http://www.jenal.com
> e-mail: http://www.jenal.com/?p=1
> ++++++++++++++++++++++++++++++++++++++++++

Relevant Pages

  • Re: AMD to integrate PCIe into CPU
    ... HyperTransport Technology eliminates the problems associated with high speed parallel buses with their many noisy bus signals while providing scalable ... HT sends 1 to 32 bits in parallel accompanied by a clock for every 8 bits which is used to latch all the bits on the receiving chip and a framing signal used to mark the start of 4 byte words and distinguish data from commands. ... No alignment of the clock and data is performed so all of the jitter and skew and timing tolerance must be accomodated by the width of the data bit. ...
    (comp.sys.ibm.pc.hardware.chips)
  • Re: How accurate/tolerant is the PIC USART clock rate?
    ... samples the line every 16 clock times, resulting in a sample at the ... is received, again at nominal middle of a bit period, the complete ... Draw a few timing diagrams showing start detection delay and clock ... tolerance effects and all will rapidly be clear. ...
    (comp.arch.embedded)
  • Re: How accurate/tolerant is the PIC USART clock rate?
    ... samples the line every 16 clock times, resulting in a sample at the ... The little quote from the data sheet says majority of three samples, ... tolerance effects and all will rapidly be clear. ... I'm looking at a spec that always sends a Break (more 0's than a legal ...
    (comp.arch.embedded)
  • Re: How accurate/tolerant is the PIC USART clock rate?
    ... samples the line every 16 clock times, resulting in a sample at the ... is received, again at nominal middle of a bit period, the complete ... The little quote from the data sheet says majority of three samples, ... tolerance effects and all will rapidly be clear. ...
    (comp.arch.embedded)
  • Re: Error Code 13: Guide Info Will Not Download
    ... austin, tx ... Also I had the time sync issue resolved yesterday, ... The internet connection and firewall can be ruled out as suspects. ... internet connectivity and system clock can be ...
    (microsoft.public.windows.mediacenter)