Re: maintainer update: add support for more AVR microcontrollers

Re: maintainer update: add support for more AVR microcontrollers

[Björn Haase]

From: Joerg Wunsch <j@uriah.heep.sax.de>, To: Eric Christopher 
<echristo@apple.com>, 
Cc: Jan-Benedict Glaw <jbglaw@lug-owl.de>, binutils@sourceware.org, Date: Thu, 
20 Apr 2006 23:01:23 +0200, Subject: 
References: 
<20060419193241.GA77330@uriah.heep.sax.de> <20060420014708.GM13324@lug-owl.de> 
<234616A5-B9B9-4A30-867D-3CD053064067@apple.com> 
<20060420050834.GC73791@uriah.heep.sax.de> 
<F610553E-74F0-44C0-AA67-94EC0BD0DD70@apple.com>, Reply-to: Joerg Wunsch 
<joerg_wunsch@uriah.heep.sax.de>

I completely agree with Joerg. IMO there is *NO* present user of the gnu 
toolchain for AVR that is not aware of the fact that the best place to find 
recent documentation is the avr-libc project. I'd like to estimate that 95% 
of the users even would not know how to access the information on the 
binutils info pages :-).

Without Joerg's changes the binutils port was extremely outdated. The only 
reason why this did not cause difficulties is, that almost every user has 
been working with pre-compiled binaries that were generated with the patches 
that were distributed and maintained by the maintainers of the avr-libc 
projects (thank's to Joerg Wunsch and Eric Weddington IIRC :-) ).

So the private binutils version of Joerg generally has a more official status 
than the cvs version :-).

Yours,

Bjoern.

Re: maintainer update: add support for more AVR microcontrollers

[Joerg Wunsch]

