Attiny13 with Arduino ISP

[ElectroNick]

I'm just moving this post by lefty.crupps from the blog comments so we can have a better structured discussion:

> If you used either smeezekitty’s or Damellis’es cores, you don’t need adjusting pin
> assignments in the core – they are already properly mapped. You just need to make sure
> you refer to the proper numbered B port I/Os (which Arduino calls D – D0 through D5)

I don’t know exactly what that means, but I’ve not changed anything in the cores files and I’ve wired the ATtiny13 like this:
ATtiny Pin1 – Uno Pin10
ATtiny Pin4 – Ground
ATtiny Pin5 – Uno Pin11
ATtiny Pin6 – Uno Pin12
ATtiny Pin7 – Uno Pin13
ATtiny Pin8 – 5v DC (VCC) Pin

> Anyhow, post your sketch here so we can see and let us know how the LED is hooked up -
> which pin on the ATtiny13 (and then, I assume, through a resistor up to the positive
> power rail, right?)

I am just opening the Examples > Blink option and changing the LED from Pin 13 to Pin 4; I then have an LED on D4 (ATtiny13 pin 3) through a resistor to the rail. I’ve learned about the ‘Burn Bootloader’ and that’s helped remove errors in the compiling, but the LED is still solidly lit. I don’t think it’s going slow nor fast, I think it isn’t timing correctly as that one post mentioned, in the iotn13.h file
https://tekstop.wordpress.com/2011/12/30/programming-attiny13-using-arduino-isp-and-all-the-hacking-involved/

