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.
-
"*Why is there a need sometimes for an external crystal, even though the MCU have an internal CPU?*" The fact that the MCU has an internal CPU has almost nothing to do with why an internal or external clock is used. Are you conflating/confusing two different issues? – gbulmer Dec 08 '15 at 08:49
-
It may help you to understand completely http://microcontrollerslab.com/oscillator-types-microcontrollers/ – Bilal Malik Oct 19 '16 at 04:42
7 Answers
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.

- 145,145
- 21
- 455
- 667

- 310,974
- 36
- 428
- 915
-
1Off-topic, but I thought CANbus was designed to be robust enough to handle variations in clock frequencies between nodes. Am I misunderstanding? – Stephen Collings Jun 18 '12 at 13:37
-
1@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
Precision. Internal clocks are not precise, can be affected by noise.
Temperature independent precision. Typical oscillators can vary wildly. Specialty temperature compensating oscillators can be needed in low or high temp applications, or if temperature varies wildly.
Speed. Internal oscillators may not reach the highest speed of the IC. External ones can be needed for that.
Voltage. The speed of an internal timer may be dependent on the voltage it is being run at.
Multiple clocks are needed. Some applications want to share an oscillator.
Special applications where the internal clock may not be easily used. Dividing the internal clock might be harder than throwing a cheap 31 kHz watch crystal at it, for time keeping applications.
Off the top of my head, the ATMEGA 328 the arduino uses requires an external crystal at 5V for its max speed. The lily pad version runs at 8 MHz, on the internal oscillator because it's limited to that at 3.3v. The MSP430 Value Line launchpad is limited to 10 MHZ at 3V, 8 at 2.5V.

- 72,580
- 7
- 90
- 202
-
10An example for precision: USB needs a precise clock. Microchips PIC18F2550 can generate quite any clock speed internally, but it's precision is too bad for USB. When I tried it, there was a disconnect every 10-20s. This didn't happen with an external oscillator. Meanwhile they have the PIC18F25k50, which can synchronize its clock to the USB signal and doesn't require an external oscillator for USB any more. – sweber Dec 08 '15 at 10:07
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 :)

- 2,385
- 2
- 25
- 27
-
3Note 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 09: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 09:19
-
3though 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
-
@Jason A external osc is always more stable, the question is when/if you need the extra stability? Olin Lathrop has a couple of good examples on serial communication. – Johan Jun 16 '11 at 05:47
-
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
-
@stevenvh I think DCF77 is the one used in those radio controlled clocks, and with those I know that I only has signal in some parts of my house. So it is depending on where you are in the world if you can use this or not. But +1 it is cool – Johan Jun 16 '11 at 12:59
-
@Johan: then why not edit from "Frequency stability can sometimes be higher with an external one" to "Frequency stability will be higher with an external one"? – Jason S Jun 16 '11 at 13:04
-
@Johan - I can receive the DCF77 signal everywhere in my apartment, which I can't say about GPS. But then Belgium is a lot closer to Frankfurt than Sweden. (BTW, you'll have to position the magnetic antenna perpendicular to the Frankfurt direction) – stevenvh Jun 16 '11 at 15:06
-
@stevenvh I think you have ok reception to the second circle on this map from wikipedia http://upload.wikimedia.org/wikipedia/commons/b/b4/Dcf_weite.jpg – Johan Jun 17 '11 at 08:39
-
@Johan - Transmitter power (and location) was chosen such that you've got good coverage over most of Europe, so it looks like it goes up to [2000 km](http://www.timetools.co.uk/support/dcf-signal-coverage.htm) . If you're in Kiruna yo may have bad reception :-). Although I've heard of occasional reception in Karachi, Pakistan, 7000 km away(!) – stevenvh Jun 17 '11 at 09:12
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.

- 8,320
- 1
- 22
- 30
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?

- 4,167
- 3
- 31
- 40
-
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. – NickHalden 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
-
@supercat I'm pretty sure its a hardware UART, its based off the AT90USB646 chip which definitely has a hardware UART (2 of em in fact). Also, it's clock is at 16 MHz... but whatever, I understand how problems could arise. Just doesn't seem like they should have in this case. Funny how that works. – NickHalden Jun 16 '11 at 20:18
-
@JGord: Even if a device has a hardware UART, those are often limited to certain sub-multiples of the clock rate. Sometimes people use software UARTs to go faster. People have sent and received 115,200 baud using 6502's running 1.0227MHz (e.g. the Apple ][). The receiving software couldn't do anything with the data but buffer it (the sender would have to wait after each packet) but even so 115,200 was better than 57,600. – supercat Jun 16 '11 at 20:35
External crystal crystal oscillators are more accurate than internal clocks, and they should be used when accurate timing is necessary. Sometimes to save money, designers use internal ones.

- 103
- 3

- 659
- 1
- 7
- 17
Another concern related to the oscillator that has not been mentioned is the power consumption. It does not make a big difference though. Check the next chart from the PIC16F628A datasheet:
You can notice first that the more frequency then the more power is consumed. It can make a difference in low power applications.
And about the internal vs external doubt there is, the INTOSC consumes more power than the XT at the same frequency, around 30% more power.
If this information is relevant or not, it depends on the application.

- 166
- 6