Best ATTiny85 Core with updated Wiring-C

Hi All,

I have been using the Arduino Uno R3 for a project I'm building, and I read where you can migrate it all onto an ATTiny85. I picked up a few ATTiny85 20PU chips off of ebay. I tried to move my code to one, after building a shield, but the timing was messed up. So, I adjusted the timing and it seems to work, but now I think my millis are off.. After more research, I read that it might have something to do with millis rollover.

I then read that there is an update to the wiring.c that fixes the millis thing that uses an 'unsigned long' that would solve my problem. The question is, how can I test my theory by using the most updated core. I've tried the one off of google code(Google Code Archive - Long-term storage for Google Code Project Hosting.) and hi low tech (http://highlowtech.org/?p=1229) but these don't seem to do it.

Any thoughts or pointers? Thanks everyone.

p.s. the part that is failing is when I check to see if a button has been pressed for 3 seconds. After 3 seconds it does something.

void loop() {
    int reading = digitalRead(btnpin);
    if (reading == HIGH && millis() - beenpressedsince > 300 ){
      DoTheThing();
    }

    if (reading == LOW)
      {
        lastDebounceTime = 0;
      }
    else
      { 
        beenpressedsince= millis();
        }
}

TU

From the factory AVR processors are configured to run from the internal oscillator divided by 8. For an ATtiny85 the clock speed is 1 MHz.

When you upload your sketch do you have a 1 MHz board selected?

I'm currently using the ATtiny85 @ 16 MHz (internal PLL; 4.3 V BOD)

Board.txt code:

attiny85at16p.name=ATtiny85 @ 16 MHz  (internal PLL; 4.3 V BOD)

attiny85at16p.upload.tool=arduino:arduinoisp

attiny85at16p.upload.maximum_size=8192
attiny85at16p.upload.maximum_data_size=512

# PLL Clock; Start-up time PWRDWN/RESET: 1K CK/14 CK + 4 ms; [CKSEL=0001 SUT=00]
# Brown-out detection level at VCC=4.3 V; [BODLEVEL=100]
# Preserve EEPROM memory through the Chip Erase cycle; [EESAVE=0]
# Serial program downloading (SPI) enabled; [SPIEN=0]

attiny85at16p.bootloader.low_fuses=0xC1
attiny85at16p.bootloader.high_fuses=0xD4
attiny85at16p.bootloader.extended_fuses=0xFF

attiny85at16p.bootloader.path=empty
attiny85at16p.bootloader.file=empty85at16.hex
attiny85at16p.bootloader.tool=arduino:avrdude

attiny85at16p.build.mcu=attiny85
attiny85at16p.build.f_cpu=16000000L
attiny85at16p.build.core=tiny

TinyUser:
I'm currently using the ATtiny85 @ 16 MHz (internal PLL; 4.3 V BOD)

Did you execute Tools / Burn Bootlader after changing the selected board?

No...
didn't try that. I will do it now and see what happens.

Quick update.. Tried it out. Fixed my timing issue, but, the code is still not working.

For the first 5 minutes or so, everything works correctly, then after that, it completely ignores the "millis() - beenpressedsince > 300 " portion of the code and just fires off the "DoTheThing()" command.

Was really hoping that was it.

TinyUser:
No...
didn't try that. I will do it now and see what happens.

Quick update.. Tried it out. Fixed my timing issue, but, the code is still not working.

For the first 5 minutes or so, everything works correctly, then after that, it completely ignores the "millis() - beenpressedsince > 300 " portion of the code and just fires off the "DoTheThing()" command.

It's impossible to help without seeing ALL the code

I totally agree with you on that one, fungus, that's why i'm asking for pointers. Even if I gave you all the code it would be worthless unless you could see the all of the code behind the AVR.

This is why i'm asking for direction instead of the solution.

Thanks!

What @fungus meant to write was, "It's impossible to help without seeing ALL OF YOUR CODE." This should give you some guidance...

http://snippets-r-us.com/

Ahh.. Gotcha.

Here is 'all' the code.

const int switchpin = 1; // pin 6
const int pwmPin = 0;// pin 5
const int indPin = 2;  // secondary indicator pin to let me know it fired
const int nobeam = 0;  // pwmled off
const int lowbeam = 16; //pwmled dim
const int highbeam = 255; // pwmled full on

int ledVal = 16;
int reading = 0;
int msdelay = 400;
int lastDebounceTime;
int hasBlinked;
int lastBlink;
int lightStatus;



void setup() {
  // initialize the digital pin as an output.
  pinMode(pwmPin, OUTPUT);
  pinMode(switchpin, INPUT);

  pinMode(indPin, OUTPUT);
  digitalWrite(indPin, HIGH);
  analogWrite(pwmPin, ledVal);
}

// the loop routine runs over and over again forever:
void loop() {
// 
// 
 
  // set the LED:
void Blink(){
  
    digitalWrite(indPin, HIGH);
     analogWrite(pwmPin, nobeam);
     delay(msdelay);
     analogWrite(pwmPin, highbeam);
     delay(msdelay);
     analogWrite(pwmPin, nobeam);
     delay(msdelay);
     analogWrite(pwmPin, highbeam);
     digitalWrite(indPin, LOW);
     hasBlinked=1;
    //lastDebounceTime = millis();
}
int lastDebounceTime;

int lastBlink;

The time returned by millis() is an unsigned long (32 bits), but you're saving it the lastXXXX that is only an int (16 bits, on AVR. Plus you didn't specify "unsigned", so it's more like 15 bits.))
This will cause various sorts of unexpected behavior. 32768 milliseconds (15bits worth) is only about 33 seconds. (32bits worth of milliseconds is about 5 weeks. And you can actually avoid problems when it runs out, if you're careful. In this case, it's the mismatch between the two types causing the problem, rather than less obvious algorithm problems.

Make all the variables where you store millis() be "unsigned long" instead of int, and your problems should disappear.

(This is likely to be a common mistake for programmers coming from other platforms. On almost any other computer, an "int" is also 32 bits.)

Westfw,

That was exactly it... You are a genius. Thanks for your help!

~TU