"blink" on Atmega8 works perfectly but time slowed down!

Setup:
I'm using Arduino as ISP to burn small programs onto an external Atmega 8L chip on a breadboard, with a 4 MHz crystal (don't have an 8 MHz lying around), and an LED on one of the digital pins.

For example, right now, I burned the Blink program (with 1000 msec interval between pin HIGH and LOW in the code).

Problem:
Everything works fine, BUT the blinking happens every 3-4 seconds instead of the coded 1 second.
(Similar things happened with Fade program, etc.; everything works but seems to slow down a few-fold)

Wondering why this might be..

Wondering why this might be..

4 MHz crystal (don't have an 8 MHz

Ummm, let me think about that for a while :slight_smile:


Rob

You've fooled the microcontroller, it now counts 3600 secs in 2 hours, but otherwise functions fine.
Likewise it will probably see 3600 secs in 30 minutes time using a 16MHz one.

hehe shoot, such an obvious reason huh?

but hmm wondering why the LED is not blinking exactly HALF the speed (it's blinking around quarter or less the speed) if I'm using a 4 mhz. maybe it has do with the fact that the frequency dictates the number of instructions executed per second, to which the LED blinking might not be linearly proportional because of the presence of other operations in the code. just ordered some 8 mhz crystals; will do some timing tests soon.

Did you change the fuses to use an external crystal?

You might indeed be able to fiddle with the fuses. The micro-controller has an internal oscillator as well, capable of 8 MHZ. That would eliminate the need of an external one. Fiddling with fuses is quite tricky though and unfortunately I only did in another IDE using the same chip, can't tell you much about Arduino.

Anyway, If a blink program turns a light on for one sec and turns it off for another, one complete cycle takes 2 sec, right ?
The number you gave for a 4 MHz crystal, 3-4 secs there for also sounds right.

wondering why the LED is not blinking exactly HALF the speed (it's blinking around quarter or less the speed) if I'm using a 4 mhz.

The only mega8 board I see in the tools menu ("NG or older with ATmega8") will be assuming a 16MHz clock, so a 4MHz crystal will run it at 1/4 speed.

You can look at the expected speed by doing the compile in verbose mode. Look for the -DF_CPU=16000000L part of the compile lines.

thank you! just plugged in a just-received 16mhz and the led blinks at the right speed now.

@westfw:
compiling in verbose mode, DF_CPU does indeed read 16000000, so that makes sense now as far as the program's expectation goes.

Question:
I'm now reading a couple of people's documentation regarding setting fuses via avrdude to have the ability to set a specific frequency according to the particular crystal I use, but in the meantime:

Atmega8L (not the 8, but the 8L) has a speed grade of 8 Mhz, as listed on datasheet (I'm assuming "grade" is a less specific way of saying recommended/maximum external clock frequency?).

Then, why is it that upon using 16Mhz crystal, the LED blinks at the correct rate? Maybe, the correct blinking is because the program is compiled with a 16Mhz expected config, but restating, why is it that the atmega8L is STILL functioning correctly with the 16Mhz crystal, despite that being beyond the "speed grade"? Perhaps it's expected to just be less RELIABLE at a crystal beyond the datasheet-listed speed grade?

Perhaps it's expected to just be less RELIABLE at a crystal beyond the datasheet-listed speed grade?

I think that is the case, people "over clock" these chips all the time, but I wouldn't put on in the space shuttle :slight_smile:


Rob

The L-suffix parts are guaranteed (and presumably tested) to work at 8MHz when powered at 2.7V, while the non-L suffix parts are guaranteed to run at 16MHz at 4.5 to 5V. The general theory is that ALL parts will run 16MHz at 5V, but only some will run 8MHz at 2.7V, so you are likely to be able to run the L parts at 16MHz if the supply voltage is high enough, and somewhat less likely to be able to run the non-L parts at low voltages.

Counting on this in critical applications would be a bad idea.

But you'll notice that the newer parts (328) have done away with low-voltage designated parts, and just provide a curve of expected max clock rate vs supply voltage...