[SOLVED] ATTINY45 millis() Problem

Hi Guys, I am a total noob regarding Arduino IDE and coding. In this particular application I’m using an ATtiny45, with some timing functions. Everything works 100% except the maximum timing of 7200000ms (refer line 56). When 100k pot is turned ‘high’ (4.85V on pin2[PB3]), the output on pin 3 [PB4] should stay low for 2h, but it barely makes 1h (average 50 min), then should go high for 2h, but also only goes high for about 50 min. Can someone kindly assist in what I am doing wrong and/or totally misunderstand?

PotTimeOnOff_ATtiny.ino (3.4 KB)

(deleted)

No xtal Drew, use internal 8MHz clock, schematic attached as pdf.

POT TIMER.pdf (34.8 KB)

johanct:
Hi Guys, I am a total noob regarding Arduino IDE and coding. In this particular application I'm using an ATtiny45, with some timing functions. Everything works 100% except the maximum timing of 7200000ms (refer line 56). When 100k pot is turned 'high' (4.85V on pin2[PB3]), the output on pin 3 [PB4] should stay low for 2h, but it barely makes 1h (average 50 min), then should go high for 2h, but also only goes high for about 50 min. Can someone kindly assist in what I am doing wrong and/or totally misunderstand?

Forgot to put UL following those numbers, perhaps?

delay(7200000) may not work, but delay(7200000UL) might ... (forcing number to be unsigned long)

@Rupert909 now I am even more confused - I thought that in this specific application I should stay away from delay() and rather use the millis() function.

   OUTPUT:  Heater SPCO Relay - pin 3 (PB4)
            Halfbridge Signal 1 - pin 5 (PB0)
            Halfbridge Signal 2 - pin 6 (PB1)
            Buzzer - pin 7 (PB2)

Which core are you using?

johanct:
@Rupert909 now I am even more confused - I thought that in this specific application I should stay away from delay() and rather use the millis() function.

Okay. I just took a shot in the blind there, since those "UL"'s are so easy to forget. Sorry.

And you're right, you should definitely not use delay() in this situation! :slight_smile:

Possibly the map() function expects int? Have you tried printing out the result from calling map with these types of values?

May I also complement you on neat and tidy code.

The code is neat and tidy but why do this ?

const int signalPin1 = 0; // select pin for Halfbridge Signal 1 (extend)

then later do this

 digitalWrite(0, HIGH); // Turn on Signal 1 on Pin 5 (PB0)

and not use the name of the pin except in the comment.

It works but is much less easy to follow.

@Rupert909, no apologies needed. I will do a serial print and try and make out what is wrong. Someone else also made a comment over a phone conversation that the map() might overflow internally - I think your suggestion to do a serial print is the next logical step, thanks.

map() uses longs internally

long map(long x, long in_min, long in_max, long out_min, long out_max)
{
  return (x - in_min) * (out_max - out_min) / (in_max - in_min) + out_min;
}

UKHeliBob:
The code is neat and tidy but why do this ?

const int signalPin1 = 0; // select pin for Halfbridge Signal 1 (extend)

then later do this

 digitalWrite(0, HIGH); // Turn on Signal 1 on Pin 5 (PB0)

and not use the name of the pin except in the comment.

It works but is much less easy to follow.

The only excuse I can offer is that I'm a total noob when it comes to coding - maybe if I ad the schematic it will make more sense. I will do a new reply with schematic attached in pdf.

Schematic attached in pdf.

POT TIMER.pdf (34.8 KB)

The only excuse I can offer is that I'm a total noob when it comes to coding

WHat makes it even stranger is that you used the pin names when setting the pinMode()s

  pinMode(relayPin, OUTPUT);  // declare the Relay pin as an OUTPUT
  pinMode(signalPin1, OUTPUT);  // declare the bridge Signal 1 pin as an OUTPUT
  pinMode(signalPin2, OUTPUT);  // declare the bridge Signal 2 pin as an OUTPUT
  pinMode(buzPin, OUTPUT);  // declare the buzzer pin as an OUTPUT

As an aside, the pin numbers could be declared as byte rather than int to save a little memory.

Of course, what is important is that the code works, but it is good to use the best programming practices even in small programs.

