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

From: Neil Bradley (nb_no_spam_at_synthcom.com)
Date: 08/16/04 

Date: Sun, 15 Aug 2004 23:39:50 -0700

"Jim Granville" <no.spam@designtools.co.nz> wrote in message
news:6CXTc.3400$zS6.403349@news02.tsnz.net...
>> I never said it was. The whole point which everyone continues to ignore
>> is that if you have baud clocks between two devices, they need to be
>> pretty damned close in terms of tolerance (my experience says 1% across
>> the board if you want to be compatible with everyone), otherwise the
>> synchronous
> "pretty damned close" is a rather loose argument for "synchronous".
> If you replace your meaning of "synchronous" with everyone else's meaning
> of "sampling", the the logic follows better.

Well, of course we all have slightly different definitions of what words
mean. Someone else's "sloppy timing" is someone else's "tight timing". So,
to be a bit more specific:

1% of 2400bps = 2378-2423bps
1% of 9600bps = 9505-9695bps
1% of 115200bps = 114049-116351bps

So I'd say that 1% is "pretty damned close" in this case. ;-)

It's also fair to say that "we've synchronized our watches". Of course it's
not synchronized down to the millisecond. That's all I was saying. For that
brief moment in time when a byte is transferred, both ends are operating
independently but are synchronized, not locked together.

>> aspect (the data bits between the start and stop bits) of the
>> asynchronous communication will most likely not work correctly, with a
>> decreasing chance they'll work the lower the baud rate goes.
> OK, I'll bite : Why/how does the absolute baud rate affect the % of clock
> skew that can be tolerated ?
> If the data frame size is constant.unchanged, then the sampling time skew
> that can be tolerated is a fixed percentage of that time ?

I'm having a tough time explaining it in a fashion that will be globally
understandable, but here goes. The short answer is that the errors are
cumulative.

Both devices start their respective internal baud clocking at the rising or
falling edge of the start bit. That is a point where the "synchronization"
(hehehehe) occurs. Most UARTs run off some sort of timer/counter/divisor
arrangement, as does the 16550 or even the 8051. The standard clock chip
feeding a PC's 16550 (or equivalent thereof these days) is fed by a
1.8432Mhz part. There is a /16 prescaler in the 16550, followed by a
programmable baud rate divisor beyond that. So, 1.8432Mhz/16=115200bps
internal clock (that will help minimize jitter).

Let's divide it down even further - 2400bps. That'd be a divisor of 48
(115200/48=2400). That assumes a perfectly divisable clock. For the sake of
argument, let's turn that in to a 2Mhz crystal (roughly 8% difference from
the 1.8432Mhz clock). Let's say that the sender is using a 2Mhz crystal and
the receiver is using a 1.8432Mhz crystal - both with a divisor of 1, each
aiming for 115200bps.

The 2Mhz fed 16550 will yield 12500bps and the 1.8432Mhz fed 16550 will
yield 115200bps. At that rate, there's 1.08506944 hz of the sender for every
1Hz of the receiver. Mulitply that out 8 bits and you're at 8.680555552
cycles on the sender and 8 on the receiver, roughly a 7% error after 8 bits,
but still within the realm of possibility in terms of sampling since the
sender hasn't blasted past the receiver by more than 1Hz.

Okay, now let's take that down to 2400bps. 2Mhz fed 16550 yields 2604bps.
1.8432Mhz receiver yields exactly 2400bps. Remember we have a divisor of 48
to get 2400bps, so we need to multiply everything by 48, so 1.08506944 * 48
= 52.083333312Hz vs 48Hz - you're off by over 4Hz, so anything past the
first 4 bits of data are guaranteed to be sampled at the wrong time, ending
up in incorrect data.

Okay, my head hurts now. ;-) I wound up running against this with a really
poor crystal on a prototype 8051 weather station controller. I had already
used the serial port for PC communications, so I had to do an interrupt
driven/bit banged UART using INT0 (if you want the code I'll post it). I had
a windspeed/direction PIC I was interfacing with that had a 20% tolerance on
the internal clock. It communicated @ 1200baud, so my opportunity for
sampling was smaller than a reasonable crystal.

-->Neil

Relevant Pages

  • Re: newbie question about synchronization
    ... frankly I don't also have any plans for synchronization of Tx and Rx ... RF carrier and the sampling clocks, ... sampling clock offset estimation and compensation ... If you do a google search for "digital receiver ...
    (comp.dsp)
  • Re: Info needed on Spectracom 8171A clock... Help
    ... >> I have a Spectracom 8171A WWVB Synchronized clock. ... > * WWVB clocks have proven vulnerable to high ambient conductive RF ... > * during initial synchronization and when received signal is lost for ... instead it is inputed via a WWVB receiver. ...
    (sci.electronics.repair)
  • Re: Info needed on Spectracom 8171A clock... Help
    ... >> I have a Spectracom 8171A WWVB Synchronized clock. ... > * WWVB clocks have proven vulnerable to high ambient conductive RF ... > * during initial synchronization and when received signal is lost for ... instead it is inputed via a WWVB receiver. ...
    (sci.electronics.equipment)
  • Re: Info needed on Spectracom 8171A clock... Help
    ... >> I have a Spectracom 8171A WWVB Synchronized clock. ... > * WWVB clocks have proven vulnerable to high ambient conductive RF ... > * during initial synchronization and when received signal is lost for ... instead it is inputed via a WWVB receiver. ...
    (sci.electronics.design)
  • Re: Info needed on Spectracom 8171A clock... Help
    ... >> I have a Spectracom 8171A WWVB Synchronized clock. ... > * WWVB clocks have proven vulnerable to high ambient conductive RF ... > * during initial synchronization and when received signal is lost for ... instead it is inputed via a WWVB receiver. ...
    (sci.electronics.misc)