Let me preface this post by stating that I recommend this expensive option only if you need to quickly prototype several disparate programs on a breadboard (protoboard) using Atmel chips not loaded with a bootloader.

If you are a weekend microchip programmer warrior I highly suggest purchasing chips from Nerdkit which have the bootloader loaded, it’s less expensive and keeps this awesome forum and company going.

AVR alternative….

If you decided to go with the AVR Dragon. Please do your due diligence and look up everything you can on the Atmel site. The dragon is considered a low cost debugger which also programs several chip designations including the 168 series. You can GOOGLE this information as Atmel likes to change links often as they innovate.

You may also want to purchase about 80 headers and a 40 pin ZIF socket. I found Mouser and DigiKey to be good sources however they are expensive. There is a smaller company called www.elexp.com which sells them cheaper, but they may have them on back order at times. (search for ZIF socket, not ZIFF)

Once you have the dragon in your hot little hands, solder the components and you’re off and running after you download the AVR Studio from Atmel of course. It’s about a ½ gig program, she’s a biggie. Again, please GOOGLE this under “download AVR Studio” and make sure it’s an Atmel or secure. The AVR Studio is your programmer / debugger software and I found it very useful, specifically when building the file, it points to problems in the code more efficiently.

As of this writing 1/2012 the AVR Studio 5 is the latest version and seems stable, however, the debug function leaves much to be desired. Most people gravitate towards the AVR Studio 4 because of greater stability in the debug area, but the problem is that the Studio 4 doesn’t have all the new chips developed by Atmel.

Please download all the related pdf files for the AVR Studio and AVR Dragon and take time to read them before you use the products as there is information in there that will help you keep your equipment going well and you from pulling your hair.

The AWESOME video in the link below explains how to hookup and burn in a program using ISP. Watch it a few times so you get the hang of it.

http://www.youtube.com/watch?v=yJo29VMXt90&feature=related

As per the video the AVR gcc programs do not need a bootloader. You write the program, compile it in to a hex file, then burn it in to the chip. Once you do this a few times you’ll be a pro at it.

I have several projects I’m working on therefore I hooked up my Dragon a bit differently. Instead of directly connecting the wires from the headers to the protoboard like the video has, I first connected them to the dragon itself (as prescribed by the dragon pdf file) then I took a chip socket and hooked that up with wires connected to the protoboard where the chip is. This makes it easy to program chips directly to the protoboard or using the ZIF socket on the dragon. I needed this kind of flexibility.

Click on the link below to see pictures of my hookup and a brief explanation

http://www.beachsidegem.com/dragonISP.JPG

If you have any questions, you can write on this post and I should get an update on my email at the beachsidegem domain.

Much credit to the impressive and ever educational Nerdkit guys and their company.

Al

This is a breif overview of the above article

The following link is to a very helpful Youtube video

-Click here for the AVR Studio programming video using SPI

Hi Al -

Great info. Curious though...how did you arrive at $150 in parts? I thought the Dragon sold for around $50 and the other stuff ~$10. What am I missing?

Thanks again for the info.

I purchased it several months ago and the large breadboard was pretty expensive as well. It was probably a bit less but I went high on my estimate (inflation). It's a ball park figure. It works well though, problem is that some code gives me definition errors, it seems that some of the .h and .o files are a bit different with AVR Studio compared to Nerdkits and the AVR free programmer. For example, delay.h calls for an underscore before the delay_ms command (_delay_ms) and the speed definition has to be one of the first few lines of code or errors occur. Other than that, it works well.

One more thing, the SPI pins cannot be used when programming, so that leaves 3 pins out. You can plug them in to LEDs or peripherals once you're done programming but it's a hassle. It's a give and take. SPI uses send, receive and clock. 3 pins.

If you are programming in C, AVRStudio uses the avr-gcc compiler just like the Nerdkit platform. The reason you are using _delay_ms is because you are using the AVR Libc libraries instead of the Nerdkit library found in your libnerdkits folder. If you wanted to include that, you still can and use it.

The AVR Dragon is a nice programming/debugging board offered by Atmel. The main advantage it has for the mcu's used here over either the serial bootloader programming method or a simple ISP programmer like the USBASP, is the fact that if you do mess your fuse settings up completely, it offers a high voltage serial programming option that can reset them. That is something a simple ISP programmer cannot do. Of course a serial bootloader can't muck with the fuses and create a problem in the 1st place. That is one of the main benefits to beginners using a serial bootloader, and probably (This is just my opinionated guess) one of the deciding factors for the NK guys to go that route.

I've programmed the mcu's both ways, and I use both bootloader and ISP programming but rarely fire up AVR Studio. It is way overkill for the simple projects I do. I'm glad to see you got it working for yourself though. Everyone has to do what they are comfortable with and your writeup may help some on that path who prefer that method.

Thanks,

Rick

Thanks Rick and Al,

I was interested in the Dragon because of the debugging features and since a programmer is thrown in, it is worth looking into. I found most of the troubles I've encountered have been caused by compiler optimizations and me not understanding the nuances of the AVR library. Having a debugger would have certainly saved a great deal of time on some projects I've experimented with. Using the obj-dump is a huge help, but some things are more easily detected by stepping through the code.

Al, have you figured out how to use the debugger feature?

If so that would make a great "How To"!!

Ralph

Ralph, I haven't played with that feature much because when I started it was kind of buggy. AVRS5 has that known descrepancy. It's a great feature and yet another reason I went that route but I haven't had much success with it. It's on my to do list once I get some things fitured out. One thing is for sure, Nerdkits got me going on a great path here.

Al

If one wanted to make their own debugger device - say with an ATmega as the debugger. What circuit would allow the debugger AVR to read and write a single wire debugWire? Would you use one I/O pin and change it between Input and Output as needed? Would it change direction fast enough to communicate successfully? Is ATmega fast enough to communicate serial without using the 2-wire serial interface (bit banging?)?

Hey Guys,

I did not know where else to put this question. My brain is not working. Could someone tell me where to find and read <avr/io.h> and <iom168p.h>? (or any other #include files, I'm having some kinda mental block)

Regards,

Tyron

Tyron -

On a windows machine, the default installation puts those files here:

C:\WinAVR-20090313\avr\include\avr