I would like to understand why the crystal frequency of 14.7456 MHz is selected in the first place. Why not 14 MHz or 16 MHz or 20 MHz?

I could find 14 MHz, 16 MHz and 20 MHz crystals readily available in the market. So my guess is that it has nothing to do with the availability like standard values for resistors.

I would also like to know why the kit uses 14.7456 MHz instead of a 20 MHz crystal. 20 MHz will make things run faster but what is the down side.

Is there a special reason for selecting 14.7456 MHz as the crystal frequency?

Thanks, Raja

Hi Raja,

We chose 14.74756 MHz because we wanted to enable high-data-rate serial communications to and from the PC. Commonly-available standard UART rates go up to 115200 baud (i.e. the clock rate on the serial port line is 115.2 kHz). So 14.7456MHz may seem like a strange number, but it was chosen because it evenly divides to 115200. (14745600 / 128 = 115200.)

If you take a look at Table 19-11 and 19-12 on pages 198-199 of the ATmega168 datasheet, you'll see a table listing the serial port clock rate error for different combinations of baud rate and crystal frequency. The 14.7456 MHz crystal allows for zero error up to 115200 baud, while the 20MHz would have an error of 1.4%. This may not sound like much, but it starts to approach the roughly 5% maximum tolerable error for 8-bit serial protocols, and is right at the edge of the "recommended max error" on Table 19-2 (page 189). So when you also consider that there may be some clock mismatch due to the PC end serial port, or in a USB-serial converter itself, we decided to stick with a nominally-correct baud rate to ensure maximal compatibility.

One more consideration is that there is a curve of maximum clock frequency versus operating voltage -- see Figure 28-2 on page 306 of the ATmega168 datasheet. Picking a lower clock frequency allows the system to tolerate a lower supply voltage, down to about 3.5 volts in this case. For a learning system like this one, we think it's appropriate to compromise a little bit on operating clock frequency to have a much wider tolerance on operating conditions.

Hope that helps!

Mike

Thanks Mike. Yes, it helps.

-Raja

Mike,

Does this mean a 20 MHz Xtal can be used otherwise? Unless the kit needs to communicate through the port? Would that have other effects?

Just wondering, as I have a whole bunch of various crystal values to pick from and I would hate to let them go to waste.

Dave

Hi Dave,

Yes, you can use a different crystal frequency if you wish! There's even a customer that's overclocked his NerdKit to 25MHz! (This is beyond the 20MHz spec and not guaranteed to work... but neat that it does.) You might even make the serial port work at the same baud rate as before (in your program) by changing the UBRR0 register to the appropriate divisor for your new frequency (see pages 198-199 in the ATmega168 datasheet).

However, the bootloader is locked to running at a serial baud rate equal to the crystal frequency divided by 128, so for 14745600/128 = 115200 baud. Changing the crystal frequency will change the baud rate proportionally, which will be non-trivial (or impossible) to make work with your serial port or USB-serial adapter (although Fahr was able to make it work in the thread I linked to above). But you can certainly program the chip with the 14.7456 MHz crystal in place, and run with the other one. Or, you can re-program the bootloader with a new divisor value.

Mike

Is it possible to alter a number in the uart library so we could upload with a different crystal? I looked at the programming in the library and noticed "UBRR0L = 7; // for 115200bps with 14.7456MHz clock" in one of the lines and that since we're dealing with digital arithmetic, then we could alter the number and use the equation (2^a * 115200bps = needed_crystal_frequency), where a=7 with the 14.7456mhz crystal oscillator, in which we can overclock it to (2^8 * 115200bps = 256*115200bps = 29.4192mhz), and so on. then we could use fast crystals, even when uploading.

Hi DrNoExpert,

You have the right idea, and as Mike explained above these sort of modifications are definitely possible. The reason we the 14745600 Hz clock is because it divides evenly into a baud rate. In order for your idea to work you would have to find a 29.4192 Mhz clock which are not readily available, and it is also much higher than the 20Mhz max clock speed for the chip.

Humberto