timing problems with millis and micros [Fixed]

Hi guys, I'm working on a little project, a PWM-Fancontroller to be exact. I've read some posts who really helped me in getting a basic sketch together in my brain (far far away from complete), but while doing some some blinking tests (you know LED on and off) I found a timing problem with my Arduino. Well its a selfmade Arduino (atmega168 on a protoboard 16000mHz, isp header) I've wrote the sketch (the blinky one) in the ArduinoIDE and uploaded the hexfile with AVR Studio using a AVRISP mkII. Well the LED is blinking BUT too slow delay(1000); will result in 10 seconds on and 10 seconds off, not 1 second as it should be, same thing with with micros or millis. Thats a big problem in this project because I need that software pwm and with this problem I will end up with only 4 out of 40 steps in controlling the Fanspeed, that isn't really enough.

There is no Bootloader on the chip, because i don't have an FTDI breakoutboard or a different programmer expect the AVRISP mkII. I use the Arduino IDE 0018 and I selected Arduino Diecilima /w ATmega 168 (the same chip I'm using). I hope someone out there can help me :-[

I hope someone out there can help me

You could help us all and yourself by posting the code you're using.

16000mHz

16000mHz is only 16Hz - did you really mean that?

right now (for testing purpose) just the example sketches: Blink and BlinkWithoutDelay

I figured if this doesn't even work I don't even need to try other stuff because it will work with the same commands

16MHz woud be 16000 hz not the other way around, right?

it's 16000MHz

it's 16000MHz

You've got a 16GHz crystal? "mHz" - milliHertz - thousandths of a Hertz. "kHz" - kiloHertz - thousands of Hertz. "MHz" - megaHertz - thousands of kHz.

You know 16000MHz is 16 GHz? :)

It sounds like you did not program the fuses correctly and instead of running at the expected 16 MHz frequency (you do have an external 16 MHz crystal/oscillator/resonator, right?) it is running at a much smaller frequency.

Investigate the Fuses tab of the AVR Studio programming window and see what the fuses are set at.

-- The Gadget Shield: accelerometer, RGB LED, IR transmit/receive, light sensor, potentiometers, pushbuttons

16MHz woud be 16000 hz not the other way around, right? it's 16000MHz

Bzzzt, wrong on both counts. 16MHz = 16000 kHz = 16000000Hz. 16000MHz would be 16 GHz, which lies outside of the ATmega specs. But all this doesn't really touch your problem.

If your Arduino is running at another speed than the compiler assumed at compile time. For example, if the clock runs at 1MHz (if I remember correctly) is used instead of an external crystal and the compiler assumed a 8MHz clock, you would experience symptoms like this.

I would start by trying to measure how fast your code runs in in reality with the by comparing the time taken by delayMicroseconds(20000) and the report of micros() between start and end. Or just toggle a pin with delayMicroseconds(20) and measure the pulse with using an oscilloscope. This will give you an indication what's wrong, the clock speed or the value of millis(). If it's the first, you need to look at how you wired and set up your Arduino. If it's the second, I would look into the compiling options of your sketch.

Perhaps that helps.

Korman

Edit: I must type faster, two other said the same in less time.

oops there is a point actually a dot after the 16 (sry not wearing my glasses ^^'')

so its 16 MHz ::)

fuses sound reasonable (will check it in a few minutes)

The factor of ten speed reduction seems to point to a crystal problem, not fuses - it isn't possible (I don't think) to get a decimal speed factor via the fuses, only binary.

back fuses didn't changed anything.

crystal works fine or all my crystalls are destroyed in the same way (kind of doubt that)

I don't know what you mean by "back fuses".

Check the CKDIV8 fuse in the low fuse byte. If this is 0 (programmed), which is the default, your clock will be running at 1/8th speed (2 MHz). That would explain the "factor of 10" reduction (probably actually just a factor of 8).

-- The Quick Shield: breakout all 28 pins to quick-connect terminals

sry the "back" slipped in while overwriting some text ^^

anyway the CKDIV8 was the problem, you solved it thank you :)