Attiny projects?

Please tell us more :slight_smile:

D

It's the little chip that can.

;D

I assume you mean the datasheet for the attiny85 on the OSCCAL values?

Yes. Keep the datasheet close at hand. Tiny Tuner provides you with an OSCCAL value. It's up to you to do something with that value.

I installed the cores through links to the site from other posts, I didn't realize that was your site.

I'm trying to keep it from becoming "my site". Anyone want to contribute / help?

Installing it all was a breeze

Excellent!

I'm hoping programming the 85 will be as simple

I think it is. From a software perspective, the core should make working with the 85 very similar to working with a 168 or 328. The big thing lacking are libraries. Most (all?) Arduino libraries will not work as-is on the tiny processors.

Hopefully I'll get the first done soon and I'll post it up!

Please do.

I love the 85, so much so I've built an emulator for it. (CB, got PCBs the other day and have half written a monitor program.)

Nice! Is it the PCB you published in the Hardware / Development section? Did you make any changes from what you published? Did you farm out the PCBs or etch them yourself?

Is it the PCB you published in the Hardware / Development section?

Yep.

Did you make any changes from what you published?

Quite a few actually, the emulator is now affectively an Arduino clone (if I get it all working that is :)). To save from highjacking this thread here's a link to the details.

http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1286853922/0#5

and the web site

http://emul8or.robgray.com/index.php

Did you farm out the PCBs or etch them yourself?

Thought I'd try PCBcart in China, they did a great job.


Rob

sigh, I've spent the past hour unsuccessfully programming my 85. I am using the arduinoisp with my uno, windows 7. When I upload the sktech to the arduino the "communicating with slave" led blinks really fast, then the "error" pin blinks a few times, then the "heartbeat" led goes back to doing it's thing. ?In the arduino ide it just says uploading to board... and hangs there until i disconnect the usb cable to the uno. Any help?

edit: is the pinout for "your" arduino tiny85 file the same as the one from high low tech? I wrote the blink program to run pin 0, but now I'm wondering if it might be pinned differently

sigh, I've spent the past hour unsuccessfully programming my 85

Bummer.

I am using the arduinoisp with my uno, windows 7

Have you disabled the auto-reset?

If I remember correctly, it is necessary to modify the boards.txt file so the Arduino IDE uses the correct programmer. Have you done this?

edit: is the pinout for "your" arduino tiny85 file the same as the one from high low tech? I wrote the blink program to run pin 0, but now I'm wondering if it might be pinned differently

Pin mapping...
http://hlt.media.mit.edu/wiki/pmwiki.php?n=Main.ArduinoATtiny4585

Here is the boards.txt from my sketchbook folder, just the secion for the atiny85 @ 8mhz.

attiny85at8.name=ATtiny85 @ 8 MHz

# The following do NOT work...
# attiny85at8.upload.using=avrispv2
# attiny85at8.upload.using=Pololu USB AVR Programmer

# The following DO work (pick one)...
 attiny85at8.upload.protocol=avrispv2
#attiny85at8.upload.using=pololu

attiny85at8.upload.maximum_size=8192
attiny85at8.upload.speed=19200

# Default clock (slowly rising power; long delay to clock; 8 MHz internal)
# Int. RC Osc. 8 MHz; Start-up time PWRDWN/RESET: 6 CK/14 CK + 64 ms; [CKSEL=0010 SUT=10]; default value
# Brown-out detection disabled; [BODLEVEL=111]
# Preserve EEPROM memory through the Chip Erase cycle; [EESAVE=0]

attiny85at8.bootloader.low_fuses=0xE2
attiny85at8.bootloader.high_fuses=0xD7
attiny85at8.bootloader.extended_fuses=0xFF
attiny85at8.bootloader.path=empty
attiny85at8.bootloader.file=empty85at8.hex

attiny85at8.bootloader.unlock_bits=0xFF
attiny85at8.bootloader.lock_bits=0xFF

attiny85at8.build.mcu=attiny85
attiny85at8.build.f_cpu=8000000L
attiny85at8.build.core=tiny

