Arduino translated to AVR?

[quote author=Coding Badly link=topic=108797.msg821752#msg821752 date=1339351492]

double-checked the wiring to the attiny.

chose board: ‘ATtiny85 @ 8 MHz (internal oscillator; BOD disabled)’ and the Programmer was ‘Arduino as ISP’

Perform a Burn Bootloader to change the fuses on the ATtiny85

…[/quote]

Went through the steps. Here’s the error readout…

/Applications/Arduino.app/Contents/Resources/Java/hardware/tools/avr/bin/avrdude -C/Applications/Arduino.app/Contents/Resources/Java/hardware/tools/avr/etc/avrdude.conf -v -v -v -v -pattiny85 -cstk500v1 -P/dev/tty.usbmodemfa141 -b19200 -e -Uefuse:w:0xFF:m -Uhfuse:w:0xD7:m -Ulfuse:w:0xE2:m 

avrdude: Version 5.11, compiled on Sep  2 2011 at 18:52:52
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "/Applications/Arduino.app/Contents/Resources/Java/hardware/tools/avr/etc/avrdude.conf"
         User configuration file is "/Users/Darcyneal/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : /dev/tty.usbmodemfa141
         Using Programmer              : stk500v1
         Overriding Baud Rate          : 19200
avrdude: Send: 0 [30]   [20] 
avrdude: Send: 0 [30]   [20] 
avrdude: Send: 0 [30]   [20] 
avrdude: Recv: . [15] 
avrdude: stk500_getsync(): not in sync: resp=0x15

avrdude done.  Thank you.

Drc3p0: Uploaded successful!

Argh! Stupid brain! What I read was that you successfully uploaded to the ATtiny85. Sorry about the confusion. Give me a minute to review...

Try this...

• Prepare the Uno exactly the same way you did the last time (upload the modified ArduinoISP sketch; connect the capacitor)

• Load and prepare the same Blink sketch you have been using (or copy-then-paste the following)...

/*
  Blink
  Turns on an LED on for one second, then off for one second, repeatedly.

  This example code is in the public domain.
 */

void setup() {                
  // initialize the digital pin as an output.
  // Pin 13 has an LED connected on most Arduino boards:
  pinMode(0, OUTPUT);     
}

void loop() {
  digitalWrite(0, HIGH);   // set the LED on
  delay(1000);              // wait for a second
  digitalWrite(0, LOW);    // set the LED off
  delay(1000);              // wait for a second
}

• Ensure the correct board is selected [ATtiny85 @ 8 MHz (internal oscillator; BOD disabled)]

• Ensure the correct programmer is selected (Arduino as ISP)

• Ensure the correct serial port is selected

• Click Verify to ensure the sketch compiles. If it does not compile, resolve any problems.

• Click the reset button on the Uno. The LED on pin 13 will blink a few times. Wait for the blinking to stop.

• Click Upload

If that works, do this...

• Click the reset button on the Uno. The LED on pin 13 will blink a few times. Wait for the blinking to stop.

• Click Tools / Burn Bootloader

If that works, do this...

• Click the reset button on the Uno. The LED on pin 13 will blink a few times. Wait for the blinking to stop.

• Click Upload

At this point, if everything went well, the ATtiny85 should be toggling pin 0 about once a second.

I have tried the modified sketch in reply #30 but I get this error when I try to burn bootloader or upload blink sketch, and the Error Led pin8 is on

avrdude: Version 5.11, compiled on Sep  2 2011 at 19:38:36
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "D:\Arduino_1_0\arduino-1.0-windows\arduino-1.0\hardware/tools/avr/etc/avrdude.conf"

         Using Port                    : \\.\COM20
         Using Programmer              : stk500v1
         Overriding Baud Rate          : 19200
avrdude: Send: 0 [30]   [20] 
avrdude: Send: 0 [30]   [20] 
avrdude: Send: 0 [30]   [20] 
avrdude: Recv: . [15] 
avrdude: stk500_getsync(): not in sync: resp=0x15

avrdude done.  Thank you.

I have tried to lower the Baud rate to 19200 (as far as I remember this was an advice given in another thread)

To veryfy that my setup and connections are OK, I tried the exact same setup in version 0021, with success, burning bootloader, uploading blink sketch worked as expected.

I have checked the boards.txt in the ver. 1.0 installation, it looks like this:

###########################################################################

attiny85at8.name=ATtiny85 @ 8 MHz  (internal oscillator; BOD disabled)

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

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

attiny85at8.upload.maximum_size=8192

# 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.build.mcu=attiny85
attiny85at8.build.f_cpu=8000000L
attiny85at8.build.core=tiny

###########################################################################

attiny85at1.name=ATtiny85 @ 1 MHz  (internal oscillator; BOD disabled)

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

# The following DO work (pick one)...
attiny85at1.upload.using=arduino:arduinoisp
# attiny85at1.upload.protocol=avrispv2
# attiny85at1.upload.using=pololu

attiny85at1.upload.maximum_size=8192

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

attiny85at1.bootloader.low_fuses=0x62
attiny85at1.bootloader.high_fuses=0xD7
attiny85at1.bootloader.extended_fuses=0xFF
attiny85at1.bootloader.path=empty
attiny85at1.bootloader.file=empty85at1.hex

attiny85at1.build.mcu=attiny85
attiny85at1.build.f_cpu=1000000L
attiny85at1.build.core=tiny

###########################################################################

Edit: This is the thread about lowering the baud rate http://arduino.cc/forum/index.php/topic,94609.0.html

and this about changing the delay in the heartbeat http://arduino.cc/forum/index.php/topic,108270.msg813132.html#msg813132

but as far as I can see this is implimentet in the modified sketch

[quote author=Coding Badly link=topic=108797.msg822177#msg822177 date=1339395266]

If that works, do this...

• Click the reset button on the Uno. The LED on pin 13 will blink a few times. Wait for the blinking to stop.

• Click Tools / Burn Bootloader [/quote] I went through the steps as indicated, and when I tried to burn the boot loader, I received an error message, which was the same error message that I had posted previously, and it also happens to be the same as the error message that Erni posted.

Does this version work any better?

ArduinoISP.ino (12.4 KB)

Erni: I have tried the modified sketch in reply #30 but I get this error when I try to burn bootloader or upload blink sketch,

Before posting were you having the same problem as @Drc3p0? Did you see avrdude output identical to this... http://arduino.cc/forum/index.php/topic,108797.msg820859.html#msg820859

Does this version work any better?

Success... it works !!, I have tried burn bootloader and uploading blink sketch .. no problems.

A minor problem, the hartbeat LED dosn't beat

Before posting were you having the same problem as @Drc3p0? Did you see avrdude output identical to this... http://arduino.cc/forum/index.php/topic,108797.msg820859.html#msg820859

Hmm I could check, bur maybe it is less interesting, now you have solved the problem.

Once again, thank you Coding Badly for maintaining the tiny core !

To resolve these sync errors (not related to auto reset) wouldn't it be easier to just bump the RX buffer size in HardwareSerial down in the core code to avoid all these RX buffering issues? (even it is just temporary just to build the ArduinoISP sketch?)

You can have all the buffering in the world in the sketch but if the sketch can't drain the hardware serial rx buffer fast enough it doesn't matter.

avrdude is bursting the data using a 128 byte pages/chunks + 1 byte cmd + 1 byte memory type + 2 bytes length + 1 bye sync char for a total of 133 bytes. It will wait up to 5 seconds for a sync response and another 5 seconds for a successful write. So as long as you have 133 bytes of rx buffer you can take up to 5 seconds to burn the 128 bytes to flash after you report "IN SYNC" back to avrdude.

As it is now, in pre 1.0 you have 128 bytes of RX buffer so it tends to work because but in 1.0 you now only have 64 bytes with the arduino supplied core. If the sketch can keep up it can work, but in reality it doesn't 100% of the time particularly on 1.0 using the arduino 1.0 core and the heartbeat function. The transfer time of a byte at 115200 is 87us 64 bytes is about 5.5ms The heartbeat function does a delay of 20ms, depending on the timing of when that occurs, you just blew out your HardwareSerial RX buffer even if the buffer is 128 bytes.

If you bumped the rx buffer up to 256 bytes then there would be no rx buffering issue including when using the heartbeat function as the RX buffer could accommodate all 133 characters with no loss.

Wouldn't it be a lot simple to just bump RX buffer size by editing HardwareSerial.cpp and changing SERIAL_BUFFER_SIZE or RX_BUFFER_SIZE (depending on core and version) from 64 to 256 ?

That way you totally eliminate any possible rx buffer overruns.

--- bill

Erni: A minor problem, the hartbeat LED dosn't beat

The hearbeat code was removed. This problem is essentially the same as the "not compatible with 1.0" problem. The sad part is that I had offered a ready-to-use replacement that solves that problem and this one.

When I have time I'll post a replacement with a working heartbeat.

Erni:

Before posting were you having the same problem as @Drc3p0?

Hmm I could check,

Don't. We'll just wait to hear from @Drc3p0.

Once again, thank you Coding Badly for maintaining the tiny core !

You are welcome! Hopefully, someday, version 2 will be finished.

bperrybap: To resolve these sync errors (not related to auto reset) wouldn't it be easier to just bump the RX buffer size in HardwareSerial down in the core code to avoid all these RX buffering issues?

The solution is much simpler than that: Change heartbeat to blink-without-delay. I am sad to say I am not joking. Because of the way both sides work (avrdude sends then waits; ArduinoISP waits, buffers, then writes) a bigger buffer is really not necessary. I've used a modified ArduinoISP, without problems, at 9600, 19200, 250K baud and 125K, 250K, 1M SPI bitrates.

[quote author=Coding Badly link=topic=108797.msg825406#msg825406 date=1339620295]

bperrybap: To resolve these sync errors (not related to auto reset) wouldn't it be easier to just bump the RX buffer size in HardwareSerial down in the core code to avoid all these RX buffering issues?

The solution is much simpler than that: Change heartbeat to blink-without-delay. I am sad to say I am not joking. Because of the way both sides work (avrdude sends then waits; ArduinoISP waits, buffers, then writes) a bigger buffer is really not necessary. I've used a modified ArduinoISP, without problems, at 9600, 19200, 250K baud and 125K, 250K, 1M SPI bitrates.

[/quote] With ArduinoISP there are actually two levels of buffering. One by the HardwareSerial ISR and then one in the sketch. It all depends on how the sketch code is written as to whether a larger ISR buffer is needed or whether a sketch buffer is needed. Currently there is a very realtime need to process the data from the ISR buffer and move it into the sketch buffer because the ISR buffer is not large enough to hold the full 128 byte avrdude page size being used. When the ISR buffer gets large enough, the realtime need to drain the ISR buffer into a sketch buffer goes away.

There are two ways to solve the buffering issue: - re-buffer the rx data in the sketch and ensure the sketch has no latencies large enough cause data loss - make the ISR buffer large enough to hold the full avrdude data page.

The reason I said it might be "easier" to bump the ISR buffer size is that this eliminates any realtime needs in the sketch to pull rx data from the ISR buffer. This could make it easier for less technical folks to modify the code to add things like status indicators or whatever. They could then do all kinds of things that are somewhat time consuming and not cause data to be lost including using the existing heartbeat() function that stalls the CPU for 20ms at time.

It was the "lazy man's" approach to solving the problem without having to change/modify the sketch code.

It sure would be nice if the HardwareSerial library could let you easily set or override the existing RX buffer size.

--- bill

I agree with everything you've written. Control over the receive buffer size would certainly be helpful.

But, a bigger buffer would not have helped with this particular problem (the one reported by @Drc3p0). The sign-on is a maximum of six bytes and is the first message sent by avrdude. The current buffer is large enough to hold everything sent. The delay introduces a race condition that, in this case, leads to a loss of synchronization. It's just dumb luck that the sketch is so generally reliable.

[quote author=Coding Badly link=topic=108797.msg824488#msg824488 date=1339574914]

Does this version work any better?

[/quote]

Yes!! It works!!

thank you so so much for your help.

One more question… Is there a reference chart for the sketch size limitations for the different attiny’s? I’m hoping to use an attiny45v for a particular sketch i’ve written, but I don’t know what the size limitation is. I also know that there’s 2 different versions of the attiny45v. Does an attiny reference chart exist?

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: [u]attiny45v[/u] in your case • Restrict the search to the Atmel site: [u]site:atmel.com[/u] • 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...

• [u]2/4/8K[/u] is the size given for Flash • On the right side, past the vertical line, is a list of models: [u]ATtiny25/V[/u] [u]ATtiny45/V[/u] [u]ATtiny85/V[/u] • 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

• [u]128/256/512[/u] 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!

[quote author=Coding Badly link=topic=108797.msg827806#msg827806 date=1339785867]

Nope. It has three.

[/quote]

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