Tell me more ×
Electrical Engineering Stack Exchange is a question and answer site for electronics and electrical engineering professionals, students, and enthusiasts. It's 100% free, no registration required.
up vote 4 down vote favorite
3

I always use the internal oscillator that pics have as I have never found the need to run anything at higher frequency than 8 MHz (which is the fastest the pics I use tend to be able to go). Are there any reasons, beyond going above 8 MHz, that mean I should use an external oscillator? It just seems like one more thing to go wrong to me but I'd be interested to hear what others do.

share|improve this question

4 Answers

up vote 15 down vote accepted

As others have said, accurate frequency and frequency stability are reasons to use a external ceramic resonator or crystal. A resonator is several times more accurate than the internal R-C oscillator and good enough for UART communication. A crystal is much more accurate, and necessary if you are doing some other types of communication like CAN, USB, or ethernet.

Another reason for a external crystal is choice of frequency. Crystals come in a wide range of frequencies whereas the internal oscillator is usually one frequency with maybe a choice of 4x PLL enabled. Some newer 24 bit core PICs have both a multiplier and divider in the clock chain so you can hit a wide choice of frequencies from the single internal oscillator frequency.

There are of course various applications that inherently require accurate frequency or timing other than communications. Time is the property in electronics that we can measure most accurately cheaply, so sometimes the problem is transformed into one of measuring time or producing pulses with accurate timing.

Then there are applications which require some long term synchronization with other blocks. A 1% oscillator would be off by over 14 minutes per day if used as the basis for a real time clock. Accurate long term time may also be needed without having to know real time. For example, suppose you want a bunch of low power devices to wake up once every hour to exchange data for a few seconds and then go back to sleep. A 50ppm crystal (very easy to get) will be off no more than 180ms in a hour. A 1% R-C oscillator could be off by 36 seconds though. That would add significant on-time and therefore power requirements to the devices that only needed to communicate for a couple of seconds every hour.

share|improve this answer
Off-topic, but I thought CANbus was designed to be robust enough to handle variations in clock frequencies between nodes. Am I misunderstanding? – Remiel Jun 18 '12 at 13:37
@Remiel: CAN has provisions for nodes staying in sync despite some clock frequency difference. The nodes still need to be reasonably close. In most cases you basically need at least a ceramic resonator in each node. – Olin Lathrop Jun 18 '12 at 14:37
up vote 10 down vote

Frequency stability will be higher with an external one. So if you have a application that really depends on the mcu freq, then you may need to use a external one.

But most modern mcu:s has a quite stable internal osc, therefore I think this used to be a bigger question a couple of years ago. Also there is more and more ways to trim the internal one, and compensate for temperature drift (etc etc).

On the other hand there is other ways to make sure that you are synchronized, in some countries the freq stability in the power net is 50Hz ±0.01Hz and other places like Sweden actually has ±0.001Hz and I have seen projects using this to keep things in sync. And then you are no longer as dependent on the mcu freq and you can use the internal one. But this is a little bit of topic :)

share|improve this answer
2  
Note that those mains frequency figures are long term stability. That's okay to keep time accurately over weeks or months, but over a short period (hours) you may experience serious deviations. You'll hardly ever have to adjust time on an el cheapo digital clock, however. – stevenvh Jun 15 '11 at 9:10
@stevenvh good point, also note that there is other sources that could be used to verify long term stability as well. Both the gps and gsm systems has very nice clocks but it is more complicated to use them. – Johan Jun 15 '11 at 9:19
2  
though there are many other applications that would require it, there's one that specifically causes a lot of problems w/o an accurate time base - serial communications. – JustJeff Jun 15 '11 at 10:50
I don't know of any frequency stability which would not be higher with an external quartz crystal. You're not going to get sub-0.1% accuracy with a silicon oscillator. – Jason S Jun 15 '11 at 23:20
1  
@Johan - DCF77/WWVB is as accurate as GPS or GSM, and a lot easier to work with (1Hz heartbeat) – stevenvh Jun 16 '11 at 12:41
show 6 more comments
up vote 1 down vote

Frequency stability is the main one, particularly for serial comms at high speed. But that also brings up the occasional need for a crystal at a seeming odd frequency to get an exact baud rate, because of the limited options that the clock dividers give you.

share|improve this answer
up vote 1 down vote

I have actually come across a scenario where 1% was not good enough for UART.

If any of you guys have heard of the Teensy++ v1.0 microcontroller dev board, it has a terribly sensitive UART. I had my host baud set at 115200, and it set at 115200 and for the longest time could not figure out why it wasn't reading the data correctly. Turns out my host was sending closer to 114300 baud. ( 115200 - 114300 ) / 115200 = ~0.9% error. I tried it with two different MCU's and they worked fine.

Point is: regardless of your application, if greater accuracy of clock frequency is a benefit, you should use an external resonator, crystal, or even oscillator if you chip doesn't have the necessary driving circuitry.

P.S. I wonder if anyone has any insights as to what low level design choice they made on the UART hardware that makes it so sensitive?

share|improve this answer
The fundamental requirement for a UART is that the receiver sample each bit while it is valid. Ideally, the receiver would notice the precise moment the start bit arrived, and sample the data precisely 1.5 one bit times later, then 2.5, 3.5, etc. up to 8.5 bit times later. In practice, there's usually some slop in when the receiver detects the start pulse, and there may be more slop after that. For example, one might try to receive 2400 baud using a processor running 8,192 instructions per second.... – supercat Jun 16 '11 at 17:46
Such a thing can be done if the transmit timing is perfectly clean, but the sampling won't happen at precise 417usec intervals. Instead it will happen at some intervals of 366us and some of 488us. When a receiver is "picky", what that often means is that it's sampling data much earlier or later than when it should, but at a time when an ideal transmitter would be outputting the expected data bit. – supercat Jun 16 '11 at 17:49
@supercat Why would they ever design it to sample earlier than later? It seems like sampling at the .5's like you described would always be best. That's how I implemented my software UART a couple years ago... didn't even occur to me to do it any other way. That simply allows for the most error margin on the transmitter. – Nick Halden Jun 16 '11 at 18:47
@JGord: If sampling is controlled by a clock that's much faster than the baud rate, things are wonderful, but that isn't always the case. Suppose, for example, one were trying to receive 115,200 baud using a 6502 running at 1.0MHz and no UART. A loop waiting for the start bit will take 7us, and polling opportunities are scheduled at 1us intervals. There's an 8us uncertainty as to when the 6502 would poll a bit, but since bits are 8.6us long, one could receive data successfully if... – supercat Jun 16 '11 at 20:04
...the transmission speed was precise, rise and fall times were uniform and symmetrical, and there was no other jitter. I don't know about the Teensy board, but I wouldn't be surprised if it was using a software UART to push the controller beyond its normal abilities. – supercat Jun 16 '11 at 20:06
show 2 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.