> Note that you really need to avoid using D5 (pin #1) if you want to (easily) reprogram
> the ATTiny through ISP – it’s also the reset pin.

Avoid it, at which point? For general use? or for programming? I’m not avoiding it during programming, as I noted above. I’ve tried removing all connections after the sketch is uploaded, other than power, ground, and the LED, but no fix.

> I’ve just remembered another thing: make sure you use the “Burn Bootloader”
> function before uploading your sketch – I know if sounds counter-intuitive
> because ATtiny13 does not have a bootloeader

I’ve learned to do this, but it isn’t counter-intuitive to me — this is all new and none of it is intuitive! The D ports, the B I/O, none of it makes much sense right now. I’m working on it.

Thanks so much for the help so far… I’d be happy to move this all to the forum if you’d prefer.

Still so close, so so close…

[ElectroNick]

I’ve wired the ATtiny13 like this:
ATtiny Pin1 – Uno Pin10
ATtiny Pin4 – Ground
ATtiny Pin5 – Uno Pin11
ATtiny Pin6 – Uno Pin12
ATtiny Pin7 – Uno Pin13
ATtiny Pin8 – 5v DC (VCC) Pin

Perhaps it may be easier at this point to refer to those pins as digital input/output (I/O) numbers used in Arduino sketches:

So, when you write something like digitalWrite(0,LOW);, the "0" stands  for digital pin 0, which in the standard Arduino library maps to a hardware pin called PD0 a.k.a. I/O Port D, pin 0. This just happens to be pin 2 on the actual Atmega168 IC chip but you never actually connect to the chip itself on the Uno board - you connect to the Uno using the numbering that's already "translated" from the chip pin numbers to Arduino C numbers.

Enter the ATTiny13. This time you need to connect to the actual chip since there's no development board between you and the MCU. Thus you need to know the hardware pin assignments, "un-translated" so to speak. Note that neither smizkitty's nor Damellis'es cores have their own translation table (it would be in the pins_arduino.c files distributed with the cores but this file is an empty placeholder in both ATtiny13 cores)  and therefore they use the standard Arduino translation table, which is designed for a much larger Atmega168 chip.

So, if you've written  digitalWrite(0,LOW); , you would still be addressing "Port D, Pin 0. But ATtiny13 is a tiny    IC, it does not have a Port D! All it has is 6xI/Os in Port B.

Still with me? This is where the mapping comes together: if you are using a core that does not have its own pin translation table (and, to complicate the  matters, the MIT core does!), you have to address the pins as you would address the corresponding pins of the proper port  on a large Atmega168 chip. In other words, Port B, Pin 0 on Atmega168 chip is "Digital Pin 8", and so in order to light an LED connected to ATtiny13 hardware pin 5 (Port B, pin 0)   you need to write digitalWrite(8,LOW);.

So:

Pin 5 -> Port B, pin 0 -> digitalWrite(8,LOW);
Pin 6 -> Port B, pin 1 -> digitalWrite(9,LOW);
Pin 7 -> Port B, pin 2 -> digitalWrite(10,LOW);
Pin 2 -> Port B, pin 3 -> digitalWrite(11,LOW);
Pin 3 -> Port B, pin 4 -> digitalWrite(12,LOW);
Pin 1 -> Port B, pin 5 -> digitalWrite(13,LOW);

(note: this mapping only works with cores using standard Arduino pin/port numbering. MIT tiny core re-maps the pins to a more convenient D0=0 numbering) 

I assume, through a resistor up to the positive

I still assume the other leg of the LED is up, which is why I wrote the command as digitalWrite(13,LOW);

I am just opening the Examples > Blink option and changing the LED from Pin 13 to Pin 4; I then have an LED on D4 (ATtiny13 pin 3) through a resistor to the rail.

ATtiny13 pin 3 > Port B, pin 4 -> digital output 12 -> digitalWrite(12,LOW);

> Note that you really need to avoid using D5 (pin #1) if you want to (easily) reprogram
> the ATTiny through ISP – it’s also the reset pin.

Avoid it, at which point? For general use? or for programming? I’m not avoiding it during programming, as I noted above. I’ve tried removing all connections after the sketch is uploaded, other than power, ground, and the LED, but no fix.

I meant, avoid using in your projects, just pretend you only have 5 I/Os, most especially for those projects still in development where you need to reprogram the chip many times using ISP.   The Pin #1 is also the Reset and it's needed for ISP operation. By default, it is not available as PB5 (D5) - it's a reset by default, that's why ISP works on a brand new chip. You can burn the proper fuse and make it a PB5 but then you won't be able to program this chip in-circuit with ISP. You'd have to remove it from the circuit and program it in a specialized high-voltage programmer. It's still technically re-programmable but a PITA, that's why I said avoid pin 1.

Good luck! Please post about your progress here! I'm most curious to see the actual project that eventually comes out. The project-bragging section of the forum is here: http://elabz.com/forums/post-your-projects/   

[lefty.crupps]

You just blew my mind   

Thanks so much for the explanation!  I had to go off and read a bit about the various Ports
http://www.circuitstoday.com/inputoutput-ports-and-tris-registers-in-pic-16f877
but I think I have a good idea now.  The Arduino people provided a nice map for the ATmega168
http://arduino.cc/en/Hacking/PinMapping168 or
http://blog.elenika.net/?p=25

I realize now, I was way off with my wiring. (11pm)
OK I have it rewired (11.30), I think:

• AT Pin1 - Uno Pin13 (PB5)
  AT Pin2 - Uno Pin11 (PB3)
  AT Pin3 - Uno Pin12 (PB4)
  AT Pin4 - Ground
  AT Pin6 - LED  > 560Ω > Ground (PB1; Uno Pin9)
  AT Pin7 - Uno Pin10 (PB2)
  AT Pin8 - 5V (Vcc)

(FWIW, I was going along with this Make video which is a totally different chip, I now understand:
http://blog.makezine.com/2011/10/10/how-to-shrinkify-your-arduino-projects/
I got my new PB_ info from the data sheet for my chip.)

Now i am getting the error below for my Blink (Pin9) example sketch and i can't upload it:
Binary sketch size: 654 bytes (of a 1,024 byte maximum)
avrdude: please define PAGEL and BS2 signals in the configuration file for part ATtiny13
avrdude: stk500_recv(): programmer is not responding

A new bootloader won't burn either:
avrdude: stk500_recv(): programmer is not responding
I'm also unsure about the speed I should have my bootloader burned at, using the boards.txt that's quoted in the original article.

> most especially for those projects still in development where you need to reprogram the
> chip many times using ISP
Does that wear out my gear? Good to know!

I gotta be done for the night.  Thanks all for the eyeballs and assistance.  Now more than ever, so close! 

[ElectroNick]

L.C., just a quick reply before I investigate this a bit further:

I have to precede everything I write below by saying that I did not use Arduino ISP myself, I used a different ISP programmer device  - AVRISP MKII - but the principal of ATtiny13 programming should be the same. What certainly isn't the same here is the fact that you need to properly configure 2 different Arduino sketches: one to load the programming software into the Arduino UNO so it becomes an ISP programmer, and after that another, which is now loaded into the ATTiny13 (but not into the UNO!). Another big difference is that the first sketch you would load using "File->Upload" in Arduino IDE, the second:  "File->Upload Using Programmer". Otherwise you'll end up uploading ATtiny sketch into the UNO - not a good idea.

I'm pretty sure your issues are at the Arduino ISP level now, not ATtiny13 ( programmer is not responding is pretty explicit in this sense)

I need to read up on Arduino ISP docs to see if the connections you used are proper pins that Arduino ISP program expects but I can tell you right now that the Pin 6 which you are trying to blink an LED on is actually used in ATtiny13 as the ISP signal MISO , which tells me that your ISP connection between UNO and Tiny could not work - one of the important 4 signals is missing!  Make sure you connect the ATtiny to the proper pins on UNO  and if you want to blink an LED without breaking the ISP connection every time (I would) - use pins 2 or 3 - they aren't used in ISP and so you can setup your ISP wires, your LED, your +5V and GND and play with it all day long without touching any wires. You could use the same pins for both LED and ISP but it's safer to have them on separate pins, especially when you have two extra pins you can use that aren't part of the ISP.

I'll try to post more info here once I figure out for myself the Arduio ISP sketch - never needed to use it before but you got me intrigued.

Good luck!

[smeezekitty]

The requirement of an 8 character password for the Forum is pretty annoying!
I tend to keep it at 7 char normally.

Thanks so much for the explanation!  I had to go off and read a bit about the various Ports
http://www.circuitstoday.com/inputoutput-ports-and-tris-registers-in-pic-16f877
but I think I have a good idea now.  The Arduino people provided a nice map for the ATmega168
http://arduino.cc/en/Hacking/PinMapping168 or
http://blog.elenika.net/?p=25

The pin mapping still seems suspicious (and overcomplicated) IMO.

• AT Pin1 - Uno Pin13 (PB5)
  AT Pin2 - Uno Pin11 (PB3)
  AT Pin3 - Uno Pin12 (PB4)
  AT Pin4 - Ground
  AT Pin6 - LED  > 560Ω > Ground (PB1; Uno Pin9)
  AT Pin7 - Uno Pin10 (PB2)
  AT Pin8 - 5V (Vcc)

Still looks wrong.
Follow the pinout here http://hlt.media.mit.edu/?p=1229

Code: [Select]

Arduino : Attiny
10 : 1
11 : 5
12 : 6
13 : 7
should be correct although I could be wrong, it was a quick 'n dirty list.

Binary sketch size: 654 bytes (of a 1,024 byte maximum)

Seems kind of large for a '13!

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

Ignore - irreverent.

avrdude: stk500_recv(): programmer is not responding[/color]

A new bootloader won't burn either:
avrdude: stk500_recv(): programmer is not responding
I'm also unsure about the speed I should have my bootloader burned at, using the boards.txt that's quoted in the original article.

* Make sure the boards.txt uses the ArduinoISP
* Check the chip wiring
* Make sure the ArduinoISP sketch is written to the Arduino

Does that wear out my gear? Good to know!

It will eventually wear out the flash in the chip but it is good for > 10000 writes. Quite a bit of debugging.

[lefty.crupps]

Hello people, thanks again for the assistance.  Today is Friday and I won't be able to look at this again until Monday, but I'd still appreciate the assistance!

The pin mapping still seems suspicious (and overcomplicated) IMO.

I was wiring PB1 to PB1, etc.  I wasn't aware of the MISO and MOSI and SCK pins, but I've since learned a bit about them.  I followed your wiring scheme and I understand why it is that way, other than the 'reset' going to 10.

Code: [Select]

Arduino : Attiny
10 : 1
11 : 5
12 : 6
13 : 7I did that and I think I understand why:
-MOSI to MOSI,
-MISO  to MISO,
-SCK to SCK.
The PB_ pins are used in the sketch itself (well, their translated pins to the ATmega168) but PB_ etc are not used to push a program to ATtiny13, is that right?  MISO and MOSI are used to push the program onto the ATtiny13.  Yes?


This is still not working for me. These are my current steps, am I missing something?
1, open Arduino software, select Board > Uno.  Select Examples > Arduino as ISP.  Select Programmer >   (what should this be for the default, to interact with Arduino as if it were new?).  Upload 'Arduino as ISP' to the Arduino.

2, Wire up my ATtiny13 according to the pins listed above.  Add a 20uF capacitor to Arduino's Reset > Ground pins to prevent a reset.

3, Select Board > ATtiny13 @ 9.6MHz, change Programmer > Arduino as ISP.  Select 'Burn Bootloader' to fuse the clock speed.  Not sure what that means for my programs, but I'm going with it.

4, Add LED+Resistor to ATtiny13 Pin2 (BP3).  Open Examples > Blink, change to Pin11 (Arduino's Pin11 aka PB3 aka ATtiny13 Pin2, yes?)

5, File > Upload using Programmer

This does upload (same useless error messages) but I don't get any blinking behaviour; the LED is dark.  If I pull ATtiny P4 (Ground), the LED lights up, still no blink.  If I change the Example to Pin12 (PB4) and rewire my LED to ATtiny P3 (PB4) and reload the sketch, I get the same behaviour (dark while grounded).

[smeezekitty]

Sorry if I missed it before but, which core are you using?

I was wiring PB1 to PB1, etc.  I wasn't aware of the MISO and MOSI and SCK pins, but I've since learned a bit about them.  I followed your wiring scheme and I understand why it is that way, other than the 'reset' going to 10.

Code: [Select]

Arduino : Attiny
10 : 1
11 : 5
12 : 6
13 : 7I did that and I think I understand why:
-MOSI to MOSI,
-MISO  to MISO,
-SCK to SCK.
The PB_ pins are used in the sketch itself (well, their translated pins to the ATmega168) but PB_ etc are not used to push a program to ATtiny13, is that right?  MISO and MOSI are used to push the program onto the ATtiny13.  Yes?

Yes except the PB pins double as standard I/O pins when not programming.

4, Add LED+Resistor to ATtiny13 Pin2 (BP3).  Open Examples > Blink, change to Pin11 (Arduino's Pin11 aka PB3 aka ATtiny13 Pin2, yes?)

Uhh...I think you should change it to the PB number. For example if the LED is on PB3, change the pin to 3.

This does upload (same useless error messages) but I don't get any blinking behaviour; the LED is dark.  If I pull ATtiny P4 (Ground), the LED lights up, still no blink.  If I change the Example to Pin12 (PB4) and rewire my LED to ATtiny P3 (PB4) and reload the sketch, I get the same behaviour (dark while grounded).

Do you mean only the undefined signal message? If so, then the problem is probably just a software issue now.

[ElectroNick]

Sorry if I missed it before but, which core are you using?

Smeezekitty, it is a great question! I was wondering about that myself. Especially considering the different hardware pin mappings between these cores.

However, I just looked at my own Arduino IDE setup and have to admit: I would not be able to tell which core is used that easily either. Arduino pulls up and mixes together two boards.txt files:  one from the subdirectory under where the Arduino executable is located and another in ~/sketches (I'm using Linux version but I think the same principal applies in Win). Gotta be very careful with that, and I wasn't - I have same file/directory  names in both locations and not sure which one takes preference when Arduino IDE starts up and looks for boards.txt file(s).

Anyhow, I was going to reproduce lefty.crupps'es setup but will need some time to sort out different cores for different chips. I think it would make perfect sense to use the core names in the boards.txt in addition to the chip name and the clock speed because some of the cores overlap in the chips they cover. So, by the time lefty.crupps confirms which core is being used, hopefully I will have all of them properly labeled 

Thanks for your input!

Cheers!

[ElectroNick]

Damn it, it was a bummer of a day! 

I tried to put together this setup with Arduino ISP since I used only AVRISP programmer before.
I've uploaded a blink sketch (it didn't work - the LED was constantly ON). Then I recalled that I did not burn fuses and hit the "Burn Bootloader" without realizing it was on 128kHz and this is where all hell broke loose. I did not look at which fuse exactly I burned, so I though I lost connection to ATtiny because  it's now too slow. Turns out the Arduino IDE 1.x.x no longer honors the attiny13.upload.speed=250 directive! It always tries to communicate at 19200, regardless of the actual setting. What gives? I remember this setting working in 1.0 ...

Anyway, I tried burning fuses back with avrdude and set proper speed there but still no cigar

Code: [Select]

avrdude -v -v -v -v -c stk500v1 -P/dev/ttyUSB0 -p attiny13 -b250 -U lfuse:w:0x7a:m -U hfuse:w:0xff:m
gives 

Code: [Select]

avrdude: stk500_getsync(): not in sync: resp=0xf0
output and nothing works.

Then I looked at the actual fuse I burned and it turned out I had 
attiny13.bootloader.low_fuses=0x6B where I should have had attiny13.bootloader.low_fuses=0x68 (internal 128kHz clock)

So, I needed an external clock. There's a version of Arduino ISP with extenal "recovery clock". Put it in, the clock goes on Attiny13 pin 2 (external clock input) - burning  still  does not work!

The worst part is that I don't have another Attiny13 to check lefty.crupps'es setup.

Anyway, the chip seems to be lost to me - don't know what happened to it, nothing I did seemed to do the trick. If anyone has any suggestion, I'm all ears. I'll see what else I can do - perhaps order a couple of Attiny13s, which unfortunately takes time.

[smeezekitty]

Code: [Select]

avrdude: stk500_getsync(): not in sync: resp=0xf0
output and nothing works.

Then I looked at the actual fuse I burned and it turned out I had 
attiny13.bootloader.low_fuses=0x6B where I should have had attiny13.bootloader.low_fuses=0x68 (internal 128kHz clock)

So, I needed an external clock. There's a version of Arduino ISP with extenal "recovery clock". Put it in, the clock goes on Attiny13 pin 2 (external clock input) - burning  still  does not work!

The worst part is that I don't have another Attiny13 to check lefty.crupps'es setup.

Anyway, the chip seems to be lost to me - don't know what happened to it, nothing I did seemed to do the trick. If anyone has any suggestion, I'm all ears. I'll see what else I can do - perhaps order a couple of Attiny13s, which unfortunately takes time.

Actually 0x?B is correct for the internal oscillator but 0x6B is the 128khz oscillator with the clock divide by 8 in place giving ~16khz...Ouch!

It may be possible to recover it with this http://pastebin.com/Aw5BD0zy but that is really slow so this is untested at this speed.

[ElectroNick]

It may be possible to recover it with this http://pastebin.com/Aw5BD0zy but that is really slow so this is untested at this speed.

Thanks, Smeezekitty, I'll be sure to give it a try tonight. Is this what they call "smeezekitty's slow SPI Arduino ISP version" on Arduino forums? I loaded and compiled it fine in Artduino 1.0.2 but I'm not sure how you control the actual SPI clock: the line

Code: [Select]

//  SPI.setClockDivider(SPI_CLOCK_DIV128);
is commented out, can you give a hint?

Thanks a lot!

[ElectroNick]

Smeezekitty saves the day! The slow(er) SPI Arduino ISP did work. I had to run it several times though - the first time I attempted to burn the 4.8MHz internal clock fuse, it ran and appeared to have set some clock/divider because the LED started blinking albeit very slowly (I think a divider was set because it did look like it's 8 times slower than expected). I don't believe it was one of the high MHz ones though - all the uploads would end in error and, weird enough, the device was reporting its ID  almost correctly - avrdude was expecting 0x1e9007 for ATtiny13 but was getting something like 0x1e9000 one time, then 0x1F007 another time - it was always off by only one or two bits, which looked rather promising compared to the completely dead ATtiny before. The burning of the actual sketch did not work at this stage yet.

So, I kept trying to burn bootloader for the three clock speeds I had defined in the boards.txt  (128K, 4.8M, 9.6M) and one of the attempts to burn 4.8MHz clock (bootloader.low_fuses=0x69) finally "clicked" and burned it properly. It started accepting normal sketch uploads and the blink sketch works (blinks  ) with expected frequency.

In analyzing my errors yesterday, I would say it's pretty important to check the boards.txt file(s) for the first time you select an MCU with a particular clock speed or other fuse bit configurations. I had a typo in it all along, but never actually tried that speed before and it bit me in the least expected moment.

Also, I think my attempts to use the slow SPI Arduino ISP firmware might have been successful quicker had I not been too lazy to attach a good source of 5V external power to the Attiny13. I've used what my Arduino Duemilanove put out (powered via USB, behind a passive USB hub and on a long cable) and it was 4.7V. I wonder if 5.0V would make a difference in burning the fuses properly for the first time.

So, the hardware issues cleared, I can now post a response to lefty.crupps about his original issues. 

Once again,  thanks Smeezekitty!
 

[ElectroNick]

Lefty, I fixed my own setup I was trying to build to duplicate what's you've done, so I can take a closer look at what's going on.

The pin mapping still seems suspicious (and overcomplicated) IMO.

YES! If you are using Smeezekitty's code (core13), its pin remapping is done in a different file  which I didn't realize until I looked closer into it. Forget about everything I said in my previous  reply  and just use pins 0 through 4 (the 5 is still Reset needed for ISP) as the corresponding I/O numbers in the digitalWrite command. Same has always applied for the MIT core (not for Tiny13, which it does not support bur other Tinies). I've yet to double-check the Damellis'es core which I ended up deleting last night.
My apologies for the confusion!

Here it is, again (for core13 and MIT cores)

Pin 5 -> Port B, pin 0 -> digitalWrite(0,LOW);
Pin 6 -> Port B, pin 1 -> digitalWrite(1,LOW);
Pin 7 -> Port B, pin 2 -> digitalWrite(2,LOW);
Pin 2 -> Port B, pin 3 -> digitalWrite(3,LOW);
Pin 3 -> Port B, pin 4 -> digitalWrite(4,LOW);
Pin 1 -> Port B, pin 5 -> digitalWrite(5,LOW);

I followed your wiring scheme and I understand why it is that way, other than the 'reset' going to 10.

You are talking about Arduino Uno's Pin 10 connected to Attiny13 Pin 1, right? Just making sure. It's needed for ISP operation

Code: [Select]

Arduino : Attiny
10 : 1
11 : 5
12 : 6
13 : 7

The PB_ pins are used in the sketch itself (well, their translated pins to the ATmega168) but PB_ etc are not used to push a program to ATtiny13, is that right?  MISO and MOSI are used to push the program onto the ATtiny13.  Yes?

Well, we're still talking about ATtiny13's MISO and MOSI (and SCK and Reset), right? I am double checking because two MCUs are involved and both have these inputs. However, they are only connected strictly that way on the chip being programmed (Attiny13). The outputs of the Arduino Uno board are rather arbitrary (well, almost). Please note that Arduino ISP sketch makes  (optional) use of three other outputs for connecting to  status LEDs. I did find them very useful when it died on me yesterday - perhaps you may want to plug them in as well.  They are described in the header of the Arduino ISP sketch:

Code: [Select]

// Put an LED (with resistor) on the following pins:
// 9: Heartbeat - shows the programmer is running
// 8: Error - Lights up if something goes wrong (use red if that makes sense)
// 7: Programming - In communication with the slave

This is still not working for me. These are my current steps, am I missing something?
1, open Arduino software, select Board > Uno.  Select Examples > Arduino as ISP.  Select Programmer >   (what should this be for the default, to interact with Arduino as if it were new?). 

Nothing is needed to be setup if you are uploading your sketches to the Uno itself - it does not use a programmer. 

Upload 'Arduino as ISP' to the Arduino.

2, Wire up my ATtiny13 according to the pins listed above.  Add a 20uF capacitor to Arduino's Reset > Ground pins to prevent a reset.

3, Select Board > ATtiny13 @ 9.6MHz, change Programmer > Arduino as ISP.  Select 'Burn Bootloader' to fuse the clock speed.  Not sure what that means for my programs, but I'm going with it.

Are you getting any error messages at this point? If not, you've just verified that both Arduino ISP sketch as well as your wiring between the Uno and the Attiny is OK.
 

4, Add LED+Resistor to ATtiny13 Pin2 (BP3).  Open Examples > Blink, change to Pin11 (Arduino's Pin11 aka PB3 aka ATtiny13 Pin2, yes?)

Once again, sorry for confusion. It should have been Pin 3 (see the table above) 

5, File > Upload using Programmer

This does upload (same useless error messages) but I don't get any blinking behaviour; the LED is dark.  If I pull ATtiny P4 (Ground), the LED lights up, still no blink.  If I change the Example to Pin12 (PB4) and rewire my LED to ATtiny P3 (PB4) and reload the sketch, I get the same behaviour (dark while grounded).

Other than the pin number mismatch, everything so far looks  fine to me. I am assuming you did not get any error messages after burning the bootloader.

 Just in case: here is the blink sketch I used:

Code: [Select]

/*
  Blink
  Turns on an LED on for 1/2 second, then off for 1/2 second, repeatedly.
 
  This example code is in the public domain.
 */
int j; // just a counter
void setup() {               

   pinMode(3, OUTPUT);   
   
}

void loop() {
  digitalWrite(3,HIGH);
  delay(500); //wait for 0.5 sec
  digitalWrite(3, LOW);   // set the LED on
  delay(500); //wait for 0.5 sec

}

So, check the pin numbers and give it another try, you seem to be pretty close to success! Please update us on your progress.

Cheers!
 

[lefty.crupps]

Wow, quite the ordeal that you went through!  happy to read that you got your setup working again.  and thanks for the help!

I've reset this up and I’m still not getting the blink.  I used the exact posted sketch at the end of the last post, but no blink.  I can change the LEDs around on the ATtiny13 and only the one that I specify will go HIGH (or LOW if I swap the lines:

Code: [Select]

pinMode(3, OUTPUT);   
   
}

void loop() {
  digitalWrite(3,LOW);
  delay(500); //wait for 0.5 sec
  digitalWrite(3, HIGH);   // set the LED on; Never gets this far
  delay(500); //wait for 0.5 sec
)  It's as if the delay() doesn't work or digitalWrite() doesn't end or something.  Arg.


As for 'What Cores?', I have the following text from the original post in a boards.txt file:

Code: [Select]

###########################################################################
 
attiny13.name=Attiny13 @ 128 KHz (internal watchdog oscillator)
 
attiny13.upload.using=arduino:arduinoisp
# attiny13.upload.protocol=avrispv2
# attiny2313at1.upload.using=pololu
 
attiny13.upload.maximum_size=1024
attiny13.upload.speed=250 # important for not losing connection to a slow processor
 
attiny13.bootloader.low_fuses=0x7B
attiny13.bootloader.high_fuses=0xFF
 
attiny13.bootloader.unlock_bits=0x3F
attiny13.bootloader.lock_bits=0x3F
 
attiny13.build.mcu=attiny13
attiny13.build.f_cpu=128000
attiny13.build.core=core13
 
###############################################################
 
attiny13at4.name=ATtiny13 @ 4.8MHz (internal 4.8 MHz clock)
attiny13at4.bootloader.low_fuses=0x69
attiny13at4.bootloader.high_fuses=0xff
attiny13at4.upload.maximum_size=1024
attiny13at4.build.mcu=attiny13
attiny13at4.build.f_cpu=600000
#
attiny13.build.core=arduino:arduino
attiny13.build.variant=tiny8

#attiny13at4.build.core=core13
###############################################################
 
attiny13.name=ATtiny13 @ 9.6MHz (internal 9.6 MHz clock)
attiny13.bootloader.low_fuses=0x7a
attiny13.bootloader.high_fuses=0xff
attiny13.upload.maximum_size=1024
attiny13.build.mcu=attiny13
attiny13.build.f_cpu=9600000L
attiny13.build.core=arduino:arduino
attiny13.build.variant=tiny8
###########################################################################
I would not doubt if those are an issue, but no idea.  It's from the original post about the ATtiny13 and the Arduino.  The first one (Attiny13 @ 128 KHz) doesn't even show up in my list; the bootloader only burns with the option:

Code: [Select]

attiny13.name=ATtiny13 @ 9.6MHz (internal 9.6 MHz clock)
Do you think I need a constant 5V power supply?  I should try that... not right now tho.  Thanks so much for all the help.

[smeezekitty]

Also, I think my attempts to use the slow SPI Arduino ISP firmware might have been successful quicker had I not been too lazy to attach a good source of 5V external power to the Attiny13. I've used what my Arduino Duemilanove put out (powered via USB, behind a passive USB hub and on a long cable) and it was 4.7V. I wonder if 5.0V would make a difference in burning the fuses properly for the first time.

Should be not problem. The '13 is happy at 4.7 volts which is well within datasheet tolerances. The ISP sketch I posted uses software ISP so it is completely adjust down to several hundred milliseconds per bit if necessary. Perhaps it would have worked first time if you increased the delays from the default of 50uS.

I have even programmed an attiny powered by 2v with 5v logic even though the violates the datasheet    The Atmel chips are fairly hard to blow up in my experience. (LOL my spell check suggested Oatmeal for Atmel!)

Glad it is working. Looking forward to see how it turns out with the question originator. Hopefully they do not get discouraged by the issues.

I really  need to hook up the Tiny13 again and start development again. I think I may have spotted a potential bug albeit minor.

We still do not know which core they are using.