Strange behaviour using Delay function for ATtiny85

The delay function with the ATtiny85 gives strange results when I use it in a circuit that doesn’t require much accuracy.
Pins 2,3,6 & 7 are connected to headers where a link can connect any one of them to ground for different delays. It is essentially a simple method of stopping a water flow if the main timer goes faulty or is wrongly set. The system works OK as it is only used (probably never) as a fail safe method to stop a water tank being emptied. However, I would still like to find out why there is little relationship between the delay(xxx) and the actual measured times shown commented in the code.

void setup() {
  pinMode(0, OUTPUT); //power to pin 5 of ATtiny85
  pinMode(1, INPUT_PULLUP); // for pin 6 of ATtiny85
  pinMode(2, INPUT_PULLUP); // for pin 7 of ATtiny85
  pinMode(3, INPUT_PULLUP); // for pin 2 of ATtiny85
  pinMode(4, INPUT_PULLUP); // for pin 3 of ATtiny85
  pinMode(5, INPUT_PULLUP); // for pin 1 of ATtiny85 Not used for timing

  digitalWrite(0, HIGH); // To pin 5. Enable power to pump and solenoid
  
  //Test which setting for desired delay
  if   (digitalRead(1) == LOW) { //pin 6
    delay(300000); //approx 40 min as measured
  }
  if   (digitalRead(2) == LOW) { //pin 7
    delay(50000); //approx 10 min
  }
  if   (digitalRead(3) == LOW) { // pin 2
    delay(20000); //approx 9 min as measured
  }
  if   (digitalRead(4) == LOW) { // pin 3
    delay(15000); //approx 2 min as measured
  }
   digitalWrite(0, LOW);//To pin 5.Disable power to pump and solenoid
}

void loop() {
}

The Tools settings are as follows:
Board ATtiny25/45/85
Chip ATtiny85
Clock 8MHz (internal)
BOD level: BOD Disabled
Save EEPROM: EEPROM retained
Timer 1 Clock: CPU
LTO(1.6.11 + only); Disabled

I can use this system as is but am puzzled by the results. Maybe someone has some clues as to why the times and delay don’t correlate.

Ooops!! I forgot to burn the bootloader for 8MHz. I was confident that after this was done all would make sense, however apart from a scaling factor of 8 the "strange behaviour" continued.

It appears that grounding PB4 (pin 3) or PB1 (pin 6) give correct results as expected by their associated delays but grounding PB3 (pin 2) or PB2 (pin 7) give delay results with almost no relevance to their expected delays.

Maybe it is something to do with the fact that PB3 is used when an external XTAL is used (I have used the Internal 8MHz clock) but not sure why PB2 would be affected by being grounded.

Anyway, this behaviour is not a show stopper but I would like to know why I get these results???

Which tiny core do you use?

Gaggymoon: The delay function with the ATtiny85 gives strange results when I use it in a circuit that doesn't require much accuracy. Pins 2,3,6 & 7 are connected to headers where a link can connect any one of them to ground for different delays. It is essentially a simple method of stopping a water flow if the main timer goes faulty or is wrongly set. The system works OK as it is only used (probably never) as a fail safe method to stop a water tank being emptied. However, I would still like to find out why there is little relationship between the delay(xxx) and the actual measured times shown commented in the code.

void setup() {
  pinMode(0, OUTPUT); //power to pin 5 of ATtiny85
  pinMode(1, INPUT_PULLUP); // for pin 6 of ATtiny85
  pinMode(2, INPUT_PULLUP); // for pin 7 of ATtiny85
  pinMode(3, INPUT_PULLUP); // for pin 2 of ATtiny85
  pinMode(4, INPUT_PULLUP); // for pin 3 of ATtiny85
  pinMode(5, INPUT_PULLUP); // for pin 1 of ATtiny85 Not used for timing

 digitalWrite(0, HIGH); // To pin 5. Enable power to pump and solenoid    //Test which setting for desired delay  if   (digitalRead(1) == LOW) { //pin 6    delay(300000); //approx 40 min as measured  }  if   (digitalRead(2) == LOW) { //pin 7    delay(50000); //approx 10 min  }  if   (digitalRead(3) == LOW) { // pin 2    delay(20000); //approx 9 min as measured  }  if   (digitalRead(4) == LOW) { // pin 3    delay(15000); //approx 2 min as measured  }   digitalWrite(0, LOW);//To pin 5.Disable power to pump and solenoid }

void loop() { }




The Tools settings are as follows:
Board ATtiny25/45/85
Chip ATtiny85
Clock 8MHz (internal)
BOD level: BOD Disabled
Save EEPROM: EEPROM retained
Timer 1 Clock: CPU
LTO(1.6.11 + only); Disabled


I can use this system as is but am puzzled by the results. Maybe someone has some clues as to why the times and delay don't correlate.

Pin 1 is reset. How are you using "pinmode" on it?

krupski: Pin 1 is reset. How are you using "pinmode" on it?

Physical pin1, yes.

That will be PB5 -> Arduino pin 5. The question applies for that.

Willem.

From the above comments, maybe the following code line is the problem:

pinMode(5, INPUT_PULLUP); // for pin 1 of ATtiny85 Not used for timing

I will delete this line and connect pin 1 through a 10k resistor to Vcc (to stop it developing an arbitrary level) and observe if this fixes the problem. I am not in a position currently to try this out but will when the opportunity arises.

Thanks

Gaggymoon: From the above comments, maybe the following code line is the problem:

pinMode(5, INPUT_PULLUP); // for pin 1 of ATtiny85 Not used for timing

I will delete this line and connect pin 1 through a 10k resistor to Vcc (to stop it developing an arbitrary level) and observe if this fixes the problem. I am not in a position currently to try this out but will when the opportunity arises.

Thanks

I'm a bit confused. In order to use pin 1 as an I/O you need to change a fuse setting which then prevents using the ICSP function of the device. I'd love to know how you are making it work at all.

Your attempts to write/configure PB5 are ignored by the hardware because you have not fused that pin to act as a GPIO pin (my core does not support doing this through the IDE); it's acting as a reset pin, not an I/O pin. When acting as a reset pin, the internal pullup is always enabled.

There is no issue with using the crystal pins as gpio when using internal oscillator as clock source.

Does putting UL after the constants fix it? (eg, delay(50000UL); ) I thought the compiler was smart enough to not try storing a constant that won't fit in an int as an int though...

All good now.

Just deleting the line below fixed the problem. pinMode(5, INPUT_PULLUP); // for pin 1 of ATtiny85 Not used for timing

All delays are now as expected.

I guess I treated pin 1 as I normally would for unused pins by trying to stop it from floating but didn't consider the fact that it was a reset pin thus causing these strange effects and as DrAzzy wrote "When acting as a reset pin, the internal pullup is always enabled."

Thanks to all who contributed.