Well, I managed to use an Arduino UNO as an ISP programmer to get a Arduino bootloader into an ATmega328, so I guess I could use the very same setup for uploading code into an attiny2313.
Now, I installed the Arduino-tiny and the Alternate-Core core files in order to compile some code for the attiny but I always get .hex files bigger than 2KB (which is the maximum an attiny2313 could load).
What am I doing wrong? I tryed compiling the very basic Blink sketch. Is the IDE loading some unnended libraries that make the .hex file so big? What’s going on in the background? I have no clue right now. Any hint/guide/suggestion would be very much appreciated.
Tryed and working fine
Now I can move on with the prototyping ...
Blinking is good but I still have to clear out how to correctly call the attiny2313 pins inside the Arduino IDE.
I modified the blink sketch using "digitalWrite(1, HIGH)" since attiny2313 doesn't have a pin13 (the one used in the original Arduino example) obviously and I've found out the pin 1 corresponds to attiny2313's pin named PD1. I have to assume PD0..PD6 are digital pins 0..6, and PB0..PB7 are analog pins 0..7, right? Sorry, that's still very confused in my mind.
Digged into the arduino-tiny source files for my very first time trying to understand something. It looks like it exposes all attiny2313 pins as digital pins to the Arduino IDE, following this scheme:
But then ... attiny2313's datasheet state that PA0...PA2 are 3bit bidirectional I/O, PB0...PB7 are 8bit I/O and PD0..PD6 are 7bit I/O. I wonder how it all works together ... and, do I have to consider them all working as digital ports only (I doubt that)?
I will write down some code and try it out myself.
But, of course, any hint from the forum gets a big thank you
It looks like it exposes all attiny2313 pins as digital pins to the Arduino IDE, following this scheme
attiny2313's datasheet state that...
Ah, there it is: the Overview / Pin Descriptions section.
All digital I/O pins on AVR processors can be accessed as a "port". On the 2313 processor, three pins are connected to port A, eight pins to port B, and seven pins to port D. In an Arduino sketch, the "ports" can be read using a "PIN" variable...
ValueOfPortA = PINA;
Some digital I/O pins on AVR processors can also be accessed directly using bit manipulation instructions.
But, you needed worry about any of that. pinMode, digitalRead, digitalWrite, and the GCC compiler manage all of those details.
Thank you man for the clarification. I’m testing it all by myself right now, I’m figuring out what the source means and how it works in practice with a few simple input/output tests.
I didn’t have much time for that but … so far I’ve tested digital and analog output.
The only pin not working as expected is the PA2 (D17) which should work as a digital output too, but it doesn’t. In my schematics it’s the tiny’s Reset that gets connected to Arduino’s Digital10. I tested a simple led blink on it (like with the other pins) with and without leaving it connected to Digital10 … no luck, the led stays off There’s obviously a reason I don’t know about.
The only pin not working as expected is the PA2 (D17) which should work as a digital output too, but it doesn't. In my schematics it's the tiny's Reset that gets connected to Arduino's Digital10.
The PA2 can be either RESET --or-- a digital I/O pin; it cannot be both. It's function is determined by a fuse setting. In order to program the processor with the equipment you have, PA2 must be left as RESET. If PA2 is changed to a digital I/O pin, the only way to reprogram the processor is: "high voltage" programmer or, I believe, debugWIRE. In other words, if PA2 is changed to a digital I/O pin, you will have to buy a dedicated programmer.