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

"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 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 

I believe you, but this is not synchronous communications. You are correct
that
synchronous and asynchonous do have meanings depending upon
the context. However, when talking about data communications the meaings
are well understood and widely accepted standards. Nuff said!

Doug

"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 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
>
>

Neil Bradley wrote:

> "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 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?

Perhaps, but there is an industry accepted usage, which is clear if you 
read (as an example)
http://www.ti.com/sc04160
and
http://focus.ti.com/lit/ds/symlink/tl16c550d.pdf

  I think everyone agrees that UARTS can tolerate only a limited 
clock-miss-match, for correct communication.

  The exact frequency skew that can be tolerated depends on if you apply 
it to both ends, or only one, and what margin is considered acceptable.

-jg

Neil Bradley <nb_no_spam@synthcom.com> wrote in message
news:10hvisv6ucimkf3@corp.supernews.com...
> "CBFalconer" <cbfalconer@yahoo.com> wrote in message
> news:411FC1AD.91751819@yahoo.com...
> > Neil Bradley wrote:
> >> "CBFalconer" <cbfalconer@yahoo.com> wrote in message
> >>> Neil Bradley wrote:
> >>>> "Schwob" <schwobus@aol.com> wrote in message
> >>>>> It is my understanding that a synchronous interface such as SPI
> >>>>> or I2C should work without problems even if the transmition rate
> >>>> Correct. Asynchronous protocols don't matter much (if at all).
> >>> ITYM synchronous.
> >> No, I meant asynchronous, where things like I2C and SPI have
> >> separate clock and data lines. The clock lines can vary wildly
> > No, you do mean synchronous.
>
> No, I meant synchronous. I'm referring to the period of time when the byte
> itself is transferred. During byte transmission, a UART requires both ends
> to be completely synchronous. Of course the positions of when those bytes
> come is completely asynchronous. In a clock/data driven environment like
> I2C, you can clock at a completely irregular rate during the byte and it
> won't matter. You can't do that with a UART.
>
> -->Neil

No, here (as applied to a usart) asynchronous means that the data can be
sent at any time as opposed to synchronous where data is sent all the time.
Many USART (UART) have both synchronous and asynchronous modes. In
synchronous mode the usart normally sends sync bytes when it has no data to
send, and does not send a start and stop bit. The usart really does send
only 8 bits per byte. In asynchronous mode the line is quite until there is
data to send, then the usart sends a start bit to signal that data is about
to be sent, the data and finally a stop bit. The edge that signals the start
of the start bit is used to start a timer that causes bits to be sampled
near or just after the middle of the bit period. The edge is not used as a
clock signal (think about send two zeros, there is not transition between
them). Bits are sampled near the middle of the bit rather than the start to
overcome signal propagation problems. A good usart will sample the bit 3 or
more times and use a majority vote for the actual bit value.

Synchronous as applied to I2C and SPI refers to the data being sampled
relative to a separate clock.

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler

Neil Bradley said...
> "Doug Dotson" <dougdotson@NOSPAMcablespeed.NOSPAMcom> wrote in message 
> > 
> >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. 

Both sides are NOT synchronized - that's the essence of async 
communications.  The clocks at the transmitter and receiver ends are 
not exactly the same.  They just have to be close enough to sample the 
pulses correctly.  

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

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

> There is no common clock between them. 

Correct.

> 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 clock can't vary - the two ends have to use the same 
"synchronized" clock.  
 
> You do know that the words synchronous and asynchronous can mean different 
> things depending on the context, right?

You're using the terms exactly backwards.  If you insist on using the 
terms incorrectly, you'll be unable to communicate with anyone else.

www.inetdaemon.com/tutorials/theory/basics/asynchronous_synchronous.htm



Casey

"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!

>> 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

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

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.

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

-->Neil 

"Doug Dotson" <dougdotson@NOSPAMcablespeed.NOSPAMcom> wrote in message 
news:otednWpGDrpYn73cRVn-gQ@cablespeedmd.com...
>I believe you, but this is not synchronous communications.

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

-->Neil 

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.

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

> >> 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
>
>

"Doug Dotson" <dougdotson@NOSPAMcablespeed.NOSPAMcom> wrote in message 
news:u9adnR6BVMpmtr3cRVn-hw@cablespeedmd.com...
>> 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
>> for all intents and purposes, synchronized, or damned close to it.
> No, by defintion they are not.

Depends on the definition you're using (from www.dictionary.com):

1. To occur at the same time, be simultaneous
2. To operate in unison

For all intents and purposes, both sides are "in time" with eachother. One 
is not *SLAVED* to the other, however (as in with synchronous 
communication). Now how you define "same time" and "simultaneous" of course 
is open to discussion, but the clocks had better be damned close.

> tx and rx within limits. This is not synchronized If it were, then once 
> the
> 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.

I think we're splitting hairs, here. Even clocked/slaved devices aren't 100% 
synchronized, either. ;-) It all depends upon where you want to draw the 
line, but you'd agree that the baud clocks on both sides need to be close or 
damned close to eachother (by how much obviously depends upon the baud rate 
in question).

-->Neil 

Neil Bradley wrote:
> "Doug Dotson" <dougdotson@NOSPAMcablespeed.NOSPAMcom> wrote in message 
> news:otednWpGDrpYn73cRVn-gQ@cablespeedmd.com...
> 
>>I believe you, but this is not synchronous communications.
> 
> 
> 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.

> 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 ?

-jg