I met a great engineer at the eFlea electronic flea market here in Silicon Valley. Kenneth already had an ME degree. Now he wants to get an MSEE with an emphasis in networking embedded systems. He is at Cal Poly. So he asked me if I could get him an AVR Dragon, a debugger board Atmel sells. A debugger is a gizmo that lets you see “inside” a chip. You can read its internal registers and see memory values. It makes it way easy to troubleshoot what is going wrong with your program. The Dragon works with most AVR microcontrollers. I got him a deal through our University program and asked if he would write a review when he got the board. He did a great job, and posted it on his website, with the understanding I would just cut-and-paste it to Bits and Pieces.
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 2×3 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…
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.”
Hey, I told Kenneth to give an honest review, and I am not going to edit out his criticism. And as you folks realize, it’s not like “Atmel didn’t feel the need” to put the docs in the product page. My buddy Gil over in the next cube just told me we have over 2000 English-language product pages. And those come in four languages. So I showed our web team the blog, and they point out it is not that simple. See the doc Kenneth found was a help page for the Atmel Software Framework (ASF). So it should not go in the documentation tab, since it is not technically product documentation. But Michael in the web team feels Kenneth’s pain. So he is adding that link Kenneth found to the product page description, which will keep the CMS (content management systems) happy. Like I joke “the other guy’s job is always easy.” That is the nice thing about coming to work here, where you can see how hard everybody is working to make the website do what you folks want it to. Kudos to the whole team—they really “get it”.
Now, the really cool thing is that we cleaned out a storage room and I found a Dragon I can play with too. As I mess with it, I will keep you posted on my trials and tribulations. Bear in mind my Atmel programming has all been in assembly language, so this might be exciting if I have to learn C.
Although I joke about “Friends don’t let friends go without a debugger,” it’s also true that “simple is good”. Kenneth was the guy I asked what was so cool about Arduino. He said: “Two big buttons. Compile, and Program, and that is all.” So if you can debug with printf statements out the serial port, go right ahead. When you want a real debugger we have the Dragon, and our Xplained boards not only have a debugger built in, but some of them have a header, so that after you get your board laid out and built, you can connect the header on the Xplained board to your target hardware, and it will be a debugger for the AVR in your production board too. Nice.
Pingback: In-circuit emulation for AVR and ARM SAM D20 chips | Bits & Pieces from the Embedded Design World
Pingback: AVR XMEGA-A3BU Xplained demo board unboxing | Bits & Pieces from the Embedded Design World