Arduino translated to AVR?

Yes!! It works!! thank you so so much for your help.

Excellent! You are welcome!

Drc3p0:
One more question... Is there a reference chart for the sketch size limitations for the different attiny's?

The most reliable source is the "datasheet". This is how I get Atmel datasheets...

https://www.google.com/
• Enter the full processor model: attiny45v in your case
• Restrict the search to the Atmel site: site:atmel.com
• A link to the datasheet is often on the first page...
http://www.atmel.com/Images/doc2586.pdf

Memory sizes are on the first page but in an annoying format...

2/4/8K is the size given for Flash
• On the right side, past the vertical line, is a list of models: ATtiny25/V ATtiny45/V ATtiny85/V
• The ATtiny45/V is second in the list so the second number (4) is the total Flash (in K)
• An Uno has about 32K of Flash available so the ATtiny45/V has 8 times less storage for code

128/256/512 is the size given for SRAM
• The second number, 256, is the storage available for data (in bytes)
• An Uno has 2K of SRAM available so the ATtiny45/V has 8 times less storage for data

I'm hoping to use an attiny45v for a particular sketch i've written, but I don't know what the size limitation is.

When you Verify (compile) your sketch, something like this is displayed in the status window...

  Binary sketch size: 304 bytes (of a 4,096 byte maximum)

If the "binary sketch size" is less than 4096, there is a high probability the code will fit. If the size is a bit over 4096, there may be some things you can do to whittle it down to 4096.

Determining if the data will fit often has to be done by-hand. The task is made more time consuming by the fact that "static SRAM" is not included in the status.

I also know that there's 2 different versions of the attiny45v. Does an attiny reference chart exist?

I'm not aware of a chart highlighting the differences (but such a thing would certainly be nice).

"Speed grades" ("V" versus non-"V") are also on the first page of the datasheet and they are also in an annoying format...

Speed Grade
– ATtiny25V/45V/85V: 0 – 4 MHz @ 1.8 - 5.5V, 0 - 10 MHz @ 2.7 - 5.5V
– ATtiny25/45/85: 0 – 10 MHz @ 2.7 - 5.5V, 0 - 20 MHz @ 4.5 - 5.5V

Basically, the "V" model can operate at a lower voltage (as low as 1.8 volts) but the maximum speed is limited to 10MHz. If your application will be battery powered, the "V" model is an excellent choice.

The IC I want seems like it might be discontinued? it says there's only 24 left and none on order. hmmm. My main thing is that I need at least 3 PWM outputs. the attiny85v only has 2, so I was going to go with the attiny84v.... http://www.mouser.com/ProductDetail/Atmel/ATTINY84V-10PU/?qs=x9Fa6eo0USnynhfIznoQQA%3D%3D

any suggestions?

Drc3p0:
The IC I want seems like it might be discontinued? it says there's only 24 left and none on order. hmmm.

Naw. That's the way production goes with Atmel's DIP processors. They make a big production run, wait for inventory to reach a certain (very low) level, then schedule the next production run. From scheduled production to actual delivery seems to take several weeks to a few months. The "V" processors (ATtiny85V and family; ATtiny84V and family) seem to be on an especially slow track. You just have to purchase about a six month supply when you can.

If inventory on the processor you want is at 24 I suggest making a decision within two days. The last time I was in that position I waited too long and had to purchase at a higher price. Be sure to check http://www.digikey.com and http://avnetexpress.avnet.com. Every once in a while one of the three big vendors will have a "can't resist" low price.

My main thing is that I need at least 3 PWM outputs. the attiny85v only has 2,

Nope. It has three.

so I was going to go with the attiny84v.... http://www.mouser.com/ProductDetail/Atmel/ATTINY84V-10PU/?qs=x9Fa6eo0USnynhfIznoQQA%3D%3D

Let's see... the t84 has four PWM outputs.

any suggestions?

For general use, you really can't go wrong with either processor. I use the t85 when I can and the t84 when I need more pins. Other than that, any member of either family is a good choice.

looking on findchips.com (great site btw) digikey has almost 1000 of them, verical has like 5150 of them for a great price but you got to get them in lumps of 50

I was hoping to get the price break at 25 IC's. If I can figure out how to use the attiny85v then i'd much rather just go that route!

I'll have to check the data sheet... I've been referencing the hi-low tech page about the attiny's, which lists only 2 PWM outputs for pinout image http://hlt.media.mit.edu/?p=1229

The datasheet states that the attiny45/85v has 2 High Frequency PWM Outputs with Separate Output Compare Registers

Is there a hidden 3rd PWM output?