Thanks for all the positive criticism @UKHeliBob - I just realized again how little I know. Will go study up on how millis(), map() works in detail and then how declare pin numbers as bytes.

Apart from making the code more readable and cutting down the need for verbose comments, using the pin names throughout makes circuit changes easy to deal with. If the circuit changes to use say pins 0 and 1 in the reverse order then all you have to do is to change the variable declarations rather than hunt through the code looking for use of pin numbers, perhaps missing some.

ATtiny45

Done some of your suggestions, and thanks, it now reads better and if pin needs changing is will be a breeze;

void setup() { 

  pinMode(relayPin, OUTPUT);  // declare the Relay pin as an OUTPUT
  pinMode(signalPin1, OUTPUT);  // declare the bridge Signal 1 pin as an OUTPUT
  pinMode(signalPin2, OUTPUT);  // declare the bridge Signal 2 pin as an OUTPUT
  pinMode(buzPin, OUTPUT);  // declare the buzzer pin as an OUTPUT

  // make sure actuator is retracted
  digitalWrite(signalPin2, HIGH); // Turn on Signal 2 on Pin 6 (PB1)
  delay(750);              // wait for 750ms
  digitalWrite(signalPin2, LOW); // Turn off Signal 2 on Pin 6 (PB1)
  digitalWrite(buzPin, HIGH); // Turn on buzzer on Pin 7 (PB2)
  delay(200);              // wait for 200ms
  digitalWrite(buzPin, LOW); // Turn off buzzer on Pin 7 (PB2)

I also experiment with using "const int ..." vs "byte ..." vs "const byte ..." for declaring pin numbers. Interesting for me was that code size using "const int ..." and "const byte ...", both yielded a code size of 1760 bytes. But, by using "byte ..." increased the code size to 1796 bytes. Settled by using:

// Constants won't change. Used here to set pin numbers:
const byte potPin = 3;  // select the input pin for the 100k pot
const byte relayPin = 4; // select the output pin for the SPCO Relay
const byte signalPin1 = 0; // select output pin for Halfbridge Signal 1 (extend actuator)
const byte signalPin2 = 1; // select output pin for Halfbridge Signal 2 (retract actuator)
const byte buzPin = 2; // select output pin for buzzer

Now back to study map() - & millis() functions to try and sort out my problem.

johanct:
ATtiny45

That is not a core. That is a processor.

I ask the question because pin mappings vary. The problem you are having could easily stem from the simple mistake of using the wrong pin numbers.

Hi @Coding Badly, apologies I don’t know the terminology as I am new to this, thus please enlighten me on what you meant with core?

Regarding the pins, it works with the 2 test coding lines when one of them are un-commented (see pic below of buildup prototype attached):

 // interval = map(interval, 0, 1023, 10000, 2000); // min 2 to max 10s - for testing
  // interval = map(interval, 0, 1023, 1800000UL, 3600000UL); // min 30min to max 60min - for testing

It is only when I un-commented the following line, that I only get 50min instead of 2h on the maximum pot setting:

interval = map(interval, 0, 1023, 1800000UL, 7200000UL); // min 30min to max 120min

PS: I think I know what you meant with “core”: I use under Arduino IDE Tools, Board: ATtiny, Processor: ATtiny45, Clock: 8MHz(internal) - using Additional Boards Manager URL: https://raw.githubusercontent.com/damellis/attiny/ide-1.6.x-boards-manager/package_damellis_attiny_index.json

johanct:
PS: I think I know what you meant with "core": I use under Arduino IDE Tools, Board: ATtiny, Processor: ATtiny45, Clock: 8MHz(internal) - using Additional Boards Manager URL: https://raw.githubusercontent.com/damellis/attiny/ide-1.6.x-boards-manager/package_damellis_attiny_index.json

Precisely.

Assuming the comments from the core are correct...

Your comments are incongruent....

   OUTPUT:  Heater SPCO Relay - pin 3 (PB4)
            Halfbridge Signal 1 - pin 5 (PB0)
            Halfbridge Signal 2 - pin 6 (PB1)
            Buzzer - pin 7 (PB2)

Pin 3 is PB3. So either the heater is connected to the wrong pin or the source code is wrong.

Pin 5 is PB5. So either Signal 1 is connected to the wrong pin or the source code is wrong.

Etcetera.