On Thu, Dec 8, 2011 at 6:03 PM, Joerg Wunsch <[email protected]> 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 _______________________________________________ avrdude-dev mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/avrdude-dev
