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

"Schwob" <schwobus@aol.com> wrote in message
news:123e50e1.0408141619.5d4d54a4@posting.google.c om...
Correct. Asynchronous protocols don't matter much (if at all).

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

Schwob wrote:

This is a relatively new field, so you are right to watch the fine print!
At the least, you should look at the Voltage / Temperature deviations,
if there is a mechanism to calibrate, as well as if the deviation
needs to be allowed at BOTH ends of the link.

Thus XTAL <-> RegVoltTempComp OSC may be workable, but
BatteryVoltTempCompOSC <-> BatteryVoltTempCompOSC may be out of spec.

Aging, or drift over time, is not often defined for these on On Chip
oscillators, but you will see this defined for better crystals, and high
spec resistors. [Of course, these can cost more than cheapo uC]

Voltage variations, the designer can do something about, by choosing
a good spec regulator 1-2% is quite doable, sub 1% is available at a
price. Temperature is not as easy, so ideally the chip vendor has done
a good job there.

If the RC Osc has some trim scheme, then you can allow for a Baud Trim
Handshake, and that can protect you against long-term drift effects.
I think the Philips LPC family allow this.

The safest approach is a PCB design with an option for an external
Cyrstal/resonator, plus a SW design that can Fine Baud trim,
if needed

-jg

....


Some microcontrollers allow you to fine tune the oscillator in software
(some PIC chips allow this). You may be able to get an external device
to send several "U"'s as test bytes, and use some trickery to calibrate
the oscillator properly.

cheers,

Al

Neil Bradley wrote:
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 (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

The LIN Standard allows for trimming of the Slave Oscillators, by sending a
Sync Byte ( 0x55 ) before every message, this allows slaves which are using
low cost internal oscillators to trim themselves.

Motorola now have a range of HC908QL parts that do this autmatically without
any software overhead.




"Al Borowski" <al.borowski@EraseThis.gmail.com> wrote in message
news:411f350c$0$16339$5a62ac22@per-qv1-newsreader-01.iinet.net.au...

"CBFalconer" <cbfalconer@yahoo.com> wrote in message
news:411F4D38.BF6EEF59@yahoo.com...
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.

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

And that was my point above as well.

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

-->Neil

Neil Bradley wrote:
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 (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

"CBFalconer" <cbfalconer@yahoo.com> wrote in message
news:411FC1AD.91751819@yahoo.com...
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

I believe that UART stands for "Universal ASYNCRONOUS Receiver
Transmitter". You need to go back and study the difference between
sync and async.

Doug

"Neil Bradley" <nb_no_spam@synthcom.com> wrote in message
news:10hvisv6ucimkf3@corp.supernews.com...

"Doug Dotson" <dougdotson@NOSPAMcablespeed.NOSPAMcom> wrote in message
news:ismdnTKuDKd_T4LcRVn-hQ@cablespeedmd.com...
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...

Neil Bradley wrote:

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

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

Incorrect.

Correct.

The clock can't vary - the two ends have to use the same
"synchronized" clock.

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

http://www.inetdaemon.com/tutorials/...ynchronous.htm



Casey

"Casey" <cclremovethispart@cox.net> wrote in message
news:JoUTc.21115$pT5.3217@lakeread05...
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!

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

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.

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
newstednWpGDrpYn73cRVn-gQ@cablespeedmd.com...
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...

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.

Correct. All properties of async coms.

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

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

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

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.

"Doug Dotson" <dougdotson@NOSPAMcablespeed.NOSPAMcom> wrote in message
news:u9adnR6BVMpmtr3cRVn-hw@cablespeedmd.com...
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.

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

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