[-- Attachment #1: Type: text/plain, Size: 1765 bytes --]

As Eric Christopher wrote:

> >Documentation for the entire toolchain is mainly maintained as part
> >of the avr-libc project:

> >http://www.nongnu.org/avr-libc/user-manual/index.html

> This is bad. You should consider documenting the binutils options in
> the binutils manual.

Well, seriously, most of our users probably don't know what binutils
actually means.  For them, it's all "the compiler", and they are
already wondering why "the compiler" doesn't come along bundled with
an editor, as all of our "competitors" (i. e. other embedded compiler
vendors) do.

Thus, maintaining a consistent documentation for the entire toolchain
has a much higher priority to me than anything else, as that way, I
can at least point people to a single location where they can get all
the information needed.  Fortunately, we made a lot of progress here
compared to say 5 years ago, when the AVR support in the GNU toolchain
started its life, and many documentation files really only ended up in
.c.

If the original authors had bothered to at least write something like
a gas/doc/c-avr.texi file at all, well, I had no trouble to add each
new device name there as we are adding it.  However, there would be
much more things to document like added assembler operators where I'm
unfortunately don't even know for sure myself what they are doing
exactly. :-(  I'll see to find the people who once started that
project, and try whether we could come up with that doc file
eventually.

For the time being, please accept the patch as it is.

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: maintainer update: add support for more AVR microcontrollers

[Eric Christopher]

> all but happy about that change (as it is the first time where a
> suffix letter really makes a difference for the device), but for
> whatever reason, that's their marketing decision.

Sounds reasonable.

> Documentation for the entire toolchain is mainly maintained as part of
> the avr-libc project:
>
> http://www.nongnu.org/avr-libc/user-manual/index.html

This is bad. You should consider documenting the binutils options in  
the binutils manual.

-eric

Re: maintainer update: add support for more AVR microcontrollers

[Joerg Wunsch]

[-- Attachment #1: Type: text/plain, Size: 2405 bytes --]

As Eric Christopher wrote:

> >>-  {"atmega164", AVR_ISA_M323,     bfd_mach_avr5},
> >>+  {"atmega164p",AVR_ISA_M323,     bfd_mach_avr5},
> >
> >>-  {"atmega324", AVR_ISA_M323,     bfd_mach_avr5},
> >>+  {"atmega324p",AVR_ISA_M323,     bfd_mach_avr5},
> >
> >I'm not an AVR user, but from a user's perspective, this is an
> >interface change and should be documented.

> Agreed, I think that unless there's a reason you should keep both.

There is a reason: the ATmega164 and ATmega324 never really existed in
silicon, and Atmel literally renamed these devices before releasing
the first silicon for them.  Things are different for the ATmega644
which does exist in its original form, so there we do have both
devices now (and of course, we kept the old one).

Yes, this is really weird, I know.  They originally announced
ATmega164/324/644 to be one family, but funnily enough, the 164 and
324 had a wider feature set than the 644.  ATmega644 engineering
samples became available, but nothing except the datasheet for the
smaller siblings (not even their device XML files which they are using
for their own simulator).

Now that they started their `picopower' program (which is indicated by
the `P' suffix), they renamed the ATmega164/324 to 164P/324P (with
their originally intented feature set), and complemented that one by
an ATmega644P which has the same feature set as its smaller siblings,
so there are now 644 and 644P with different feature sets. :-(  I'm
all but happy about that change (as it is the first time where a
suffix letter really makes a difference for the device), but for
whatever reason, that's their marketing decision.

Likewise for the ATmega165/169 where both, the old and the 165P/169P
versions do exist.  They have the same feature set but some register
naming has been changed, so we also have both devices in the list now.

Documentation for the entire toolchain is mainly maintained as part of
the avr-libc project:

http://www.nongnu.org/avr-libc/user-manual/index.html

Once a new library release is done that supports these new devices
(most likely today or tomorrow), you'll be able to see their names in
that list.

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: maintainer update: add support for more AVR microcontrollers

[Eric Christopher]

>> -  {"atmega164", AVR_ISA_M323,     bfd_mach_avr5},
>> +  {"atmega164p",AVR_ISA_M323,     bfd_mach_avr5},
>
>> -  {"atmega324", AVR_ISA_M323,     bfd_mach_avr5},
>> +  {"atmega324p",AVR_ISA_M323,     bfd_mach_avr5},
>
> I'm not an AVR user, but from a user's perspective, this is an
> interface change and should be documented.

Agreed, I think that unless there's a reason you should keep both.

-eric

Re: maintainer update: add support for more AVR microcontrollers

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1509 bytes --]

On Wed, 2006-04-19 21:32:41 +0200, Joerg Wunsch <j@uriah.heep.sax.de> wrote:
> gas/ChangeLog:
> 
> 	* config/tc-avr.c (mcu_types): Add support for atmega165p,
> 	atmega169p and atmega644p device. Rename atmega164/atmega324
> 	devices to atmega164p/atmega324p.
> 
> -- 
> cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL
> 
> http://www.sax.de/~joerg/                        NIC: JW11-RIPE
> Never trust an operating system you don't have sources for. ;-)

> Index: src/gas/config/tc-avr.c
> ===================================================================
> RCS file: /cvs/src/src/gas/config/tc-avr.c,v
> retrieving revision 1.32
> diff -u -r1.32 tc-avr.c
> --- src/gas/config/tc-avr.c	7 Apr 2006 15:18:08 -0000	1.32
> +++ src/gas/config/tc-avr.c	19 Apr 2006 15:13:26 -0000
> @@ -116,13 +116,15 @@
> -  {"atmega164", AVR_ISA_M323,     bfd_mach_avr5},
> +  {"atmega164p",AVR_ISA_M323,     bfd_mach_avr5},

> -  {"atmega324", AVR_ISA_M323,     bfd_mach_avr5},
> +  {"atmega324p",AVR_ISA_M323,     bfd_mach_avr5},

I'm not an AVR user, but from a user's perspective, this is an
interface change and should be documented.

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 für einen Freien Staat voll Freier Bürger"  | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

maintainer update: add support for more AVR microcontrollers

[Joerg Wunsch]

[-- Attachment #1: Type: text/plain, Size: 667 bytes --]

Hi again,

here's another small patch to add support for more Atmel AVR
microcontrollers.  Atmel renamed some of their parts, and added
variants that need to be handled differently from their original
counterparts inside the library.

(My binutils copyright assignment is on file with the FSF.)

gas/ChangeLog:

	* config/tc-avr.c (mcu_types): Add support for atmega165p,
	atmega169p and atmega644p device. Rename atmega164/atmega324
	devices to atmega164p/atmega324p.

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

[-- Attachment #2: binutils-ATmegaXXXP.diff --]
[-- Type: text/plain, Size: 1573 bytes --]

Index: src/gas/config/tc-avr.c
===================================================================
RCS file: /cvs/src/src/gas/config/tc-avr.c,v
retrieving revision 1.32
diff -u -r1.32 tc-avr.c
--- src/gas/config/tc-avr.c	7 Apr 2006 15:18:08 -0000	1.32
+++ src/gas/config/tc-avr.c	19 Apr 2006 15:13:26 -0000
@@ -116,13 +116,15 @@
   {"atmega161", AVR_ISA_M161,     bfd_mach_avr5},
   {"atmega162", AVR_ISA_M323,     bfd_mach_avr5},
   {"atmega163", AVR_ISA_M161,     bfd_mach_avr5},
-  {"atmega164", AVR_ISA_M323,     bfd_mach_avr5},
+  {"atmega164p",AVR_ISA_M323,     bfd_mach_avr5},
   {"atmega165", AVR_ISA_M323,     bfd_mach_avr5},
+  {"atmega165p",AVR_ISA_M323,     bfd_mach_avr5},
   {"atmega168", AVR_ISA_M323,     bfd_mach_avr5},
   {"atmega169", AVR_ISA_M323,     bfd_mach_avr5},
+  {"atmega169p",AVR_ISA_M323,     bfd_mach_avr5},
   {"atmega32",  AVR_ISA_M323,     bfd_mach_avr5},
   {"atmega323", AVR_ISA_M323,     bfd_mach_avr5},
-  {"atmega324", AVR_ISA_M323,     bfd_mach_avr5},
+  {"atmega324p",AVR_ISA_M323,     bfd_mach_avr5},
   {"atmega325", AVR_ISA_M323,     bfd_mach_avr5},
   {"atmega329", AVR_ISA_M323,     bfd_mach_avr5},
   {"atmega3250",AVR_ISA_M323,     bfd_mach_avr5},
@@ -131,6 +133,7 @@
   {"atmega64",  AVR_ISA_M323,     bfd_mach_avr5},
   {"atmega640", AVR_ISA_M323,     bfd_mach_avr5},
   {"atmega644", AVR_ISA_M323,     bfd_mach_avr5},
+  {"atmega644p",AVR_ISA_M323,     bfd_mach_avr5},
   {"atmega128", AVR_ISA_M128,     bfd_mach_avr5},
   {"atmega1280",AVR_ISA_M128,     bfd_mach_avr5},
   {"atmega1281",AVR_ISA_M128,     bfd_mach_avr5},