ATTiny85 run at 1Mhz When I Program "delay(1000)" does not give 1 second?

I find that the 328p runs at 16Mhz or so does it? When I program to delay 1 second it is pretty close to 1 second
When giving the same command to an attiny85 which runs on an internal clock of 1Mhz it is very short .

So I can adjust the fuses in the tiny to 8 meg but I jaust wonder without doing that ,how do I get it to delay exactly 1 second?

april:
I find that the 328p runs at 16Mhz or so does it? When I program to delay 1 second it is pretty close to 1 second
When giving the same command to an attiny85 which runs on an internal clock of 1Mhz it is very short .

If there's a big difference then the fuse settings don't match the board selected in the Arduino menu. Try doing "burn bootloader" (this sets the fuses even if you don't need the bootloader)

april:
So I can adjust the fuses in the tiny to 8 meg but I jaust wonder without doing that ,how do I get it to delay exactly 1 second?

What do you mean "exact"? The internal clocks are only approximate, they depend on voltage and temperature.

Yes I know about doing the bootloader to set the fuses to 8 Meg or leave it at 1 Meg but that is not the question

The question is how do I set the tiny so I can get a real time delay of say 3 seconds?
My program says
delay(3000);

and atm I'm getting about a 1 sec delay

If I use the same line on a 328p I get a 3 second delay . Ignore the miniscule differences brought about by voltage or temperature thats just a ridiculous furfy and is totally irrelevant here
I'm not understanding the relevence of the clock speed to the delay function . Can someone point me in the right direction please?

april:
I'm not understanding the relevence of the clock speed to the delay function . Can someone point me in the right direction please?

Simple: The delay() works by counting clock cycles.

The software you load on the chip has to match the clock speed of the chip. If it doesn't you'll get problems like yours.

So...somehow you're not loading the right software.

If you have everything set up properly in the IDE the compiler should choose the right settings for you. If it isn't then you need to check your configuration.

Option (2) is to not use delay() and use the chip's internal timers directly.

april:
Ignore the miniscule differences brought about by voltage or temperature thats just a ridiculous furfy and is totally irrelevant here
I'm not understanding the relevence of the clock speed to the delay function.

You said "exact"...

Hm don't agree with that fully

the 328p is 16 Meg clock speed
the tiny85 is 1 Meg

So I would assume that running the same function delay() a 1 second delay(1000) on the 328p gives 1 second
on a tiny85 I would have thought 16 times longer

That doesn't work though, and I find if I want 10 seconds delay on the tiny85 I must use "delay(20000) which I don't understand.because that is only 2 times as much

april:
So I would assume that running the same function delay() a 1 second delay(1000) on the 328p gives 1 second
on a tiny85 I would have thought 16 times longer

It's not as easy as you think.
The delay() is a function that halts the flow of your code for a certain number of milliseconds. To do that, it reads the value returned by another function, millis(), that itself reads the value of a variabile that is incremented every millisecond or so (it's more complex, but think that this is the way it works). To have the variable incremented, a timer is used. This timer is clocked with a clock that is obtained dividing the system clock with a specific value (the "prescaler"). If you use a clock that is not the original, you will get a variable that is incremented with a frequency that is higher or lower, depending of the situation. Usually there are some calculations that the code do to obtain the correct setups for the timer to get 1000 milliseconds a second: everything is based upon the value of a constant, F_CPU, that tells the compiler the value of the clock. This constant is set in the preferences of the boards inside the boards.txt file.

So, if you don't compile your sketch specifying the correct board, the clock value that will be used won't be correct and your code will run faster or slower.

Also, a tiny without calibration messes a lot the millis function. +/-10%

Check if Serial is working, if not, you need to do the "oscal" thing

eried:
Also, a tiny without calibration messes a lot the millis function. +/-10%

Any chip running with the internal oscillator has a big difference between the nominal clock and the real frequency.
Put 2 or 3 chips on a breadboard, set them to use the internal osc, and load the Blink. You'll see a caotic sequence of flashes just after 5 seconds :stuck_out_tongue_closed_eyes:

leo72:
The delay() is a function that halts the flow of your code for a certain number of milliseconds. To do that, it reads the value returned by another function, millis(), that itself reads the value of a variabile that is incremented every millisecond or so (it's more complex, but think that this is the way it works).I understood that millis()simply counts the milliseconds since reset. Again I would have thought that would be based on clock speed

To have the variable incremented, a timer is used. This timer is clocked with a clock that is obtained dividing the system clock with a specific value (the "prescaler"). If you use a clock that is not the original,(but I am using the original) you will get a variable that is incremented with a frequency that is higher or lower, depending of the situation. Usually there are some calculations ...?...that the code do to obtain the correct setups for the timer to get 1000 milliseconds a second: everything is based upon the value of a constant, F_CPU,( F_CPU is set at 1Mhz on the tiny85 and 16Mhz on the 328p) that tells the compiler the value of the clock. This constant is set in the preferences of the boards inside the boards.txt file.

So, if you don't compile your sketch specifying the correct board (but I have compiled it for the right board , the tiny85 running at 1Mhz or I have the option of choozing 8 Mhz both of which have the correct board.txt files . I have downloaded board files into Arduino to enable me to program the attiny 25/45/85/chips at 1Mhz or 8Mhz. https://github.com/damellis/attiny/zipball/Arduino1 and http://hlt.media.mit.edu/?p=1695
I understand the 8Mhz is obtained with the prescaler and that I must load the bootloader first which does not actually load a bootloader but changes the fuses), the clock value that will be used won't be correct and your code will run faster or slower.

In practice it is working out that I must use twice the delay I would expect when the tiny is set at 1 Mhz. I don't have a rule of thumb yet for the 8Mhz

leo72:

eried:
Also, a tiny without calibration messes a lot the millis function. +/-10%

Any chip running with the internal oscillator has a big difference between the nominal clock and the real frequency.
Put 2 or 3 chips on a breadboard, set them to use the internal osc, and load the Blink. You'll see a caotic sequence of flashes just after 5 seconds :stuck_out_tongue_closed_eyes:

I accept that this might be the case between individual chips . This would be because of the physical construction of the crystal / capacitor combination in each I would suspect?
I don't understand eried's statement about calibration. Do you mean external calibration with crystal capacitor or something else ? The individual chip would still count millis since reset using the clock pulses but that would be different for each chip by say +/- 10% yes?

So this is not actually what I am looking for but rather why is the delay only half of what I expect?
Thats telling me there is something going on which I have not yet grasped

april:
In practice it is working out that I must use twice the delay I would expect when the tiny is set at 1 Mhz.

If you compile for 8 MHz and run the code on a chip clocked at 1 MHz you'll notice that your sketch is slower than you expected, and vice versa.

I don't have a rule of thumb yet for the 8Mhz

If you use the core Tiny you can choose between several clock speeds.
http://code.google.com/p/arduino-tiny/

april:
I accept that this might be the case between individual chips . This would be because of the physical construction of the crystal / capacitor combination in each I would suspect?

Yes, every component has its own tollerances.

I don't understand eried's statement about calibration. Do you mean external calibration with crystal capacitor or something else ? The individual chip would still count millis since reset using the clock pulses but that would be different for each chip by say +/- 10% yes?

Every micro has an internal register that it can be used to calibrate the oscillator: you put a value in it and this value is used to correct the clock. I never used this tecnique since I don't need extrem precision. If you need expreme precision, you have to use specific external components.

So this is not actually what I am looking for but rather why is the delay only half of what I expect?
Thats telling me there is something going on which I have not yet grasped

No idea. What core are you using?

leo72:

april:
In practice it is working out that I must use twice the delay I would expect when the tiny is set at 1 Mhz.

If you compile for 8 MHz and run the code on a chip clocked at 1 MHz you'll notice that your sketch is slower than you expected, and vice versa.You are confusing things by not reading the posts properly .I am not doing so . It is compiled for and run on a 1Mhz attiny85 chip

I don't have a rule of thumb yet for the 8Mhz

If you use the core Tiny you can choose between several clock speeds.
Google Code Archive - Long-term storage for Google Code Project Hosting. core I am using is cited above and is https://github.com/damellis/attiny/zipball/Arduino1 and it is mentioned on the page cited by you for alternative cores

I don't understand eried's statement about calibration. Do you mean external calibration with crystal capacitor or something else ? The individual chip would still count millis since reset using the clock pulses but that would be different for each chip by say +/- 10% yes?

Every micro has an internal register that it can be used to calibrate the oscillator: you put a value in it and this value is used to correct the clock. I never used this tecnique since I don't need extrem precision. If you need expreme precision, you have to use specific external components.I dont need extreme precision . My question is about the fact that the delay on say "delay(10000)" only gives a 5 second delay instead of 10 seconds[/size]

So this is not actually what I am looking for but rather why is the delay only half of what I expect?
Thats telling me there is something going on which I have not yet grasped

No idea. What core are you using?It is posted above[/color]
[/quote]

Leo72 If you don't specifically know why this is then please don't post. The bits you have thrown in do not address the question but rather confuse the issue.

I have said the chip is compiled and run at 1 Mhz as far as I know and the fuses have not been reset as far as I know yet I am only getting half of the expected delay from the "delay()" function.

april:
You are confusing things by not reading the posts properly .I am not doing so . It is compiled for and run on a 1Mhz attiny85 chip

It was an example of what could be happen

the core I am using is above and is https://github.com/damellis/attiny/zipball/Arduino1 and is mentioned on the page cited by you for alternative cores

Never used it.
I don't know if it has frequencies not supported. Did you check the files?

My question is about the fact that the delay on say "delay(10000)" only gives a 5 second delay instead of 10 seconds[/quote
Read above.

Like a lot of AVR MCUs, the ATtiny85 comes from the factory set so that the system clock is provided by the 8MHz internal RC oscillator, and the prescaler is set to divide by 8, so the actual system clock frequency is 1MHz.

When a sketch is compiled, the compiler needs to be told what speed the hardware is set to, in order to provide accurate delays, etc. This is done via the f_cpu parameter in the boards.txt file.

To change the clock speed, the MCU fuse bytes need to be re-programmed. See the datasheet for details.

The appropriate fuse byte values to match f_cpu are also specified in boards.txt (low_fuses, high_fuses, extended_fuses).

By issuing a "burn bootloader" command, the fuse values for the selected board are burned to the MCU. Note in this case "burn bootloader" is a bit of a misnomer since there is no bootloader for a tiny85. (The "burn bootloader" command on an m328 would burn the bootloader as well as the fuse bytes.)

As long as the fuses burned in the MCU match the f_cpu for the selected boards.txt entry, delay(1000) should give a one-second delay with either a 1MHz or 8MHz system clock, so something is amiss here. Your symptoms could be explained if the fuses were set to provide an 8MHz clock, but a 1MHz board was selected in the IDE. Simply changing the board in the IDE does not alter the system clock frequency setting in the hardware. "Burn bootloader" will do that.

april:
The question is how do I set the tiny so I can get a real time delay of say 3 seconds?
My program says
delay(3000);

and atm I'm getting about a 1 sec delay

Three possibilities:

  1. Your fuses are wrong
  2. The board selected in the IDE is wrong.
  3. The files you added to get ATtiny85 support in the IDE are wrong.

Thanks both Fuses must have been wrong Fungus was right all along
Bootloaded 8Mhz to chip then loaded program and delay is now right .

I just wondered Jack is there any power usage difference between running at 8 and 1 Mhz ?

april:
Thanks both Fuses must have been wrong Fungus was right all along
Bootloaded 8Mhz to chip then loaded program and delay is now right .

Good deal!

I just wondered Jack is there any power usage difference between running at 8 and 1 Mhz ?

Yes, generally, the slower the clock, the lower the power consumption. See Figs 22-2 through 22-4 in the datasheet. If my well-calibrated eyeball serves, at 3V, 0.6mA at 1MHz vs. 2.8mA at 8MHz.

april:
Bootloaded 8Mhz to chip then loaded program and delay is now right .

Now I'm a bit confused. When I read this thread I first thought "neglected to program fuses", but when I saw you were running at 1MHz, I thought "no, that wouldn't matter, for 1Mhz/int osc the factory setting for the fuses would be correct anyway."

So first question: How did you think the fuses might have gotten set incorrectly? Second question: You now have it running at 8Mhz OK, but can you get it running at 1MHz after all that?

I'm wondering if the fuse setting in your boards.txt file are incorrect for the attiny85 1MHz option, and that's been the root cause of your issues. In other words, things got screwed up because you did burn the bootloader (i.e., set the fuses), but that set them to an incorrect setting from the boards.txt file!

Can you have a look at the relevant boards.txt file and report what they say for the 1MHz attiny85 fuse config? Might be a bug that needs fixing.

The chip I used was in another device first.
I scavenged it to use here and, when programming it ,I chose the 1 Mhz option and it was out . I tried the 8 Mhz option too and it was out . Then I posted the question.

As it was out on both I thought I had a problem but it turned out that when I did flash the bootloader it came good. Now I don't know what was on the chip when I started but I did d/l and save eeprom and flash to files so if you can read those I'll post them .

EDIT No need , a bit of research on the original device turned up this gem

  1. Change the fuse bits so the ATtiny85 uses 16MHz PLL and divide clock by 8 by running the
    following command:
    avrdude ?p ATtiny85 ?c usbtiny ?U lfuse:w:0x61:m ?

So it was in fact still running at 16Mhz then I think which explains everything if it was ?

april:

  1. Change the fuse bits so the ATtiny85 uses 16MHz PLL and divide clock by 8 by running the
    following command:
    avrdude ?p ATtiny85 ?c usbtiny ?U lfuse:w:0x61:m ?

So it was in fact still running at 16Mhz then I think which explains everything if it was ?

16MHz divided by 8 = 2MHz