I hooked the reset pin up to 5v power through two 220 ohm resistors in parallel, is that what you were referring to by discabling auto reset?

It looks like the Arduino ISP implements the "stk500v1" protocol. Try changing this...

# The following DO work (pick one)...
 attiny85at8.upload.protocol=[glow]avrispv2[/glow]
#attiny85at8.upload.using=pololu

...to this...

# The following DO work (pick one)...
 attiny85at8.upload.protocol=[glow]stk500v1[/glow]
#attiny85at8.upload.using=pololu

I hooked the reset pin up to 5v power through two 220 ohm resistors in parallel, is that what you were referring to by disabling auto reset?

Yes. When you try to upload to the 85, the bootloader on the Arduino should not run.

Okay...I changed the boards.txt to stk500v1, and it worked! Uploaded the blink sketch successfully and tested it. Then I tried the fade sketch, and I got

avrdude: please define PAGEL and BS2 signals in the configuration file for part ATtiny85
avrdude: verification error, first mismatch at byte 0x0008
         0x47 != 0x45
avrdude: verification error; content mismatch

Then I tried to go back to the blink, and get the same error. I unplugged everything and closed the IDE, even rewrote the ISP sktech to the uno. Same error, tried a second attiny85, loaded the first sketch fine, then got the error uploading the second sketch... any advice?
I read that a noisy power supply could have caused this, so I installed a 10 uF cap to filter the power with no change, all in a breadboard, no soldering... I just find it odd that I can upload one sketch but not another...

Okay...I changed the boards.txt to stk500v1, and it worked!

Excellent!

Uploaded the blink sketch successfully and tested it.

Also excellent!

Then I tried the fade sketch, and I got
Code:avrdude: please define PAGEL and BS2 signals in the configuration file for part ATtiny85

I believe that particular error can be ignored.

To "fix" this problem, you need a newer version of the AVRDUDE.CONF file (or you can modify the one you have). In my case, I'm using the latest version of WinAVR. It was easy to get working and solves a few other problems.

avrdude: verification error, first mismatch at byte 0x0008
0x47 != 0x45
avrdude: verification error; content mismatch

That problem will have to be addressed. Unfortunately, it is not one I've ever encountered so I will only be able to offer general advice.

Then I tried to go back to the blink, and get the same error. I unplugged everything and closed the IDE, even rewrote the ISP sktech to the uno.

That was a good first step. You've confirmed that the "programmer" is very likely not the problem.

Same error, tried a second attiny85, loaded the first sketch fine, then got the error uploading the second sketch...

That was a good second step.

any advice?

Yes. Try again with no "devices" (LEDs in your case) connected to the target (the 85 processor). It is very important that the programmer and target are able to drive the three ISP lines to VCC (five volts). Any load on the pin (like an LED) can be a problem (a piezo with no resistor wreaks havoc). Once you have a working setup, you will be able to experiment with what loads you can get away with.

In addition, make certain that you've wired everything correctly, there are no loose connections, and that the wires aren't "too long" (a few inches is good; a few feet is OK; a few yards is bad).

I read that a noisy power supply could have caused this, so I installed a 10 uF cap to filter the power with no change, all in a breadboard, no soldering...

Are you powering the target (85) from the programmer (Arduino)? How is the programmer powered? USB?

