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

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi,

for a low-cost design I need a small 8-bit microcontroller (1-2k Flash
will do) and now the question is whether I need to plan for an
external resonator or an internal oscillator is good enough. My
application will have to communicate through a serial interface to the
outside world. I don't know yet if that's going to be a UART or SPI or
I2C, could be different for some of our customers.

It is my understanding that a synchronous interface such as SPI or I2C
should work without problems even if the transmition rate for I2C is
not 400 kbit/s but rather something like 250 kbit/s. Same is true for
SPI.
For the UART the story is a little different, I think I need an
accuracy of 2.5% or better. Many micros list a wonderful "trimmed to
1% accuracy" but after looking closer, the temperature drift for some
Microchip devices does not permit usage of the UART over -40/85
although they advertise 1% !?!
Low power was another consideration, so I looked into the MSP430 but
that internal oscillator is a POS. It comes up fast, end of good news
about this one.
Overall the Philips LPC900 oscillators are specified with +/- 2.5%
over temp range and voltage range.  They also offer very nice
combinations of serial interfaces already in the low cost devices. Any
experience with these devices in regards to the internal oscillator
would be greatly appreciated.

Thanks for your feedback, Schwob

Re: Why should I (not) use an internal oscillator for 8-bit micros
Quoted text here. Click to load it

Correct. Asynchronous protocols don't matter much (if at all).

Quoted text here. Click to load it

You have the basic idea right. The UART will be more sensitive to a drifting
clock at lower (yes, lower) baud rates. It all depends upon whether or not
you need accuracy with interprocessor communication or if the internal
timers need to be semi-accurate. If they're going to be in an environment
where the temperature varies signficantly, you can find that your CPU will
run fast and slow, and that may be irritating - depending upon your
application, of course.

-->Neil



Re: Why should I (not) use an internal oscillator for 8-bit micros
Quoted text here. Click to load it

ITYM synchronous.


No, the critical thing is agreement between the source and
receiver.  If they have separate clocks, the accuracy requirement
depends on the timing of the sampling of the individual bits and
the length of the bit stream per unit (usually 8 bit units, plus
stop and start bits, for 10).  Draw some signalling waveforms,
marking the sampling points, and it will become clear.

Synchronous protocols, on the other hand, carry the clock with
them so agreement is automatic (within reason, again depending on
the sampling technique).

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: Why should I (not) use an internal oscillator for 8-bit micros
Quoted text here. Click to load it

No, I meant asynchronous, where things like I2C and SPI have separate clock
and data lines. The clock lines can vary wildly and it'll still work. That
won't happen with a UART which requires synchronous clocking to occur - on
byte boundaries at least.

Quoted text here. Click to load it

That is what I meant above by "accuracy with interprocessor communication".

Quoted text here. Click to load it

And that was my point above as well.

Thank you for disagreeing with me, only to restate my points. ;-)

-->Neil



Re: Why should I (not) use an internal oscillator for 8-bit micros
Quoted text here. Click to load it

No, you do mean synchronous.  The clock line does the
synchronizing.  UARTs are generally asynchonous, as there is
previous agreement as to the clock rate, start/stop bits delimit
the individual transmitted bytes, and there can be any desired
time between such bytes.

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: Why should I (not) use an internal oscillator for 8-bit micros
Quoted text here. Click to load it

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



Re: Why should I (not) use an internal oscillator for 8-bit micros
I believe that UART stands for "Universal ASYNCRONOUS Receiver
Transmitter". You need to go back and study the difference between
sync and async.

Doug

Quoted text here. Click to load it



Re: Why should I (not) use an internal oscillator for 8-bit micros
Quoted text here. Click to load it

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



Re: Why should I (not) use an internal oscillator for 8-bit micros
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

Quoted text here. Click to load it
asynchronous
must
separate



Re: Why should I (not) use an internal oscillator for 8-bit micros
Quoted text here. Click to load it

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



Re: Why should I (not) use an internal oscillator for 8-bit micros
Quoted text here. Click to load it

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

Quoted text here. Click to load it

  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


Re: Why should I (not) use an internal oscillator for 8-bit micros
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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/1611%5200bps
internal clock (that will help minimize jitter).

Let's divide it down even further - 2400bps. That'd be a divisor of  48
(115200/4824%00). 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



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

Quoted text here. Click to load it

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




Re: Why should I (not) use an internal oscillator for 8-bit micros
Neil Bradley said...
Quoted text here. Click to load it

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.  

Quoted text here. Click to load it

No, but the two ends can use clocks that are 5% off from each other and
still communicate successfully.

Quoted text here. Click to load it

Incorrect.


Correct.


The clock can't vary - the two ends have to use the same
"synchronized" clock.  
 
Quoted text here. Click to load it

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

Re: Why should I (not) use an internal oscillator for 8-bit micros
Quoted text here. Click to load it

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!

Quoted text here. Click to load it

It depends upon the baud rate. The lower the baud rate the more susceptible
it is to being

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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



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

Quoted text here. Click to load it
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.

Quoted text here. Click to load it
tolerance.
susceptible

Correct. All properties of async coms.

Quoted text here. Click to load it
when

NO, they are not syncronized. THat is why the drift of sampling points
becomes
a problem.

Quoted text here. Click to load it

No, the drift has to be within acceptable bounds. That is not the same as
being
synchronized.

Quoted text here. Click to load it
on
hard

The fact that the tx and rx ends are using the same clock is the definition
of
synchronous coms.

Quoted text here. Click to load it
be,

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.

Quoted text here. Click to load it



Re: Why should I (not) use an internal oscillator for 8-bit micros
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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



Re: Why should I (not) use an internal oscillator for 8-bit micros
Quoted text here. Click to load it

This discussion is confusing the general term 'synchronized' with the
comms term 'synchronous'.  They are not interchangeable in this context.

Synchronous comms is where the baud rate is clocked using a signal
transmitted in parallel to the data stream; the receiver uses this
signal to sample the incoming bits.  Start & Stop bits are not used, and
it often uses a packet format with leading "sync" bytes and a trailing
checksum instead of parity bits.  Receiver clockspeed is irrelevant, so
long as it can sample once per cycle on the incoming clock.  (TX and RX
baud rates are synchronized via the clock in the data stream, so the
rate can drift without harm.)

Asynchronous comms uses no inline clock, and depends on the TX and RX to
operate near the same baud rate, i.e., using the same I/O sampling
frequency.  Bytes are "clocked" individually, and the RX detects the
byte via the Start bit that's prefixed.  (TX and RX baud rates are
synchronized independently from the data stream, and they'd better be
close.)

With async comms, a bad reference clock (MCU oscillator) causes sampling
to miss entire pulses (or start counting them twice, depending on who's
running fast).  IIRC, TX and RX baud rates have to be within 5-6% of
each other or the last pulse in a byte starts getting sampled wrong
(regardless of the baud rate).

Re: Why should I (not) use an internal oscillator for 8-bit micros
That was my point earlier although perhaps I did not make it well.
Just because there is a point of synchronization at the edge of the
start bit doesn;t make it synchronous comms. Way early in this
thread the OP referred to synchronous comms with reference
to the synchronization at the start bit edge. Since then the thread
had gone off into the weeds of error tolerance between tx and rx cloack.

Doug

Quoted text here. Click to load it



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

Quoted text here. Click to load it
message

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.


Quoted text here. Click to load it
and

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


Quoted text here. Click to load it
sides
in
effect
definition
I'm
the
since



Site Timeline