[avrdude-dev] [bug #22520] Programming Tiny25 with AVR-Prog AVR109 style programmers does not work

[Joerg Wunsch]

Update of bug #22520 (project avrdude):

                  Status:                    None => Wont Fix               
             Assigned to:                    None => joerg_wunsch           
             Open/Closed:                    Open => Closed                 

    _______________________________________________________

Follow-up Comment #1:

avr109 aka. butterfly is meant for exactly that purpose: to
drive a bootloader, which normally can only handle a single
device anyway.  What you're seeing there is the consequence
of the infamous "device code" mess that is implied into the
entire protocol here, where the device code itself is already
a clumsy idea to begin with, and where Atmel gave up
maintaining device codes years ago.  What you can see is done
in the butterfly implemenation now is essentially a workaround
that brokeness by design, to get bootloaders at least working
at all, even for modern devices.

So you ought to use avr910 for a standalone programmer.
However, given the mess with the device codes, it's virtually
impossible to find a single set of device codes that would
be supported by multiple vendors of "modern" AVR910 firmware.
To add to this, several incompatible versions of AVR910
firmware implementations have been developed over time, to
make the mess complete.

My strongest recommendation would be to completely give up
AVR910 protocol as a standalone programmer protocol, and
urge all the vendors of those tools to migrate their firmware
to the much better defined STK500v2 protocol.  My major
concern with AVRDUDE's AVR910 implementation is to provide
an implementation that is backwards compatible to AVR910
programmers out in the field (so to not break historical
implementations that are still around in production use),
rather than providing a feature-rich implementation for
new AVR910 firmware.  Users of new devices could always
chose to abandon the AVR910 protocol in favor of STK500v2,
while users who've got an established installation base
cannot.

As such, I welcome any patches to help improving the code,
but I'll be very cautious to assure they won't break the
existing installed base.  One idea I've already tossed
around with another developer in a private conversation
is to use the new -x option to offer additional options
for just these programmer types.  That would e.g. allow
for the user to specify things like

-x devcode=0x42

to override the device code to send to the programmer,
or maybe also something like

-x use_blockmode

if someone were to implement an optional block transfer
mode into the avr910 module.  For the latter, I simply
hesitate to use any form of "negotiation" because it is
virtually impossible to predict how existing programmers
would actually react to that.

Again, my strongest recommendation is for any standalone
programming tool to migrate to the STK500v2 protocol, which
is, after all, not "rocket science" to implement.  If, for
whatever reason, certain vendors of AVR910 tools don't want
to go that path, they are welcome to contribute patches that
implement things like the above mentioned -x options.  Me
personally, I don't have much interest in spending my own
time into extending an (IMHO) obsolete protocol myself, and
I think I explained my major concern of maintaining backwards
compatibility in the avr910 module.

    _______________________________________________________

Reply to this item at:

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

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