In the long term, you will want to include a 0.1uF capacitor across GND and VCC on the 85 processor as close to the processor as possible. The processor will run fine without it (you don't need to add it now) but it dramatically reduces the digital noise (e.g. the analog-to-digital converter behaves much better).

I just find it odd that I can upload one sketch but not another...

That is odd.

I have disconnected the LED everytime I've tried to program it. The uno is powered by usb. I tried using a 9v battery connected to a 5v 1 amp regulator, with two 10uf caps, one right at the regulator, one right next to the leads for the 85. I'm using premade jumper wires, longest one is about 6 inches. I did not change any wires at all between the first and second sketch except for the one for the positive leg of the led. I removed the uno and then uploaded a simple sketch to the uno, and it worked. Reloaded the isp sketch, same error. I am going to reset this laptop just for kicks....

So, I tried a 3rd attiny85, I uploaded the blink program twice successfully. Then, without touching any wires except for disconnecting the LED leg from pin 0, I uploaded the fade sketch, then got the same error. I can't load anymore sketches to the 85, so apparently something in the fade sketch is causing the error...I don't know enough about the actual behind the scenes stuff, does anything seem potentially fatal in this code? I've used it on my uno as is, just with a different pin number.

/*
 Fade
 
 This example shows how to fade an LED on pin 9
 using the analogWrite() function.
 
 This example code is in the public domain.
 
 */
int brightness = 0;    // how bright the LED is
int fadeAmount = 5;    // how many points to fade the LED by

void setup()  { 
  // declare pin 9 to be an output:
  pinMode(0, OUTPUT);
} 

void loop()  { 
  // set the brightness of pin 9:
  analogWrite(0, brightness);    

  // change the brightness for next time through the loop:
  brightness = brightness + fadeAmount;

  // reverse the direction of the fading at the ends of the fade: 
  if (brightness == 0 || brightness == 255) {
    fadeAmount = -fadeAmount ; 
  }     
  // wait for 30 milliseconds to see the dimming effect    
  delay(30);                            
}

can't load anymore sketches to the 85, so apparently something in the fade sketch is causing the error

That's very unlikely. The programmer holds the target in reset while the program is uploaded. There really is no way the existing program can cause a problem.

This...

avrdude: please define PAGEL and BS2 signals in the configuration file for part ATtiny85

...is next. Locate your "avrdude.conf" file. It should be here...

  {ArduinoRoot}\hardware\tools\avr\etc

Make a backup copy in case something goes wrong.

Open the file in your favorite text editor.

Search for "ATtiny85".

Replace the ATtiny85 section with this...

#------------------------------------------------------------
# ATtiny85
#------------------------------------------------------------

part
     id            = "t85";
     desc          = "ATtiny85";
     has_debugwire = yes;
     flash_instr   = 0xB4, 0x02, 0x12;
     eeprom_instr  = 0xBB, 0xFF, 0xBB, 0xEE, 0xBB, 0xCC, 0xB2, 0x0D,
                   0xBC, 0x02, 0xB4, 0x02, 0xBA, 0x0D, 0xBB, 0xBC,
                   0x99, 0xE1, 0xBB, 0xAC;
## no STK500 devcode in XML file, use the ATtiny45 one
     stk500_devcode   = 0x14;
##  avr910_devcode   = ?;
##  Try the AT90S2313 devcode:
     avr910_devcode   = 0x20;
     signature        = 0x1e 0x93 0x0b;
     reset            = io;
     chip_erase_delay = 4500;

     pgm_enable       = "1 0 1 0  1 1 0 0    0 1 0 1  0 0 1 1",
                        "x x x x  x x x x    x x x x  x x x x";

     chip_erase       = "1 0 1 0  1 1 0 0    1 0 0 x  x x x x",
                        "x x x x  x x x x    x x x x  x x x x";

    timeout            = 200;
    stabdelay            = 100;
    cmdexedelay            = 25;
    synchloops            = 32;
    bytedelay            = 0;
    pollindex            = 3;
    pollvalue            = 0x53;
    predelay            = 1;
    postdelay            = 1;
    pollmethod            = 1;

    hvsp_controlstack   =
        0x4C, 0x0C, 0x1C, 0x2C, 0x3C, 0x64, 0x74, 0x66,
        0x68, 0x78, 0x68, 0x68, 0x7A, 0x6A, 0x68, 0x78,
        0x78, 0x7D, 0x6D, 0x0C, 0x80, 0x40, 0x20, 0x10,
        0x11, 0x08, 0x04, 0x02, 0x03, 0x08, 0x04, 0x00;
    hventerstabdelay    = 100;
    hvspcmdexedelay     = 0;
    synchcycles         = 6;
    latchcycles         = 1;
    togglevtg           = 1;
    poweroffdelay       = 25;
    resetdelayms        = 1;
    resetdelayus        = 0;
    hvleavestabdelay    = 100;
    resetdelay          = 25;
    chiperasepolltimeout = 40;
    chiperasetime       = 0;
    programfusepolltimeout = 25;
    programlockpolltimeout = 25;

     memory "eeprom"
         size            = 512;
        paged           = no;
        page_size       = 4;
         min_write_delay = 4000;
         max_write_delay = 4500;
         readback_p1     = 0xff;
         readback_p2     = 0xff;
         read            = "1  0  1  0   0  0  0  0    0 0 0 x  x x x a8",
                           "a7 a6 a5 a4  a3 a2 a1 a0   o o o o  o o o o";

         write           = "1  1  0  0   0  0  0  0    0 0 0 x  x x x a8",
                           "a8 a6 a5 a4  a3 a2 a1 a0   i i i i  i i i i";

      loadpage_lo      = "  1   1   0   0      0   0   0   1",
                    "  0   0   0   0      0   0   0   0",
                    "  0   0   0   0      0   0  a1  a0",
                    "  i   i   i   i      i   i   i   i";

      writepage      = "  1   1   0   0      0   0   1   0",
                    "  0   0   x   x      x   x   x  a8",
                    " a7  a6  a5  a4     a3  a2   0   0",
                    "  x   x   x   x      x   x   x   x";

      mode            = 0x41;
      delay            = 6;
      blocksize      = 4;
      readsize      = 256;
       ;
     memory "flash"
         paged           = yes;
         size            = 8192;
         page_size       = 64;
         num_pages       = 128;
         min_write_delay = 4500;
         max_write_delay = 4500;
         readback_p1     = 0xff;
         readback_p2     = 0xff;
         read_lo         = "  0   0   1   0    0   0   0   0",
                           "  0   0   0   0  a11 a10  a9  a8",
                           " a7  a6  a5  a4   a3  a2  a1  a0",
                           "  o   o   o   o    o   o   o   o";

         read_hi         = "  0   0   1   0    1   0   0   0",
                           "  0   0   0   0  a11 a10  a9  a8",
                           " a7  a6  a5  a4   a3  a2  a1  a0",
                           "  o   o   o   o    o   o   o   o";

         loadpage_lo     = "  0   1   0   0    0   0   0   0",
                           "  0   0   0   x    x   x   x   x",
                           "  x   x   x  a4   a3  a2  a1  a0",
                           "  i   i   i   i    i   i   i   i";

         loadpage_hi     = "  0   1   0   0    1   0   0   0",
                           "  0   0   0   x    x   x   x   x",
                           "  x   x   x  a4   a3  a2  a1  a0",
                           "  i   i   i   i    i   i   i   i";

         writepage       = "  0  1  0  0   1   1   0  0",
                           "  0  0  0  0  a11 a10 a9 a8",
                           " a7 a6 a5  x   x  x  x  x",
                           "  x  x  x  x   x  x  x  x";

      mode            = 0x41;
      delay            = 6;
      blocksize      = 32;
      readsize      = 256;
       ;
#   ATtiny85 has Signature Bytes: 0x1E 0x93 0x08.
     memory "signature"
         size            = 3;
         read            = "0  0  1  1   0  0  0  0   0  0  0  x   x  x  x  x",
                           "x  x  x  x   x  x a1 a0   o  o  o  o   o  o  o  o";
       ;
       
     memory "lock"
         size            = 1;
         write           = "1 0 1 0  1 1 0 0  1 1 1 x  x x x x",
                           "x x x x  x x x x  1 1 i i  i i i i";
         read            = "0 1 0 1  1 0 0 0  0 0 0 0  0 0 0 0",
                           "0 0 0 0  0 0 0 0  o o o o  o o o o";
        min_write_delay = 9000;
        max_write_delay = 9000;
       ;

     memory "lfuse"
         size            = 1;
         write           = "1 0 1 0  1 1 0 0  1 0 1 0  0 0 0 0",
                           "x x x x  x x x x  i i i i  i i i i";

         read            = "0 1 0 1  0 0 0 0  0 0 0 0  0 0 0 0",
                           "x x x x  x x x x  o o o o  o o o o";
        min_write_delay = 9000;
        max_write_delay = 9000;
       ;

     memory "hfuse"
         size            = 1;
         write           = "1 0 1 0  1 1 0 0  1 0 1 0  1 0 0 0",
                           "x x x x  x x x x  i i i i  i i i i";

         read            = "0 1 0 1  1 0 0 0  0 0 0 0  1 0 0 0",
                           "x x x x  x x x x  o o o o  o o o o";
        min_write_delay = 9000;
        max_write_delay = 9000;
       ;

     memory "efuse"
         size            = 1;
         write           = "1 0 1 0  1 1 0 0  1 0 1 0  0 1 0 0",
                           "x x x x  x x x x  x x x x  x x x i";

         read            = "0 1 0 1  0 0 0 0  0 0 0 0  1 0 0 0",
                           "x x x x  x x x x  o o o o  o o o o";
        min_write_delay = 9000;
        max_write_delay = 9000;
     ;

     memory "calibration"
         size            = 2;
         read            = "0  0  1  1   1  0  0  0    0 0 0 x  x x x x",
                           "0  0  0  0   0  0  0  a0   o o o o  o o o o";
     ;
  ;

Save and close the file.

Restart the Arduino IDE.

Try again with one of the first three processors.

I've tried copying that code three times and using two different text editors, I always get this error

avrdude: error at {arduino root}\arduino-0021\hardware/tools/avr/etc/avrdude.conf:8801: invalid bit specifier "0 0"

edit: just out of curiosity I upgraded to arduino 0022, still getting the verification error.

Argh! The tabs have been eaten!

I sent you a Personal Message with a link to my copy of the file. Please give that a try.

Now I get this error lol:
error at {arduino root}\arduino-0022\arduino-0022\hardware/tools/avr/etc/avrdude.conf:320 unrecognized character: "a"

is it possible this is caused by using the uno as an isp(the verification error, not the avrdude.conf errors)? Would it be worth my time to buy the pololu? Or do I need to fgure out this error before deciding?

with the 84 I reverted back down to version 19, aside from the "please define" errors it worked fine once (after killing the serial support)

since then I have not been able to upload via the ide, but avrdude provided from the winavr package works fine, though I am using 16MHZ clock on the chip (22 has delay issues, 19 has serial issues)

In all honesty every single time I go to a non mega x8 chip its this big drama hassle of fiddlefarting around getting version X to work with core Y, my advice is to not touch the darn thing once you have it running and make a backup, I didnt and pissed away a better part of the day getting blink to upload 2 times in a row :stuck_out_tongue:

Now I get this error lol:
error at {arduino root}<mark>arduino-0022\arduino-0022\hardware/tools/avr/etc/avrdude.conf:320 unrecognized character: "a"

I assume there is only one "arduino-0022" in the path.

I have emailed you a ZIP file and sent you a link to the same ZIP file via Personal Message. There are two subdirectories in the ZIP file. Try the configuration file in the "1" directory first. If that does not work, try the configuration file in the "2" directory.

is it possible this is caused by using the uno as an isp(the verification error, not the avrdude.conf errors)?

It is possible. But, there are people who have successfully used an Arduino as an ISP. In fact, most AVR programmers are implemented using an AVR processor.

So, the wiring, the RESET, the breadboard (the external hardware) are more likely to be the culprit.

Would it be worth my time to buy the pololu?

I'm a big fan of the Pololu programmer. It has worked almost flawlessly so far. Adding male pins has made it very handy to use with a breadboard.

Or do I need to fgure out this error before deciding?

That's the route I would take but I would also place a time limit on the effort.

since then I have not been able to upload via the ide

How very strange. My route has been the opposite. I had all sorts of trouble getting the IDE to upload and now that's the only method I use. I wonder if I've left somthing out of the core...

on that note I think it has something to do with the core and 16MHZ operation, not really this specific issue

though once you get any core working its almost necessary to not touch it, I attribute that to the constant dicking around in non broken parts of the released core files from the official team