Added support for AVR Dragon, tested in 1.6.7

[shimniok]

Added Atmel AVR Dragon support to programmers.txt / externalprogrammers.txt. Tested that AVR Dragon option appears when ATTiny841 (no optiboot) selected, and verified that programming works, in Arduino 1.6.7. Thanks! --Michael

[SpenceKonde]

Thanks!

[shimniok]

@bperrybap The scope of this PR is only to provide support for programming ATtiny in Arduino with AVR Dragon. Once either of the teams finally bothers addressing the bug, then I would think it should be possible to use AVR Dragon or any of the other supported programmers.

[bperrybap]

But what does "support for programming" really mean?
If you have a virgin attiny, you usually want to (or in some cases need to) change the fuses and the only way to do that from the IDE is to use burn bootloader.
So in my mind programming includes the ability to set the fuses from the IDE.
Yeah it can easily be done from the commandline using avrdude, but most people using the Arduino IDE are using Windows and have no clue how to use the command line much less even where to locate avrdude on their system.

don't get me wrong, I think the update to include the dragon in the known programmers is a really good thing, but if the AttinyCore can't use the burn bootloader function with the dragon, there needs to be a "known issue" about it somewhere.

This is only an issue for Atmel ISP programmers like the Dragon and a few other atmel ISP programmers.
It is not a problem on any of the 3rd party non atmel ISP programmers such as USBasp, USBTiny etc....
I think is very ironic that the guy that controls and maintains avrdude works for Atmel and yet avrdude has this issue with only Atmel programmers.
Joerg complains that it is not a avrdude issue but rather an issue in libUSB however, avrdude triggers the issue in libUSB and avrdude can easily work around it but he doesn't lke the fix because it breaks an undocumented "feature" that he uses.
It took me years to convince WestFW to modify the makefiles in his optiboot project to work around this issue.
I don't understand the reluctance to fix this this or at least work around it.

I run a patched version of avrdude to fix the issue.
But it isn't really much of an issue for me anymore since I also don't use my dragon much since it is so slow and programming compared to a cheap USBasp ISP programmer.
(The code inside avrdude to support the dragon is really awful which is why it is so slow)

[shimniok]

Points taken and agree about "known issue" though I defer to @SpenceKonde on that.

It seems like the biggest challenge for the issue is finding out who is really responsible... and willing. :) It may well be a libusb thing, given some of my past struggles. I recall vaguely something about a kludge that "resets" the Dragon after every programming activity. Is this an issue on Linux, MacOS, and Windows?

Curious... do you have any details about the underlying libusb issue which you could forward to me? Agree that Dragon is (glacially) slow on avrdude. Wished it weren't so. Maybe I should break down and get a USBasp. It's just that I have built such a nice enclosure for my Dragon. :) Kidding. Thanks.

[per1234]

Here's the issue that bperrybap is referring to: arduino/Arduino#2986. As I reported there, the issue as it occurs with the Atmel AVRISP mkII programmer was solved for me when Arduino updated AVRDUDE to 6.3.0 but apparently the issue still occurs for bperrybap even with AVRDUDE 6.3.0. I also found that switching from libusb-win32 to the libusbK driver solved the issue with older AVRDUDE versions. I don't own an AVR Dragon so I can't say what the situation is with that programmer.

[bperrybap]

@shimniok
IMO, the Dragon product sucks all the way around.
It is a horribly complex and expensive piece of h/w (from a design & architecture perspective) vs what could have been done, the f/w takes a ridiculous amount of time to startup and enumerate after powerup and reset, and the code in avrdude uses ridiculous access methods to talk to the device that end up transferring the data across the bus in horribly inefficient ways vs what could have been done - in some cases sending the data across the USB multiple times.

Definitely go get yourself a USBasp. You will like the results. They are cheap so no reason not to.
You should update the f/w in them with the updated USBasp f/w that I created as it fixes many USBasp f/w issues and has code to automatically select the fastest SCK speed that works.
Yes you can use the dragon to update the f/w and the tools I provide (including GUI drag and drop tools for both Windows and Linux) in the USBasp package won't trigger the avrdude issue so you can set fuses and update the USBasp device.
I actually prefer the ones with a 6 pin ISP header vs the 10 pin. If you search on Ebay you can find them.
They cost a bit more but IMO are more convenient.
This gives you a faster solution than the dragon that can also be used to power the AVR target device which why I pretty much never use my dragon unless I want to do source level debugging.

Yes it is still a problem.
I just now attempted to use the IDE to burn a bootloader on a ATtiny85 using the latest ATtinyCore with the new avrdragon programmer entry on Arduino IDE 1.8.2 on linux.

avrdude: Version 6.3, compiled on Jan 17 2017 at 06:01:25
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "/home/bill/Arduino/hardware/ATTinyCore/avr/avrdude.conf"
         User configuration file is "/home/bill/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : usb
         Using Programmer              : dragon_isp
         Setting bit clk period        : 5.0
avrdude: usbdev_open(): did not find any USB device "usb" (0x03eb:0x2107)

avrdude done.  Thank you.

Error while burning bootloader.

@per1234
Given the problem, and what avrdude does to trigger the issue (avrdude explicitly resets the USB for certain USB ISP programmers), I don't see anyway that it could be fixed without a change to avrdude. At a minimum avrdude would need to stop explicitly reseting the USB for these devices just before it exits.
My suspicion is that due to a combination of IDE/avrdude and host enumeration timing on Windows vs Linux and potentially a faster f/w due to a f/w update on the mkII, that the issue is being avoided rather than actually solved on the mkII.
Or it could be that avrdude no longer resets the USB for the mkII - I haven't gone and looked at the latest avrdude code.
Whatever the case, it is still broken when using a Dragon and will require changes to avrdude to fix it since the code that triggers the issue is being done by avrdude.

@shimniok
Oh yes I have details.... I've written about it in GREAT detail many times.
Not only that I have created a working fix that is only 7 lines of code for avrdude.
All it does it poll for the target USB device to show up for a few seconds rather than do a single look for the USB ISP device. It adds ZERO additional time overhead if the device is present and ready to operate.
I have filed a bug for avrdude on savana and given that fix to the avrdude maintainers (which is mainly Joerg) who so far has rejected it, (He doesn't like it since it breaks an undocumented capability he uses in his lab - it doesn't really break it, it just slows it down because it looks longer for devices that are not present)
and to the Arduino IDE maintainers who have never pulled in the fix.
I have also proposed multiple s/w work arounds to for the Optiboot makefile and the Arduino IDE.
The optiboot project makefile was eventually updated to work around the issue - It took a few years to convince westfw to make the simple change in the Optiboot makefile.

The summary is that Avrdude resets the USB just before exiting after using certain USB devices. According to the comment in the code, it is to clear some kind issue between the Atmel devices and libusb. However, due to the way Atmel ISP devices work, a USB reset causes the f/w in the device to restart and the f/w takes several seconds to restart and re-enumerate with the host. If the host looks for the device during that time (which is what happens if you run two avrdude commands back to back) the device has not yet enumerated with the operating system so it will appear that the device is not plugged in. This issue is caused by avrdude doing a USB reset and so it must be fixed in avrdude.
The code I added simply polls for a few seconds rather than just looking for the device one time which allows the device time to restart, re-enumerate and show up.
It is a very simple solution to the issue.

Here are some links for more reading:
https://github.com/arduino/Arduino/issues/650
arduino/Arduino#2986

--- bill

[bperrybap]

@shimniok I actually did build a case for my dragon: http://www.instructables.com/id/A-protective-case-for-the-Atmel-AVR-Dragon/