[bug #22699] Errors in AVR910 Device Codes

[Sylvain Beucler-4]

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

                 Summary: Errors in AVR910 Device Codes
                 Project: AVR Downloader/UploaDEr
            Submitted by: None
            Submitted on: Sunday 03/23/2008 at 03:32 UTC
                Category: None
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
         Originator Name: Mike Perks
        Originator Email: mikep@...
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

It is important to maintain support for AVR910 programmers and therefore a
few corrections to the AVR910 devices codes is required (looking at AVRDude
5.5):
1. The following devices do not have AVR910 device code in the conf file:
mega48, mega88, mega168. These should be added so a AVR910 can be used for
these devices.
2. The following devices use device code 0x75 although that is already
allocated to the mega16 bootloader. I suggest that device code 0x73 might be
better: mega329, mega329p, mega3290, mega3290p, mega649, mega6490.
3. The device code for mega162 is listed as 0x63 but this should be 0x62
because device code 0x63 is for the mega162 bootloader.





    _______________________________________________________

Reply to this item at:

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

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



_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

[Sylvain Beucler-4]

Update of bug #22699 (project avrdude):

                  Status:                    None => Need Info              
             Assigned to:                    None => joerg_wunsch          

    _______________________________________________________

Follow-up Comment #1:

> 1. The following devices do not have AVR910 device code
> in the conf file: mega48, mega88, mega168. These should
> be added so a AVR910 can be used for these devices.

Klaus Leidinger uses 0x31, 0x33, 0x35, myAVR uses 0x6, 0x7,
0x8, respectively.  Which one to chose, and why that one?

> 2. The following devices use device code 0x75 although that
> is already allocated to the mega16 bootloader. I suggest
> that device code 0x73 might be better: mega329, mega329p,
> mega3290, mega3290p, mega649, mega6490.

I agree that 0x75 is a poor choice, and should be avoided.
But in which respect would 0x73 (ATmega32 BOOT) be better
here?

> 3. The device code for mega162 is listed as 0x63 but this
> should be 0x62 because device code 0x63 is for the mega162
> bootloader.

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

The closest match would be the ATmega161 which is kind of a
predecessor of the ATmega162 (code 0x60), but I don't know
for sure whether both use the exact same programming
parameters.  Further, both Klaus Leidinger's and myAVR's
AVR910 implementation agree on using device code 0x63 for
the ATmega162 so changing that right now will cause further
incompatibilities.

    _______________________________________________________

Reply to this item at:

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

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



_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

[Sylvain Beucler-4]

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

> Klaus Leidinger uses 0x31, 0x33, 0x35, myAVR uses 0x6, 0x7,
> 0x8, respectively. Which one to chose, and why that one?

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.

I think there are at least 3 implementations of avr910 with different
devicecodes, where the devicecode scheme seems not to follow any  rule.

I'm willing to change the devicecodes and would strongly agree to a new list
given by the avrdude.conf to get rid of this incompatiblities.  

>> 3. The device code for mega162 is listed as 0x63 but this
>> should be 0x62 because device code 0x63 is for the mega162
>> bootloader.

> 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

So my suggestion is that avrdude should declare devicecodes and  I expect the
devicecode mess is over soon. (except the bootloader code mess ;-) )

Kind Regards,
Klaus



    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.nongnu.org/



_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

[Sylvain Beucler-4]

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

Klaus Leidinger wrote:
> In the avr109 Sourcecode gcc section is a Parts.txt or the
preprocessor.xls)
> which lists the devicecode for m162 to 0x63
This doesn't match your programmer which it what I was looking at. We should
change the programmer to match AVR109 and we can take this item off the list
for this bug.

    _______________________________________________________

Reply to this item at:

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

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



_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

[Sylvain Beucler-4]

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

Followup to Joerg's comment on #2:

>> 2. The following devices use device code 0x75 although that
>> is already allocated to the mega16 bootloader. I suggest
>> that device code 0x73 might be better: mega329, mega329p,
>> mega3290, mega3290p, mega649, mega6490.
>
> I agree that 0x75 is a poor choice, and should be avoided.
> But in which respect would 0x73 (ATmega32 BOOT) be better
> here?
This is a typo on my part - I couldn't read my own writing. It should have
said 0x78 (mega169).

    _______________________________________________________

Reply to this item at:

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

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



_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

[Sylvain Beucler-4]

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

Followup on comment #4:

> It should have said 0x78 (mega169).

OK, that makes sense.

    _______________________________________________________

Reply to this item at:

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

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



_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

[Sylvain Beucler-4]

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/



_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

[Sylvain Beucler-4]

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

The more I think about the future of this, the more I come close to Joergs
opinion. Let's RIP the good old avr910.

For the existing avr910 programmers and implemented devices anyone who is
interested could edit the avrdude.conf and that's it.

This worked for the last years, and should for the next.
If we always improve the old avr910, this story will never stop.

Changing the devicecode scheme to an Signature based decision within the
avr910 Firmware is also a mess. To be backward compatible (with AVRprog and
others) at least the "official" Devicecodes have to be there.


    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.nongnu.org/



_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

[Sylvain Beucler-4]

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

Reply to comment #7:

> Changing the devicecode scheme to an Signature based decision
> within the avr910 Firmware is also a mess. To be backward
> compatible (with AVRprog and others) at least the "official"
> Devicecodes have to be there.

Well, they'd only need to be there in order to "offer" them
to avrprog.exe.  Upon receiving a selection, just don't care
what it was (unless it's a 0x13, indicating an AT90S1200),
go ahead initializing ISP, and then query the signature.

I just added the extended parameter -x devcode=VALUE to the
avr910 implementation.  It allows the user to override the
device code that is sent to the programmer.  That might
hopefully serve as a stop-gap measure so at least no separate
avrdude.conf is required.

    _______________________________________________________

Reply to this item at:

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

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



_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

[Sylvain Beucler-4]

Update of bug #22699 (project avrdude):

                  Status:               Need Info => Wont Fix              
             Open/Closed:                    Open => Closed                

    _______________________________________________________

Follow-up Comment #9:

I believe the new -x devcode=VALUE option is a good enough
compromise to work around the various mutually incompatible
AVR910 device code extensions.

    _______________________________________________________

Reply to this item at:

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

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



_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev