# How should I select my crystal frequency?

I have seen questions like this that talk about selecting a crystal for UART and I have seen questions like this that mention 32.768 kHz for RTC. But how do I decide the right crystal for my application.

At this point I am not sure what UART baud I will be using, but it will be one of the standard one. It would be nice to be able to get semi-accurate time in milliseconds, but not a requirement. Intuitively I think going with the fastest crystal that my micro can use will give me the most flexibility, but is there something I am missing? Is there a "general-purpose" frequency that people use?

• with great care... :) Commented Dec 20, 2010 at 20:37

Honestly I could spend hours describing the different frequencies and why to use them, but someone already has!

http://en.wikipedia.org/wiki/Crystal_oscillator_frequencies

This table has a UART column to tell you what UART frequencies it divides to well.

It also tells you when a frequency is a standard crystal for a specific comm system.

• Wouldn't it be nice if there was some nice crystal frequency that everyone used. Commented Dec 21, 2010 at 4:14
• Wouldn't it be nice if every part of the world had the same power outlets in buildings, life shall continue, unless you mix up the outlets. Commented Jan 6, 2011 at 18:30

Intuitively, I would use the SLOWEST crystal that works for my application. You'll get less clock drift and circuit traces generally behave nicer at lower frequencies.

As an aside, if you want to do things every few milliseconds, you can do something along the lines of the following:

Fosc = 25MHz.
T=1/Fosc = 40ns;
1ms/40ns = 25000 cycles/ms;
0xFFFF-25000=0x9E57;

on overflow TMR1:  //assuming TMR1 is 16 bit and counts every clock cycle
doEveryMillisecond;
incrementMillisecondTimer;
TMR1 = 0x9E57;


Not sure what micro you're using but MPLAB has utilities to time how long events take, so you can use that to adjust the reset value of TMR1 to deal with any overhead and/or an inaccurate clock. Crystals might vary enough that this is infeasible in a production environment... not sure.

• As an extension to this, if one doesn't know what XTAL to use in their widget, don't select one at all. Just leave the PCB spot unpopulated and wait 'til you need the stability (calibration of internal RC oscillator isn't good enough at the desired baud rate, for example) or speed. Don't fix what ain't broke! Commented Dec 20, 2010 at 18:33
• Agreed - if your MCU has an internal oscillator, try and use that first. Make sure to set config words/fuses correctly. Also, you should consider using a socket on your PCB so you don't have to deal with soldering/desoldering crystals... bonus is that you can swap them easily. Commented Dec 20, 2010 at 18:39
• @isaac, a crystal is one of the largest sources of EMI on a board, it should be as close to the ground plane as possible, not go through connectors, and have shield traces around it. Commented Dec 20, 2010 at 19:09
• @isaac, also, if you have 10ppm clock drift it will not matter what crystal speed you have. They all will divide down to the same potential error, as a higher speed clock must have a larger divide. A slower crystal means worse resolution on other things. Commented Dec 20, 2010 at 19:10
• @isaac I have never had issues with 40MHz crystals before. I just stick them as close to the micro as I can. and @kortuk response is the same reason why I didn't think clock drift was an issue. I figured higher clock speeds would let me able to get closer to 1 ms exactly. Commented Dec 20, 2010 at 21:09