8

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?

Community
  • 1
Kellenjb
  • 17,509
  • 5
  • 51
  • 87

2 Answers2

13

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.

Kortuk
  • 13,362
  • 8
  • 60
  • 85
  • Wouldn't it be nice if there was some nice crystal frequency that everyone used. – Kellenjb Dec 21 '10 at 04:14
  • 1
    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. – Kortuk Jan 06 '11 at 18:30
2

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.

Isaac
  • 296
  • 1
  • 3
  • 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! – tyblu Dec 20 '10 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. – Isaac Dec 20 '10 at 18:39
  • 1
    @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. – Kortuk Dec 20 '10 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. – Kortuk Dec 20 '10 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. – Kellenjb Dec 20 '10 at 21:09
  • @kellenjb, you pick your crystal to divide to exactly what frequency you need. speed makes no difference there, but what one tic equals will be affected by that decision. – Kortuk Dec 21 '10 at 05:02
  • Power requirements (i.e., how often you need to change the battery) increase with frequency. Electromagnetic interference also generally increases with clock frequency. – davidcary Feb 01 '11 at 03:27