Electronics > Atmel and Arduino

Attiny13 with Arduino ISP

(1/5) > >>

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


--- Quote ---> 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)
--- End quote ---

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


--- Quote ---> 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?)
--- End quote ---

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/


--- Quote ---> 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.
--- End quote ---

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.


--- Quote ---> 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
--- End quote ---

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:

--- Quote from: ElectroNick on November 28, 2012, 11:26:57 AM ---
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

--- End quote ---
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) 


--- Quote ---I assume, through a resistor up to the positive

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


--- Quote ---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.

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


--- Quote ---> 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.

--- End quote ---
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   :o

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.


--- Quote from: lefty.crupps on November 29, 2012, 01:06:37 AM ---
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

--- End quote ---
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: ---Arduino : Attiny
10 : 1
11 : 5
12 : 6
13 : 7

--- End code ---
should be correct although I could be wrong, it was a quick 'n dirty list.

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

--- End quote ---
Seems kind of large for a '13!

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

--- End quote ---
Ignore - irreverent.

--- Quote ---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.

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


--- Quote ---Does that wear out my gear? Good to know!
--- End quote ---
It will eventually wear out the flash in the chip but it is good for > 10000 writes. Quite a bit of debugging.

Navigation

[0] Message Index

[#] Next page

Go to full version