Follow-up Comment #3, bug #42267 (project avrdude):
Hmm, I see. However, even though this might be the firmware's fault, it seems
unlikely that this will be fixed on that end (especially for the older
hardware, I'd expect). Closing this as invalid and ignoring the problem
doesn't seem like a great idea, since then things will still be broken for
anyone using avrdude with this hardware. When manually running avrdude, the
obvious workaround is of course to not verify the lockbits, but for example
running inside the Arduino IDE, I don't think this easy (and probably not
possible without also disabling verification of the full binary). Having to
disable verification isn't so nice anyway...
What's the problem with adding a workaround in avrdude? Sounds like it could
just be added for the affected hardware (if the code structures allows this,
not sure). Alternatively, adding a small delay for all hardware doesn't seem
like a big burden?
Ideally, you'd not add workarounds for broken hardware or firmware to any
software, but that's unfortunately often impossible. If the Linux devs would
have used this filosophy, I don't think the Linux kernel would still exist
today ;-p
_______________________________________________________
Reply to this item at:
<http://savannah.nongnu.org/bugs/?42267>
_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/
_______________________________________________
avrdude-dev mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