Drc3p0:
The datasheet states that the attiny45/85v has 2 High Frequency PWM Outputs with Separate Output Compare Registers http://www.atmel.com/Images/2586s.pdf
Is there a hidden 3rd PWM output?

I warned you about that page. :wink:

8-bit Timer/Counter with Prescaler and Two PWM Channels

8-bit High Speed Timer/Counter with Separate Prescaler
• 2 High Frequency PWM Outputs with Separate Output Compare Registers

One timer with two PWM channels and a second timer with 2 high frequency PWM outputs for a total of four. Unfortunately, two of the outputs are on the same physical pin so only three outputs can be active at any one time.

Atmel AVR datasheets are filled with subtlety. You have to check "1. Pin Configurations" to determine that two of the outputs overlap (look for pin labels that start with "OC").

Drc3p0:

[quote author=Coding Badly link=topic=108797.msg827806#msg827806 date=1339785867]Nope. It has three.

I'll have to check the data sheet... I've been referencing the hi-low tech page about the attiny's, which lists only 2 PWM outputs for pinout image[/quote]

Alessandro Saporetti's core had support for two PWM outputs. I believe the diagram and documentation are from his core.

The hardware (essentially) has three PWM outputs and the Tiny Core support supports all three. I have no idea if the current HLT core has support for two or three.

I am going to be controlling a RGB LED Via PWM so how would I be able to control all three outputs at the same time? What pins would be used for PWM? I am trying to understand your explanation

The PWM pins are...

PB4, physical pin 3, digital pin 4, third pin down on the left side
PB0, physical pin 5, digital pin 0, fourth pin down on the right side
PB1, physical pin 6, digital pin 1, third pin down on the right side

Basically, add a u[/u] label to the pin just above GND on the diagram you posted...

Just like on a typical Arduino board, analogWrite is used to change the PWM output...

analogWrite( 0, 127 );
analogWrite( 1, 127 );
analogWrite( 4, 127 );

I'll definitely utilize the attiny85v vs. the attiny84v, now that I know that the extra PWM pin is available. I find it odd though that it isn't clearly stated though.

once again, Thank you for your help!

You are welcome! I hope your project goes well!

I'm having some difficulty with Pin 4 of the AVR being used for PWM. The sketch i'm using cycles through different RGB light patterns, so I have an RGB led wired up to digital pins 0,1,and 4. The LED on pin 4 stays on the entire time. It should be flashing in rhythm to the pattern in the sketch. The sketch works fine with an atmega328. I'm using digitalWrite. Does it need to be analogWrite instead?

I just changed all of the digitalWrite to analogWrite, and now its just pulsating on one LED and won't switch between any of the patterns. I tested it on the atmega and it works properly. I have checked the pinouts to make sure they were correct. Maybe there are some differences between the atmega/avr that i'm not taking into consideration?

I just wanted to leave this forum post in a resolved format. The issues I was experiencing was due to the sketch being too large...it required too much ram, which I later resolved due to some coding cleanup. Thanks so much for all of your help!

Yes - thanks a lot! After spending hours trying to program my Attiny85, it now works perfectly. And without any capacitor between reset and ground.

I wish this info was more readily available so people could stop wasting time making it work. I installed the IDE recently, why isn't the ArduinoISP updated with your (or another working) version?

PS. Is there a solution to the heartbeat problem? I really like that function :slight_smile:

Thanks again - you made my day!
Martin

marlar:
Yes - thanks a lot! After spending hours trying to program my Attiny85, it now works perfectly.

You are welcome. I'm glad you found this thread.

And without any capacitor between reset and ground.

It works better with the capacitor (~ one second faster uploads).

I wish this info was more readily available so people could stop wasting time making it work. I installed the IDE recently, why isn't the ArduinoISP updated with your (or another working) version?

I have asked (more than once) for the ArduinoISP sketch to be fixed. I suspect they don't believe me that the problem persists.

At this point, you will have to ask the folks in charge. The Developers List is a reasonable contact method...
http://arduino.cc/mailman/listinfo/developers_arduino.cc

AND/OR, You can try creating an issue...

PS. Is there a solution to the heartbeat problem? I really like that function :slight_smile:

Change the heartbeat code to blink-without-delay.

I use this; it's much bigger but it has lots of goodies...

Do you mean by using this principle?

Yes.

My take on all the ARduino ISP problems is that the real problem is that
the HardwareSerial buffer down in the core code is
not large enough to hold a full command buffer from avrdude.
The buffer in the sketch is an attempt to work around this limitation in the core code.
In fact, if the core code buffer was larger, ArduinoISP would not have to re-buffer the data
and could simply pull it directly from HardwareSerial as needed.

avrdude will wait 5 seconds for a command to complete and during page write commands
it waits for a command to complete before it sends the next command.
You would think that 5 seconds is long enough to allow the sketch to do
anything goofy it wants to do including goofy 10's of millisecond delays to flicker an LED.

HOWEVER......

Avrdude will send a flash page size of bytes of data (128 bytes for a mega328) plus
4 bytes of command header and 1 byte of sync-EOP-CRC for a total of 133 bytes.
The HardwareSerial RX buffer is not that large.
It used to be 128 bytes, now in the 1.x core it is only 64 bytes.
By having an RX buffer that is smaller than the size of the total bytes that avrdude sends on a command,
it means that the sketch must always drain the HardwareSerial buffer while avrdude is still squirting it out.
Because of the way the sketch code is written, it has trouble doing it.
It was easier to keep up in pre 1.x since the core buffer was nearly large enough at 128 bytes.
Now that the core code buffer is much smaller (64 bytes),
the sketch struggles to keep up given what it is doing and the way it is doing things.
The goofy 20ms delay in heartbeat() doesn't help - in fact it really hurts particularly
with only a 64 byte RX buffer.

loop() calls heartbeat() which delays for 20ms.
Given it is called in the loop and there really isn't much else in the loop other than a check
on Serial.available() is very likely that this will delay processing any RX characters.
If you are running a baud rate of 38400 or beyond, that 20ms delay is guaranteed to
overflow the 64 byte RX buffer down in HardwareSerial before the sketch even gets
a chance to start looking at the bytes much less extracting them.

If the RX buffer down in the core code were large enough for the entire avrdude command,
the baud rate is no longer a factor and the sketch could take up to 5 seconds to process it,
since avrdude will not send more than 1 command at time.
It would also mean that the sketch wouldn't have to re-buffer the data and things
could get a bit simpler in the sketch and timing within the sketch
would no longer be an issue other than slowing down the burn speed.

However the HardwareSerial buffer isn't large enough.

After ArduinoISP finally "notices" a STK_PROG_PAGE command
ArduinoISP eventually calls fill() which will copy characters from HardwareSerial
into buff[] by calling getch() which calls Serial.read()
The problem is fill() wants all the expected data bytes
and getch() will wait FOREVER if there is no character to read.
So if a byte is dropped/lost down in HardwareSerial due to a rx buffer overrun
because the sketch isn't keeping up, ArduinoISP hangs in a loop in fill()
potentially forever waiting for all the date bytes it expects from the PROG_PAGE command.
Now both ends are waiting on each other.
avrdude times out after 5 seconds and will try to get back in sync by sending
a GET_SYNC command - again waiting 5 seconds for a response.
Things continue like this for up to 33 retries to get back in sync.
Meanwhile the ArduinoISP sketch can still be out of sync with avrdude
as it could be hung in its fill() routine
since it is waiting for the full data bytes from the PROG_PAGE command.

ArduinoISP simply isn't very robust with respect to recovering from lost serial data.

A simple fix would be to bump the size of the buffer down in the HardwareSerial core code to be 256 bytes
(even if only temporarily to build the sketch and then change it back).
This would allow the sketch to run "as is" including with the goofy current heartbeat() delays.

There are smarter ways to fix HardwareSerial permanently so it can continue to work on the multi port
AVRs, but it requires fixing more of the HardwareSerial
core code to do things like not use the same size buffer on RX and TX and vary the buffer sizes depending on the number
of serial ports and use some smarter weak functions to allow eliminating ram buffers for serial ports
that are not used.
An even better solution would be to allow the sketch to declare the HardwareSerial constructors
which could define the buffer sizes for the TX and RX buffers and let the user define what he wants for the ports he
is actually using.
But those fixes are not as quick and easy as just a temporary kludge to bump
the buffer size while you build the ArduinoISP sketch.

Another easy optimization that can help a little bit (but not eliminate the issue)
is to change the head/tail pointers to unsigned chars instead of unsigned ints.
This is a an easy modification that can done and left in.
It will make the HardwareSerial code smaller and a bit faster.
I make this change to every single Arduino release.

There is no real need to use unsigned ints since they would only come into play
with buffers larger than 256 bytes which they aren't.
Further, if buffers were ever made larger than 256 byes there are other
portions of the code that would break because the code is not properly handling atomicity issues
with respect to the head/tail pointers. i.e. they assumed that looking at and modifying a head/tail value
is atomic and for larger than 8 bit values, on the AVR, it isn't

--- bill