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

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

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

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

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.

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

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.

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

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

asynchronous

must

separate

Perhaps, but there is an industry accepted usage, which is clear if you read (as an example)

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

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

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.

Casey

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

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

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.

tolerance.

susceptible

Correct. All properties of async coms.

when

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.

on

hard

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

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.

Depends on the definition you're using (from

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

"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