And Atmel Studio 6, or is there a better programmer and programming environment? It seems like it may be hard to beat fifty bucks and free.
P.S. The fact that I can't press Alt-F, S to save my sketch makes me angry. I love the Arduino, but the IDE has a lot of little irritations in it coming from Visual Studio.
Thank you.
Well... why would you?
The Arduino hardware and programming environment are good to let go of the training wheels too. Do you still use digitalRead? digitalWrite? AnalogRead()? Do you know how to use those peripherals without Arduino libraries?
The fact that I can't press Alt-F, S to save my sketch makes me angry.
Angry? Really? It's just a programming environment. I don't complain because nothing uses ctrl-ks to save.
Hi,
I had the same idea myself recently, I had been building lots of standalone Arduinos that were embedded in time critical applications however when I installed AVR Studio it looked like I would need to learn a new set of libraries for simple things like millis and serial output. Being too old to learn yet another environment I returned to Arduino on the basis that I can get code out very quickly and easily and if I do ever need to optimise anything to the nth degree I can use all the time I have saved using the familiar Arduino environment to do so (so far I have not needed to).
If you go commit to AVR Studio, let us know how you get on and if there are any killer benefits that we should not be living without.
Duane B
JoeN:
P.S. The fact that I can't press Alt-F, S to save my sketch makes me angry. I love the Arduino, but the IDE has a lot of little irritations in it coming from Visual Studio.
Isn't Ctrl+S easier anyway? And you can specify an external editor if you want to.
DuaneB:
If you go commit to AVR Studio, let us know how you get on and if there are any killer benefits that we should not be living without.
OK, I took a few hours and bit the bullet today and it all worked out. I bought an Dragon from Digikey a couple of weeks ago and also some ATTiny85s and ATTiny88s because I knew I wanted to do this. This is basically how it is done:
My test code was a modification of the first project in tinyAVR Microcontroller Projects for the Evil Genius. I simplified it, it alternately blinks two LEDs. That is all. Here is the project:
Here is the code:
#define F_CPU 8000000UL
#include <avr/io.h>
#include <util/delay.h>
int main() {
DDRB |= 1<<2|1<<3;
PORTB |= 1<<2|1<<3;
while (1) {
PORTB &= ~(1 << 3);
_delay_ms(300);
PORTB |= (1 << 3);
PORTB &= ~(1 << 2);
_delay_ms(300);
PORTB |= (1 << 2);
}
}
Benefits?
I made up a small "jig" board which pre-connects the jumpers for the board you want to program. This is particularly useful for the larger chips like the Atmega328 which have quite a few pins you have to jumper. Then when you want to use the programmer you just shove the board onto it to make the connections.
Underneath:
Top:
Ready to use:
It's useful for the smaller chips, but I still write the code in the IDE.
Compiled in the Arduino IDE (1.0.1) the sketch you posted above gives this:
Binary sketch size: 144 bytes (of a 8192 byte maximum)
That is 144 bytes compared to your 148. So don't get too excited that you are saving heaps of program memory.
As for the debugging, well let us know how that goes. Personally I haven't been motivated to attempt to use it yet.
The ZIF socket is a good idea. When testing it is nice and quick to remove the chip from the programmer and drop it into a test board (also with a ZIF socket) until it is all debugged.
That is interesting, sort of surprising to me, but to use the Arduino, aren't you immediately losing 1K or something like that for the bootloader?
I have seen something like your pre-made jumper board on Hack A Day when I was researching all of this prior to actually doing the work tonight:
That does look like a good idea if you are going back between a few AVR chips that you know you will stick to. I have a pretty good idea I like these tiny85 chips. The number of pins is limited, but the RAM and flash should be OK for a lot of applications and they are so incredibly cheap.
The other choice is buy another Dragon and jumper it up to your other configuration(s). The tradeoff is going to be probably more time to do the board but less cost. Then again, the Dragon is really quite reasonable at fifty bucks.
JoeN:
That is interesting, sort of surprising to me, but to use the Arduino, aren't you immediately losing 1K or something like that for the bootloader?
First, the Optiboot loader is only 512 bytes.
Second, to compare apples with apples, I was compiling in the IDE, and then using the Dragon to upload. So I didn't need a bootloader.
You don't have to use a bootloader, and indeed the smaller chips don't support one anyway.
If you compile in the IDE with verbose output, you get to see the location of the .hex file. Just copy and paste that into the "file to upload" box for the Atmel Studio uploader, and it uploads the .hex file from the IDE. Pretty simple, because the name won't change for one session.
When I was testing stuff on the AtTiny85 I hit the "Verify" button in the IDE, which produces the .hex file, switched to the Atmel Studio and then hit the Upload button. Just a couple of clicks and the chip was programmed. Pull it out, put it into the testing board, and test.
Thanks for that information. I did not know that. The fact is, I just want another tool here and I am interested in the debugging aspect. I purposefully titled this thread a little bit provocatively and maybe I should not have done that. I love the Arduino boards that I have bought so far and I am going to use AVR Studio and the Arduino system both as tools in the chest. Also, and I am not going to do this for a while because I have enough ideas on my plate already, I would like to experiment with Atmel's ARM microcontrollers in the future. It seems this is something that Studio 6 apparently supports, though it looks like it may require a different programmer.
No offence taken. 
Have fun, and if you find anything useful, please let use know. Like, is the debugger worth the effort, or not?
Hi Nick,
Do you have an overview of how the high voltage programmer works ? I have locked myself out of 3 or 4 ATMega8's and understand that high voltage programming is one method to get back in.
Duane B
I haven't made one, but from the datasheet (page 300) you apply +12V to the /RESET pin (this is the "high voltage" part).
This turns the chip into "parallel programming mode" where the normal IO pins are reconfigured to have different meanings. The programming works in the absence of any clock (well, you supply the clock) and regardless of the fuse settings. You can't read back a protected program, but you can change the fuse bits to allow SPI programming if disabled, and unprotect the chip (which erases it).
dxw00d:
The fact that I can't press Alt-F, S to save my sketch makes me angry.
Angry? Really? It's just a programming environment. I don't complain because nothing uses ctrl-ks to save.
:wq doesn't work either.
DuaneB:
Hi Nick,Do you have an overview of how the high voltage programmer works ? I have locked myself out of 3 or 4 ATMega8's and understand that high voltage programming is one method to get back in.
Duane B
I would suggest you read the document I linked earlier:
It says this...
High Voltage Serial Programming Description
Low pin count AVR devices do not have enough IO pins to support the full Parallel
Programming interface. These devices instead use HVSP programming, which is a serial
version of the Parallel Programming interface.Important!
Extreme care should be taken if using HVSP mode to program a AVR device on an external
target. The HVSP lines do not have level converters, so it is important that the target board
is powered by the AVR Dragon VCC header, and not using another power supply. In
addition the AVR Dragon will apply 12V to the reset pin, so it is important that the target
board is designed to handle 12V on this line.To avoid damaging the Target Board, the AVR Dragon or both, it is recommended to only
use HVSP mode on devices placed in the 28/40 pin DIP socket on the AVR Prototype area
on the AVR Dragon.Parallel Programming Description
High pin count AVR devices support the full Parallel Programming (PP) interface. This
interface offer high speed programming, and also support programming all fuse and lock
bits in the AVR Device.Important!
Extreme care should be taken if using PP mode to program a AVR device on an external
target. The PP lines do not have level converters, so it is important that the target board
then is powered by the AVR Dragon VCC header, and not using its own power supply. In
addition the AVR Dragon will apply 12V to the reset pin, so it is important that the target
board is designed to handle 12V on this line.To avoid damaging the Target Board, the AVR Dragon or both, it is recommended to only
use PP mode on devices placed in the 28/40 pin DIP socket on the AVR Prototype area on
the AVR Dragon.
The way I read this, you can do it with the Dragon in the prototype area once you have mounted a ZIF socket. This document gives the correct wiring diagram for the HVSP and PP programming modes for all devices that are supported.
So with a Dragon with a ZIF mounted and Atmel Studio 6 installed, you should be able to jumper it correctly and program it - just select the HVSP or PP programming mode on the programming screen when you get there.
OK, a bit more information.
To debug, you have to go into the programmer and set the DWEN fuse. If you don't, the debugger will only give you a cryptic message that includes the message "set the DWEN fuse" absolutely nowhere.
Once set, debugging happens in almost exactly the way you would expect it to, which is really cool.
On my rig, I am having a weird problem - after I set that fuse, the programmer refused to acknowledge the chip anymore in ISP mode. The thing still debugged and still ran on my breadboard, just the programmer was having trouble.
Because of the prior talk about HVSP programming mode, I rejumpered the programmer for HVSP for the ATtiny85 and tried to program it this way. HVSP had no problem finding the chip.
BUT, you can't debug in HVSP mode!. And also, I still can't get the chip to recognize in ISP mode after reprogramming it in HVSP mode ald also once I reprogrammed it with HVSP it would not debug. That is odd, I wonder what I am doing wrong. So this calls for some more experimentation on my part.
But for the person asking about HVSP, it is no more difficult to use that mode than the ISP mode, for the chips that support it. It works fine. I don't know about PP mode yet, I have only worked with the ATtiny85 which does not have nearly enough pins to support it. I have some ATTiny88s and ATMega328s which use PP mode so I will do that tomorrow.
JoeN:
3. On my rig, I am having a weird problem - after I set that fuse, the programmer refused to acknowledge the chip anymore in ISP mode. The thing still debugged and still ran on my breadboard, just the programmer was having trouble.
I'm not too surprised. With DWEN enabled, the /RESET pin is no longer a reset source. So the ICSP wouldn't work, I guess.
:wq doesn't work either.
Neither does ZZ.
Yes, I get angry when ZZ doesn't work.
Knowing vi is a useful skill. It still abounds on many operating systems.
I can definitely edit files more efficiently in vi, than any GUI based editor.