Except that I wish I could program the fuses on the ATtiny85 through boards.txt.
I'm using Sparkfun's "Pocket AVR Programmer" which works like the USBtinyISP.
It uploads fine, but when I try Burn Bootloader I get
avr_read(): error reading address 0x0000
read operation not supported for memory "lock"
avrdude: failed to read all of lock memory, rc=-2
Strangely, I'm able to "burn the bootloader" for the 2313. I can also set the fuses with that programmer using the command line. (avrdude -C "..\etc\avrdude.conf" -c usbtiny -p ATtiny85 -U lfuse:w:0xE2:m -U hfuse:w:0xD7:m)
The section of boards.txt for the 85 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.protocol=avrispv2
# attiny85at8.upload.using=arduino:arduinoisp
# attiny85at8.upload.using=pololu
attiny85at8.upload.using=arduino:usbtinyisp
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.bootloader.unlock_bits=0xFF
attiny85at8.bootloader.lock_bits=0xFF
attiny85at8.build.mcu=attiny85
attiny85at8.build.f_cpu=8000000L
attiny85at8.build.core=tiny
Is it possible I'm getting some kind of "interference" from the MIT core I also have installed? (It's installed in the IDE's hardware folder and not in the sketchbook hardware folder where Ardunio-Tiny is.) Since the MIT core does not include a 2313, it might explain why I can burn that one - just a WAG.
The problem is the AVRDUDE.CONF file. There are a few lines missing for the 85 processor (I think the 84 section is also deficient). The problem is solved by using a newer version of the file.
There is also a bug in the compiler (or linker) that prevents jumps / calls to the entire address range. The symptom is a cryptic message that includes something about "R_AVR_13_PCREL" and a failure to finish the build. This problem is solved by using a newer version of the toolchain.
So you don't have to "upgrade" your toolchain, later tonight I'll diff the old and new AVRDUDE.CONF files and post instructions for updating the file.
Good to hear about AVRDUDE.CONF. I found your post on this previous thread, made the change and now it's working.
There is also a bug in the compiler (or linker) that prevents jumps / calls to the entire address range. The symptom is a cryptic message that includes something about "R_AVR_13_PCREL" and a failure to finish the build.
Oh really! You mean something like this ? . . .
c:/program files/arduino-0022/hardware/tools/avr/bin/../lib/gcc/avr/4.3.2/../../../../
avr/lib/avr25/crttn85.o:(.init9+0x2): relocation truncated to fit: R_AVR_13_PCREL against
symbol `exit' defined in .fini9 section in c:/program files/arduino-
0022/hardware/tools/avr/bin/../lib/gcc/avr/4.3.2/avr25\libgcc.a(_exit.o)
I ruined 3 cups of coffee on that this morning. I'd think I'd have it reduced to the lowest common denominator - and then it would slip away. Let me know if you want examples.
Things are making sense again, and I thank you for that!
BroHogan:
Oh really! You mean something like this ? . . .
Yup. That's the nasty thing.
I ruined 3 cups of coffee on that this morning. I'd think I'd have it reduced to the lowest common denominator and then it would slip away.
That's a familiar experience! I would move things around and the error would disappear. Add a single line of code and ... bang ... it would be back.
Would you prefer to "upgrade" to the latest tool-chain? It was fairly easy to do, both bugs have been eliminated, and I haven't had any other problems.
Would you prefer to "upgrade" to the latest tool-chain? It was fairly easy to do, both bugs have been eliminated, and I haven't had any other problems.
gulp, sure!
(I've come a long way from being happy with my parallel programmer. Next I'll be on the AVR Freaks forum!)
It's not comfortable to live with a time bomb, so I guess it's the thing to do.
Install the latest WinAVR to a convenient location. I went with C:\WinAVR.
Ensure the Arduino IDE is not running.
Locate the existing tool-chain directory. It should be in {ArduinoRootFolder}\hardware\tools.
There should be a single sub-directory there named avr. Rename the existing avr sub-directory to something like avr (old).
Create a new sub-directory named avr.
Move the entire contents of your WinAVR directory (C:\WinAVR*) to the newly created avr directory ({ArduinoRootFolder}\hardware\tools\avr*).
Copy avrdude.conf from {ArduinoRootFolder}\hardware\tools\avr\bin to {ArduinoRootFolder}\hardware\tools\avr\etc (you may have to first create etc).
That's it. You should now be able to run the Arduino IDE and build Sketches. If you have problems, you can switch back to the original tool-chain by renaming avr to avr (new) then renaming avr (old) to avr.
Sweet! The hardest part was downloading the file. Sourceforge doesn't seem to like Chrome.
That took care of the compile problem. I had a collection of sketches with the problem and now they all compile.
The avrdude.conf (Step 8 ) didn't allow me to "Burn Bootloader" however. It still must have the missing lines (although it's bigger than the older one). So I used the one I had modified and it's all good.
I may have started with ruined coffee but I sure am enjoying this scotch. Thanks for your generous help.
I initially tried both this core as well as the MIT HLT-core, neither worked on my desktop, I assume it's to do with 64-bit Windows, I've had issues with Processing apps using any kind of serial communication on x64. So I tried with my netbook, which has a 32-bit OS. This core didn't work there either, but the MIT core works as described.
What do I need to do to get this to work? I've followed all the instructions in tiny/readme.txt to the letter (unzip core zipfile to the hardware directory inside the sketchbook directory, edit hardware/tiny/boards.txt to upload.using=arduino:arduinoisp for all MCUs, upload ArduinoISP to the arduino, wire the Arduino and ATTiny together, load up a sketch and upload). I've now done a fresh reinstall of the Arduino IDE three times now, and whatever I try, I always end up with "avrdude: stk500_getsync(): not in sync: resp=0x15".
I'm using ArduinoISP and wiring according to the Fritzing-schematics on the MIT HLT core page. Any help would be appreciated...
Arduino Duemilanove. Oh, and the target is a ATTiny85. I actually started again trying to get this to work because I read in another thread that with your core, I could set the fuse bit directly from the IDE, something that I've been unable to do manually with avrdude with the core and wiring from MIT LHT.
shinmai:
For the life of me, I can't get this to work.
I've now done a fresh reinstall of the Arduino IDE three times now, and whatever I try, I always end up with "avrdude: stk500_getsync(): not in sync: resp=0x15".
This error is because of Auto Reset capabilities of Arduino. This document: MegaISP gave me some details. This error occurs on Mac or Linux. For using Arduino as ISP, I need to disable Auto Reset capabilities. Therefore I inserted 110 ohms (330 ohms / 3) resistor between Reset-pin and 5V-pin. This resistor should be above 110 ohms and below 124 in accordance with this document: DisablingAutoResetOnSerialConnection.
I tried to burn Arduino bootloader onth ATmega 8 again and succeeded in it. I connected 19 pin of ATmega 8 and GND with a LED and it flashed. This behavior proves buring Arduino bootloader in accordance with this document: Bootloader.
I'm working to get Arduino-Tiny up and running on an ATtiny85. I think I have gotten as far as Burning the Bootload configuration to the ATtiny85 but am now stuck trying to upload my first sketch. After the patch to AVRDUDE.CONF (see http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1274820597/90 reply #99, noting that reply #8 of this thread did not work for me either), I can successfully burn the bootloader config to the ATTiny85 (I think) with a "Done Burning Bootloader" in the IDE. I am getting errors when I try to upload my first sketch. I can compile my little blink.pde sketch, but when I upload, the errors I get in the IDE are:
Binary sketch size: 694 bytes (of a 8192 byte maximum)
java.lang.NullPointerException
at processing.app.debug.AvrdudeUploader.getProgrammerCommands(Unknown Source)
at processing.app.debug.AvrdudeUploader.uploadUsingPreferences(Unknown Source)
at processing.app.Sketch.upload(Unknown Source)
at processing.app.Sketch.exportApplet(Unknown Source)
at processing.app.Sketch.exportApplet(Unknown Source)
at processing.app.Editor$DefaultExportHandler.run(Unknown Source)
at java.lang.Thread.run(Thread.java:619)
I am hoping someone here can help me out.
Thanks,
George
Extra Background
My setup is Arduino-0021 on an Windows XP laptop. I am trying to copy Coding Badly setup exactly so I am using a Pololu USB AVR programmer, which I like so far. The configuration utility for this programmer (pgm03a_config.exe) runs and reports back the programmer serial number, and I get a ready to program status (flashing yellow led) when I have the target board hooked up and powered up so I think the hardware is all working. Programmer shows up fine at COM5, with the optional TTL serial port showing on COM6 in the windows hardware device manager window. My target board has an ATtiny85 installed, with no external crystal/resonator. I wish to use the internal oscillator to clock the ATtiny85 at either 1 or 8 MHz. The board has an LED hooked up to pin 2 of the ATTiny85.
Checked programmers.txt, for some reason the version I pasted in dropped the l in serial, but my actual file has it spelled correctly.
Then I checked boards.txt, changed all the .upload.using entries from "=pololu" to "=arduino:pololu" as you recommended.
Success!!! I have a blinking green LED on my ATtiny85 board. Awesome. I then changed the board to from 1 MHz to 8 MHz and burned the bootloader, recompiled and re-uploaded. Success again.
I will now start exploring what I can do with the ATtinyX5s. I need to hook up the TTL serial port on my Pololu programmer so I can get a serial monitor for debug. Any questions or issues I will repost here.
So far the overall (your core + Pololu programmer) setup is Highly recommended.
My next goal is to get ATtiny Arduino running as an I2C slave.
There has been some discussion on the forum. But, I've not done anything I2C so I won't be much help. If you do get something working, please take the time to report about your success. Even something as simple as "I got I2C slave working" is helpful to someone considering it as a solution. At least they know it is possible.
Out of curiosity, how did you discover the fix above?
I truly have no idea. It is a combination of experience (lots of mistakes trying to program ATtiny processors) and the way my brain works.
Is the syntax for the Arduino configuration .txt files documented anywhere?
Technically, it is documented by the fact that the source code is readily accessible. I have not looked at the Arduino IDE source code so it is by observation that I found that "arduino:" syntax.
