[avrdude-dev] [bug #22699] Errors in AVR910 Device Codes

[Joerg Wunsch]

Follow-up Comment #6, bug #22699 (project avrdude):

Followup on comment #2:

> As I wrote in the avrfreaks forum, ist is not so important
> whom code you use, important is that avrdude gives some
> devicecode for the newer devices. Any distributor of a
> avr910 Firmware should be interested to be compatible with
> avrdude.

Since I wouldn't want to roll a dice on each new device, I'd
like to get an opinion on an algorithm for this.  Sigh, I
wish we could drop that entire AVR910 mess completely. :-(
We almost settled to automatically generate the AVRDUDE
part configuration from Atmel's XML files in future, but due
to that AVR910 stuff, this can't be fully automated since
naturally, Atmel refuses to give out messy device codes for
a protocol that has been abandoned by them anymore.  So
there will always be manual work involved.

My personal opinion: I don't want to invent these.  We'll
add each new part based on the information in the XML files.
The first one to claim an AVR910 device code for each new
part can file a bug report for it, and we'll add that code
then.  The person filing that bug report is responsible to
ensure no clashes occur.

> There's no official assignment for the ATmega162 bootloader,
> or the ATmega162 at all.

> In the avr109 Sourcecode gcc section is a Parts.txt or the
> preprocessor.xls) which lists the devicecode for m162 to 0x63

But this is for the bootloader device codes (which are not
even to be used anymore by protocol AVR109).

Not that I ever really understood why a bootloader requires
a separate device code at all.  However, as AVRDUDE has been
using that device code in the past (and yes, I think that's
because I once messed up the bootloader codes with the basic
codes after having a look at AVR109 myself), I think we should
just keep it the way it is.

I've got a completely different suggestion: all AVR910 firmware
vendors should stop using device codes as well, and essentially
go the AVR109 route: whatever device code is presented to the
programmer, just accept it, go read the signature bytes, and
decide based upon the signature.  The only thing that still
needs a different device code then is the (now almost obsolete)
AT90S1200 since it required a different ISP initialization, but
that ought to be easy enough to do.  All other AVRs do have the
same ISP initialization, so you should always be able to read
the signature then.

Still, AVR910 is always in a poorer situation than STK500v2:
for each new part, a firmware upgrade of the programmer is
required.  In STK500v2, all device dependant parameters are
passed down from AVRDUDE, so no new firmware is needed.  Yet
another strong argument for abandoning AVR910 completely, and
move all standalone programmers to a more sensible protocol.

    _______________________________________________________

Reply to this item at:

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

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