Re: [avrdude-dev] [bug #34339] back to back avrdude commands fail on dragon_isp on Ubuntu 10.10

[Xiaofan Chen]

On Thu, Dec 8, 2011 at 6:03 PM, Joerg Wunsch <address@hidden> wrote:
> As Xiaofan Chen wrote:
>
>> But why do this Atmel tools leave and rejoin the USB Bus is still
>> a mystery which is worth some time of investigations. Something
>> must trigger it to do that, right?
>
> It's the CMND_SIGN_OFF, at least for the JTAGICEmkII (and the Dragon
> which is related).  This command is pretty much mandatory.
>
> For the AVRISPmkII, I don't know, perhaps this one doesn't detach
> itself.  (Have to try this at home on my FreeBSD machine.)
>
> As for the reasons, I can only speculate.  I think they are performing
> some internal "general cleanup" step, perhaps it's really a full
> (watchdog) hardware reset.  The JTAGICEmkII offers both, the classic
> RS-232 as well as an USB transport, and one of them gets designated as
> the transport in charge as soon as you issue the CMND_GET_SIGN_ON
> across it.  So if you issue that command through RS-232, the USB part
> completely detaches itself from the bus.  Perhaps that's the
> historical reason.
>
>> Does this happen under Windows with the original Atmel driver
>> (Jungo) and libusb-win32 filter driver?
>
> It is completely independent of the driver, as the detach is carried
> out by the device.

Thanks for the detailed information. In that case, some kind of
delay is necessary for back to back operation and usb_reset() is
actually a separate issue.

>> BTW, Ubuntu/Debian are still using legacy libusb-0.1. But take note
>> libusb-0.1 is no longer maintained by the upstream libusb project.
>> Mac OS X will also be much better off using libusb-compat.
>
> What does that mean?
>
> I wouldn't want to rewrite the code so I have to support both APIs.  I
> don't think much maintenance on the libusb-0.1 part is needed from
> their side, as this library has been proven stable for many years now.
> So as long as libusb-0.1 is still the least common denominator between
> all systems around (including Win32), I wouldn't want to switch the
> code to the 1.0 API, as the new API doesn't otherwise get us much of
> an improvement.  (Things are different in AVaRICE where the libusb 1.0
> API would allow to get rid of that "USB daemon" thing, allowing for
> direct IO multiplexing between USB and TCP, but that's a different
> mess.)
>

With libusb-compat, you do not need to change any codes. It is
a wrapper for libusb-0.1 API, on top of libusb-1.0.
Ref: http://www.libusb.org/wiki/libusb-compat-0.1
Actually many Linux distros no longer offer libusb-0.1, but instead
offer libusb-1.0 and libusb-compat.

For Mac OS X, Macports offer both libusb-compat and libusb-legacy.
>From what I read, libusb-legacy is buggy under Mac OS X.
http://www.macports.org/ports.php?by=name&substr=usb




-- 
Xiaofan