avrdude-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avrdude-dev] [bug #34339] back to back avrdude commands fail on dra


From: Joerg Wunsch
Subject: Re: [avrdude-dev] [bug #34339] back to back avrdude commands fail on dragon_isp on Ubuntu 10.10
Date: Thu, 8 Dec 2011 11:03:52 +0100
User-agent: Mutt/1.5.20 (2009-06-14)

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.

> 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.)

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]