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

I read somewhere that the ATMEGA line of chips have an internal clock mechanism. The 168PU's clock operates at 20MHz, therefore, if the external crystal is only utilized mainly for power tolerances and communication speed/reliability, once the 168 is programmed, is it possible to remove the 14MHz Crystal and have the chip run its program? I haven't tried it yet and if it does work, I need to know what the pitfalls are (if any). Just wondering. Awesome info here

Al

The internal clock operates at 8mhz and is divided by 8 for factory default configuration of 1mhz. All clock rates are controlled by fuse settings and if you have fuses set for 14mhz and you pull the crystal, the mcu will not run. You can find documentation on fuse clock settings in the ATmega48/88/168/328 datasheet.

In conjunction with Noter's comments, you can also program the mcu using the default Nerdkit crystal (14.7456MHz)

but program your program to use a different crystal i.e.:

#define F_CPU 20000000

I believe 20MHz is the fastest crystal supported for the ATmega168 and ATmega328.

Again as Noter said the internal clock is 8MHz.

You would have to supply the 20MHz crystal.

Ralph

Noter, Ralph, than you for your excellent comments. That really helps. So the chip actually runs at 1MHz 8/8 (without a crystal) The reason why I ask is because I'm building a unit that I know it will be dropped and roughed up, I hear that crystals are fragile and break easily. Any suggestions? I think I read that there were plastic or ceramic crystals? Thanks again

Al

Hi amartinez , well even if you could live with the internal clock the micro itself and any other components has to be protected from the shock of being kicked around or dropped.

You need to look for shock mounts, of course you will using a PCB a breadboard would not last.

Google PCB shock mounts or something like that.

Interesting thread keep us posted.

Ralph

I tried running the original program that came with the NK without the crystal and the LCD was full of null characters. Some had writing but mostly null. I ordered several crystals, one is 20MHz. I want to see if this will work. Thank you for the shock mounts links but they are not a good solution for the unit's application, unless I create a separate PCB for the MCU and the Crystal itself, add shock mounts then use a ribbon cable to attach to the main PCB.

I hooked up an oscilliscope to the 14Mhz crystal and it was going crazy, didn't really make much sense. There was a sine wave but it showed too erradic.

I will keep you posted, but 1MHz is not the way I want to go. I may use a 20MHz crystal and cross my fingers as to functionality and vibration.

Thank you

Al

I don't run 1mhz either but I often run 8mhz on the internal oscillator by unprogramming the fuse bit that configures to divide the clock by 8. Keep in mind you will need to change usart baud configuration in the bootloader and reinstall it on your atmega if you change clock frequencies. Otherwise your serial rate will change and you won't be able to program the chip with the nerdkit usb cable. Take a look at Rick's thread on installing the bootloader.

I've recently been looking into this, and it appears that you can use 18.4320 Mhz crystals if you want some extra cycles and still have relatively 0% error rates (see ATmega168 datasheet, p. 199) for a majority of common baud rates. As for the bootloader, you would need to recompile it with a clock rate divider of 160 instead of 128 with the 14.7456 MHz. You would also need an AVR ISP device to program the bootloader into the chip, too.

One additional benefit of using the 18.4320 MHz would be for a higher precision realtime clock and PWM switching rates. The current realtime counter project on the nerdkits website uses a 14.7456 Mhz clock prescaler at 1/1024 and an interrupt counter value of 144 yields an interrupt at 100 Hz cycle or 10 ms between interrupts. A 18.4320 Mhz clock prescaler at 1/1024 and an interrupt counter value of 18 would allow for a 1000 Hz cycle or 1 ms between interrupts. You would obviously want to have a much simpler interrupt service routine since you would have a shorter interval to run instructions on the chip, but it would be clocked 25% faster.

Other downsides of a higher clock speed would obviously be increased power draw due to more cycles drawing electrons, but it could be countered with the power saving features of the microcontroller at the expense of additional firmware code complexity.

When I use a crystal I use the 18.4320 Mhz most often. Not as fast as the 20Mhz but nice for all the baud rates like you found in the datasheet. Setting the baud rate is easy too. If you define F_CPU and BAUD in the makefile ahead of time you can set it like this in your C program:

    // initialize serial IO
    uart_init();
    UCSR0A = 0;
    UBRR0L = (F_CPU/(16*BAUD))-1;   // F_CPU & BAUD defined in makefile

Defined in the makefile like this:

F_CPU=8000000UL
PGM_BAUD=115200L

And add this line to the end of your avr-gcc command in the makefile:

    -DF_CPU=$(F_CPU) -DBAUD=$(PGM_BAUD)

If it's a high precision clock for timekeeping you want then you're much better off to use the DS3232 Real Time Clock. Can't come close to it's accuracy with an ATmega without a lot of work.