AVR Downloader/UploaDEr - Bugs: bug #34339, back to back avrdude commands fail...
You are not allowed to post comments on this tracker with your current authentication level.
bug #34339: back to back avrdude commands fail on dragon_isp on Ubuntu 10.10
Submitter: | None | ||
Submitted: | Tue 20 Sep 2011 07:49:30 AM UTC | ||
Category: | None | Severity: | 3 - Normal |
Priority: | 5 - Normal | Item Group: | None |
Status: | None | Privacy: | Public |
Assigned to: | joerg_wunsch | Originator Name: | Bill Perry |
Originator Email: | -email is unavailable- | Open/Closed: | Open |
Release: | None | Programmer hardware: | |
Device type: |
Jump to the original submission
Thu 08 Dec 2011 07:20:50 AM UTC, comment #10: |
Joerg Wunsch <joerg_wunsch> |
Thu 08 Dec 2011 06:47:50 AM UTC, comment #9:
|
Joerg Wunsch <joerg_wunsch> |
Thu 08 Dec 2011 06:43:45 AM UTC, comment #8: Btw., of course, there would be a much easier fix to solve
|
Joerg Wunsch <joerg_wunsch> |
Thu 08 Dec 2011 06:33:26 AM UTC, comment #7: Regardless of why a USB reset is being done,
|
Bill Perry <bperrybap> |
Thu 08 Dec 2011 05:58:41 AM UTC, comment #6:
|
Joerg Wunsch <joerg_wunsch> |
Thu 08 Dec 2011 12:34:17 AM UTC, comment #5: One final comment just to provide the complete information
|
Bill Perry <bperrybap> |
Sun 04 Dec 2011 10:33:17 PM UTC, comment #4: Any update on this?
|
Bill Perry <bperrybap> |
Tue 20 Sep 2011 08:15:18 PM UTC, comment #3: My previous patch was wrong.
|
Bill Perry <bperrybap> |
Tue 20 Sep 2011 08:06:30 PM UTC, comment #2: There is already other code in avrdude that tries to work around things that are outside the control of avrdude.
|
Bill Perry <bperrybap> |
Tue 20 Sep 2011 09:52:35 AM UTC, comment #1: This is not an AVRDUDE issue but an operating system one. It
|
Joerg Wunsch <joerg_wunsch> |
Tue 20 Sep 2011 07:49:30 AM UTC, original submission:
While I'm seeing this on Ubuntu 10.10 with the AVR dragon I'm guessing that this
|
Anonymous |
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 5 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2011-10-06 | joerg_wunsch | Status | Wont Fix | None | |
2011-09-20 | bperrybap | Attached File | - | Added usbdev_open_retry.diff, #24003 | |
2011-09-20 | bperrybap | Attached File | - | Added usbdev_open_retry.diff, #24002 | |
2011-09-20 | joerg_wunsch | Status | None | Wont Fix | |
Assigned to | None | joerg_wunsch |
Powered by Savane 3.13-cf05.
Corresponding source code
One more thing that just occurred to me:
Of course, adding anything like that does have side-effects for
other users. The obvious side-effect is that they have to wait much
longer until they are being told their device is not present at all,
either since the e.g. mistyped the programmer name, or they requested
a particular serial number that is not present in the system. A
three-second "dead time" can be annoying in that situation. Keep in
mind that specifying a serial number that is guaranteed to not exist
(like, -P usb:x) together with one -v option is a common way of
finding out all the serial numbers of the requested devices present on
the system. This (ab)use would also suffer from the delay.
A less obvious (but much more annoying) side-effect here is that it
will announce all the devices that are present in the system 30 times.
Thus, your 6-line hack will need to get more sophisticated to cope
with this, and to ensure each device that has been found will be
announced at most once.
Likewise, nobody can really tell three seconds is enough for
everybody.
I'm not sure I like the "goto" command there, an outer (do … while)
loop to count down the timeout would IMHO be more appropriate.
For those reasons, I'll probably add another commandline option to
activate the hack (like, -x usb_wait_time=3). Obviously, this
requires Arduino users to change their Makefiles then in order to
benefit from the hack, which poses the question why they could not
change their Makefiles for a single avrdude command in the first place
…
Also, your patch lacks documentation, something that's easily being
skipped by people submitting patches, and then left to the
maintainer(s). All this together (with testing etc.) makes it more a
5-hour job than the 5-minute one you think it were.
I hope now you see why I didn't quickly and blindly apply it the way
you submitted it.