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

  • Next message: Guy Macon: "Hydra: a FPGA-based chess computer" 
    Date: Mon, 16 Aug 2004 09:32:41 +0200

    "Doug Dotson" <dougdotson@NOSPAMcablespeed.NOSPAMcom> wrote in message
    news:u9adnR6BVMpmtr3cRVn-hw@cablespeedmd.com...
    > COmments below.
    > Doug
    >
    > "Neil Bradley" <nb_no_spam@synthcom.com> wrote in message
    > news:10i09iglmsfuv62@corp.supernews.com...
    > > "Casey" <cclremovethispart@cox.net> wrote in message
    > > news:JoUTc.21115$pT5.3217@lakeread05...
    > > > Neil Bradley said...
    > > >> "Doug Dotson" <dougdotson@NOSPAMcablespeed.NOSPAMcom> wrote in
    message
    > > >> Nope, I understand the concept perfectly. When using a UART, it's
    > > >> required
    > > >> that both sides of the serial transmission be synchronized.
    > > > Both sides are NOT synchronized - that's the essence of async
    > > > communications.
    > >
    > > They are for the duration of the byte being transmitted. That's what the
    > > start bits are for - to synchronize both ends for the duration of the
    > byte!
    >
    > Correct. But that does not make it synchronous communications. The fact
    > that the difference in tx and rx clock is a factor makes it async.
    >

    The sender and the receiver in uart communications are *never* synchronized.
    We are not talking about the general usage of a common word here (as in
    "let's synchronize our watches") - the term "synchronous" has a very
    specific meaning in the world of electronics, especially for communications.
    It means there is a shared clock. Two devices can't be "synchronized for a
    while" (unless you are swiching the clock signal on and off, etc.). They
    can't be "closely synchronized" - they are either synchronized, or not.

    When a uart receiver notices a start bit, it does not become synchronized to
    the sender - it synchronizes its state machine (using its single internal
    clock) to the start bit as sampled by its own clock. This is going to
    happen at roughly the same time as the sender transmits the start bit, but
    not exactly - it depends on transmission delays, over-sampling rates at the
    receiver, and so on. I.e., the sender and receiever are not synchronized.

    > > >> If you don't
    > > >> believe me, try using a crystal at a low baud rate with a 20%
    > tolerance.
    > > > No, but the two ends can use clocks that are 5% off from each other
    and
    > > > still communicate successfully.
    > >
    > > It depends upon the baud rate. The lower the baud rate the more
    > susceptible
    > > it is to being
    >
    > Correct. All properties of async coms.
    >

    This is a myth - a commonly believed myth, but a myth nonetheless. There
    are definitely factors that make serial communication harder at higher
    speeds, such as rounded edges, noise, cross-talk, etc., and closer clock
    matching might help marginally, but the main effect of the clock speed
    matching is a relative effect - a 5% error means a 50% *bit time* error
    after 10 bits, regardless of the length of a bit time.

    Think about the sort of speeds async communication runs at. Suppose we say
    5% is required for 9600 baud. Does that mean we can run 600 baud at 40%
    error? Or do we need 0.005% to run Profibus at 12 MBit? To say nothing of
    the 0.5 ppm accuracy crystals needed for gigabit ethernet...

    It reminds me somewhat of when my father was once buying beer at an
    off-license. They were having a special offer of 5% discount for a crate of
    12 bottles. On seeing this, my father said he would get two crates, and the
    shop assistant gave him 5% off for the first crate, then another 5% off for
    the second crate, giving him a 10% discount altogether. He was tempted to
    buy more, but didn't want to push his luck...

    > > >> 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.
    > > > Incorrect.
    >
    > NO, they are not syncronized. THat is why the drift of sampling points
    > becomes
    > a problem.
    >
    > > Completely correct. Like I said, FOR THE PERIOD OF THE BYTE transmission
    > > they need to be synchronized (or closely enough in time with eachother)
    in
    > > order to receive the byte successfully.
    >
    > No, the drift has to be within acceptable bounds. That is not the same as
    > being
    > synchronized.
    >
    > > >> 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?
    >
    > The fact that the tx and rx ends are using the same clock is the
    definition
    > of
    > synchronous coms.
    >
    > > > The clock can't vary - the two ends have to use the same
    > > > "synchronized" clock.
    > >
    > > Well, we're mincing words. I'm not saying that a UART is synchronous.
    I'm
    > > saying that for the duration of the byte being transmitted, they need to
    > be,
    > > for all intents and purposes, synchronized, or damned close to it.
    >
    > No, by defintion they are not. They just have to have the clock error
    > between
    > tx and rx within limits. This is not synchronized If it were, then once
    the
    > start
    > bit was detected then any difference between tx and rx wouldn;t matter
    since
    > they would be "synchronized". This is not the case with async comms.
    >
    > > -->Neil
    > >
    > >
    >
    >

  • Next message: Guy Macon: "Hydra: a FPGA-based chess computer"

    Relevant Pages

    • Re: Why should I (not) use an internal oscillator for 8-bit micros
      ... >> that both sides of the serial transmission be synchronized. ... try using a crystal at a low baud rate with a 20% tolerance. ... >clock, so each side uses its own time reference to clock the transfers. ... >are not joined directly to synchronize their clocks, ...
      (comp.arch.embedded)
    • Re: "The Observational Collapse of Einsteinian Physics"
      ... > |> You are still not fooling anyone, ... > | If at the point A of space there is a clock, ... Clocks do not synchronize without infinite time. ... Whoever gave you the idea that *I* was the peer in ...
      (sci.physics)
    • Re: Getting NTP to correct only the clock skew
      ... to synchronize B's clock to the source of your CBR data. ... The data stream is provided by a PCI board connected to A. The jitter between the board and A is small enough to be negligible. ... at least the maximum network latency, the packets out of B will have the ... same timing relationship as those out of A, subject only to clock errors. ...
      (comp.protocols.time.ntp)
    • Re: definition of simultaneity and on the relativity of lenghts and times by a. einstein
      ... > Let us take a system of co-ordinates in which the equations of Newtonian ... > If at the point A of space there is a clock, an observer at A can determine ... the clocks at B and C also synchronize with each other. ... > stationary system, and the time now defined being appropriate to the ...
      (sci.physics.relativity)
    • definition of simultaneity and on the relativity of lenghts and times by a. einstein
      ... Let us take a system of co-ordinates in which the equations of Newtonian ... If at the point A of space there is a clock, an observer at A can determine ... the clocks at B and C also synchronize with each other. ... stationary system, and the time now defined being appropriate to the ...
      (sci.physics.relativity)