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

[Bill Perry]

Follow-up Comment #7, bug #34339 (project avrdude):

Regardless of why a USB reset is being done,
a USB reset is being done or a device disconnect is happening. Either way, the
USB device is
having to re-enumerate which can cause usbdev_open() to fail.
avrdude can easily be updated
to acccount for this so that the usbdev_open()
routine "just works" so that external programs
and scripts using avrdude will no longer have to include work
arounds for this condition.


> The exact time required to see the device again is highly
> OS-dependant (it's the time the OS needs to walk through all
> of the enumeration process). It can be much less than the
> 3+ seconds you are claiming.

Maybe there was some misunderstanding what I meant
by "workarounds". What I intended to mean was that
if people are experiencing issues with the existing avrdude
that they can do either of the two mentioned work a rounds to
their external programs or scripts that call avrdude to be up and going again
without having to update their
avrdude code.

Yes I agree that the re-enumaration can be less than 3
seconds. In fact on my linux machine with only one other
USB device it is just barely under 2 seconds for the AVR dragon to show up in
libusb.
The mentioned 3 seconds is meant to be a very conservative
value that is especially useful for applications
or scripts that need to run on different platforms or in different
environments.

It was a value that people could use that would "just work",
until avrdude is eventually updated to solve the issue.


===

The patch I provided allows avrdude to attach to the device as soon as the
device is ready. There is no blind wait, it simply polls for a given amount of
time by looking for the device every 1/10 of second
until it gives up after some amount of time.
It adds no additional time to usbdev_open() beyond what the
device needs. If the device is ready when usvdev_open() is called, ZERO
additional time is added and it works exactly like it does today.

I am not understanding the objection to this patch or
at least using this methodology.


====================================
I've reported the issue, very clearly outlined the problem,
and even offered a simple 6 line patch to solve the problem.

There is not much else I can do.



    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?34339>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/