AVR Downloader/UploaDEr - Patches: patch #9565, Patch for WiFi AVR Programmer,...
You are not allowed to post comments on this tracker with your current authentication level.
patch #9565: Patch for WiFi AVR Programmer, uPDI support for jtagmkII, and serial-over-network improvements
Submitter: | Steve Woodford <scdoubleu> | ||
Submitted: | Wed 14 Feb 2018 04:29:49 PM UTC | ||
Category: | None | Priority: | 5 - Normal |
Status: | In Progress | Privacy: | Public |
Assigned to: | joerg_wunsch | Open/Closed: | Open |
Sun 21 Nov 2021 09:22:30 PM UTC, comment #3: |
Joerg Wunsch <joerg_wunsch>![]() ![]() |
Wed 10 Nov 2021 08:06:52 AM UTC, comment #2: Thanks for looking over the patch.
|
Steve Woodford <scdoubleu> |
Tue 09 Nov 2021 09:32:45 PM UTC, comment #1: I reviewed the patch, and mostly like it.
|
Joerg Wunsch <joerg_wunsch>![]() ![]() |
Wed 14 Feb 2018 04:29:49 PM UTC, original submission:
Here are a set of patches against trunk which add the following features:
|
Steve Woodford <scdoubleu> |
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 4 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2021-11-09 | joerg_wunsch | Status | None | ![]() |
In Progress |
Assigned to | None | ![]() |
joerg_wunsch | ||
2018-02-14 | scdoubleu | Attached File | - | ![]() |
Added avrdude-wavr-jtag2-updi.diff.gz, #43314 |
Carbon-Copy | - | ![]() |
Added -email is unavailable- |
Well, all that timeout handling is a mess. A lot of that is probably just heritage from AVRDUDE's 22-year old history.
I wonder whether there's a better way than introducing just another timeout hack^H^H^H^Hsetting though.
The jtagmkII.c code tries to implement a kind of adaptive timeout setting, by doubling the value on missed transactions. Doesn't that already help in your case?
Short of that, maybe we should implement a kind of per-programmer notion of a short vs. long timeout (defaulting to 100 ms / 5 s) that is subsequently be used to toggle between both values. Then, the wavr programmer driver could establish a longer "short" timeout than those 100 ms.
How does that sound?