Wednesday, August 7, 2013

AVR Dragon Hardware Review


 One of my good friends at Atmel, Paul Rako, recently sent me a sample of the AVR Dragon (Atmel store page), which is a in-circuit serial programmer (ISP) and On-Chip Debugger (OCD). The ISP functionality is familiar to most hobbyists in the AVR embedded programming scene; through the standard 2x3 pin header, you can erase the flash memory on an AVR and download new program code onto the chip. A typical example of an ISP programmer, and what I've been using exclusively up until now, is the wonderful, if sometimes a bit flaky, AdaFruit USBtinyISP.

As you look back through my blog, you can probably tell that only having ISP capabilities will get you pretty far, but where the Dragon really shines is in its ability to perform on-chip debugging. Most of the third-party programmers only implement the basic SPI-based erase-and-burn cycle you use when programming an AVR, but OCD allows you to set break-points in your program on the actual chip, and then step through your program code, read variable values, etc. All those glorious interactive debugging features that computer programmers have been spoiled with for decades. This makes embedded development MUCH easier, and an ability I've been suffering without while my projects have grown progressively more sophisticated.
 When I first opened the shipment from Atmel, I was very happy to see a piece of dev kit finally come in a reasonably sized, and attractive, box. I'll actually be able to store this thing in its box instead of having to shuck it and store the PCB floating around in gallon ziplocks like most of my other dev kits.
 Look at that minimally wasted space! ESD foam on top and bottom, so over all, I'm happy with the packaging, which is surprisingly important when you literally have an entire closet dedicated to development kits collected over the years.
 Nice touch on the backside silk screen logo. I'd like to have seen the pin-out references on the top, particularly since they're oriented for "top view," but it's still a handier reference than the printout I have floating around in one of my electronics binders.
Looking at the headers from the top of the board:

  • The first row has 3x Vcc and 3x GND, which seems a little strange for a programmer, but might be handy for some projects?
  • The second row has your 10 pin JTAG and 6 pin ISP headers, which are your two work-horse programming interfaces for AVRs big and small, and finally an unpopulated high voltage programming interface. The HV_PROG interface allows you to burn AVRs like old-school EEPROMs, and allows you to get around having to use the SPI ISP bus for programming. This is most useful when you want to use the reset pin as an IO pin (did you ever wonder why Atmel bothers assigning an IO port number to the reset pin?). 
  • And below the three programming interfaces... six rows of unpopulated, unlabeled, headers? Uhhh...
So the bottom third of the board's real estate dedicated to empty headers threw me for a loop until I noticed the sentence in the description, "A development area lets designers build their own circuitry or add sockets for the desired device footprint."

Fair enough; I can load the bottom of my Dragon with a socket and make it an AVR target board. I'll just pull up the manual and figure out what the on-PCB pinout looks like...
Uhhh...

So apparently, Atmel didn't feel the need to put the Dragon's users manual on its product page? After finally resorting to searching through Google, I managed to find the users manual in Atmel's online help system, which quickly lead me to what I was looking for. I'm not entirely impressed with the rats-nest of jumper wires they have in the tutorial, and the three pairs of Vcc/GND make a lot more sense now, but I'm not convinced I'll not just stick to my standard practice of building separate target boards for each AVR model I use and keeping them in a ziplock in my drawer. I'd have expected a target area like that to use a bilateral switch array to allow for automatic retargetting to a specific AVR model, but that's asking a bit much of a $50 dev tool.

So overall, I'm happy with the packaging and feature set, but am a little disappointed that they made the board 50% larger for what seems like a half-thought-out target area. I look forward to being able to use a less kludgy programmer than the USBtinyISP, and finally being able to set break points in my code. As Paul says, "friends don't let friends go without on-chip debugging."

3 comments:

  1. Hy Kenneth, long time since my last comment on your blog..

    You can find here : http://www.larsen-b.com/Article/315.html some infos on using the Dragon on linux, and a picture of an ATmega32 with debugging wired directly.

    I used some wrapping.

    CAUTON : Dragon has some hardware issues, mainly the power supply (if I remember) check this out :
    http://www.aplomb.nl/TechStuff/Dragon/Dragon.html

    Hope this helps. Bye

    ReplyDelete
  2. FYI the reason for the VCC/GND 2x3 pin header is for use with the prototyping area. It's kind of like a big switchboard. A 2x40 header connects to MCU pins, or rather, prototyping socket pins. Then you jumper VCC, GND, and pins from ISP, JTAG or HV_PROG to the 2x40 pin header. The manual provides device connection sheets, like this: http://goo.gl/L0knnd Hope this helps.

    ReplyDelete