Re: [avr-gcc-list] RFC: new AVR devices in binutils

[Anton Erasmus]

Subject:                [avr-gcc-list] RFC: new AVR devices in binutils
To:                     address@hidden
Date sent:              Fri, 18 Jan 2002 16:51:58 +0100 (CET)
Copies to:              address@hidden
From:                   Marek Michalkiewicz <address@hidden>

> Hi,
> 
> looking more at adding complete support for all these new devices (not
> only ATmega128), I'm not really sure what to do, as there are a few
> problems...  Basically, Atmel made too many different chips and didn't
> tell us (without all this super top secret NDA crap) early enough.
> 
> Looking at publicly available datasheets (some of which may describe
> non-existent devices... but most of them are real), there are about 20
> different combinations of Flash size, SRAM size, EEPROM size, and
> start of data memory (0x100 on ATmega64/128, 0x60 otherwise).  I don't
> think it's a good idea to add so many ld emulations, and add more when
> Atmel comes up with even more different chips...  So here is the plan,
> please tell me if it makes sense :)
> 
>  - add 5 new emulations, one for each "architecture" avr1 ... avr5
>    with default linker scripts defining maximum possible memory sizes:
> 
>  arch flash   SRAM    EEPROM
>  avr1 8K*     0       64K
>  avr2 8K      64K     64K
>  avr3 128K    64K     64K
>  avr4 8K      64K     64K
>  avr5 128K    64K     64K
> 
>    (* Yes, I know the largest avr1 now has only 2K - ATtiny28 - but
>    who knows if/when Atmel makes some ATtiny89 or something like
>    that... the idea is that it is possible to address max 8K of
>    program memory using the avr1 instruction set.)   In linker scripts
>    for these new emulations, define start of internal SRAM as 0x60,
>    and don't define __stack at end of SRAM (as we don't know the real

> 
>  - keep the existing avr85xx etc. emulations for now (may be removed
>    later, when no longer used for a few years...).
> 
>  - change LINK_SPEC in gcc/config/avr/avr.h to specify -Tdata 0x800100
>    for ATmega64/128 so variables start above I/O registers.  The
>    default (0x800060) is good for all other devices so there is no
>    problem.
> 
>  - change avr-libc to define __stack as a weak symbol in gcrt1.S (as
>    avr-libc has one crt*.o file for each device type anyway).  It is
>    weak soan be redefined - old linker scripts that do will not
>    fail.
> 
>  - after the next stable release of binutils, change GCC to use the
>    new avr[1-5] emulations for all devices, not just the new ones.
> 
>  - then, after the next stable release of GCC, the old avr85xx etc.
>    emulations may be removed from binutils.
> 
> The good thing is that after all this, new devices should not need big
> changes in binutils to be well supported.  Especially adding
> emulations is a pain - I don't have the right combination of
> autoconf/automake versions to regenerate all these files correctly.
> Makefile.in and configure end up being different in a few other places
> where I didn't change anything, and (tested on CVS binutils today)
> automake in "gas" subdirectory fails :(
> 
> So I guess I'll have to politely ask binutils maintainers to
> regenerate these files for me (as they know some magic that I don't
> know...), hoping I won't have to do that again too often...
> 
> The disadvantage is that we lose size checking (the linker won't
> detect that the program is too big for the device).  You have to write
> your own linker script with correct memory sizes, or look at avr-size
> output. But that size checking was not reliable anyway: no error if
> text < 8K but text+data > 8K, so looking at avr-size output (or map
> file) is necessary anyway...
> 
> Basically I try to preserve backwards compatibility between current
> stable releases of GCC and binutils.  That's why I'd like to add new
> emulations soon, but remove the old ones after no one uses them.
> 
> Also, there is no need to edit linker scripts for external SRAM
> support (how to do this is a Frequently Asked Question).  Only set up
> MCUCR correctly (avr-gcc -Wl,--defsym,__init_mcucr__=0xC0) and that's
> all. (This could probably be done by inserting some "asm" in C source,
> which could define that value using symbolic names from <io*.h>.)
> 
> It was partially my fault that I didn't expect so many new chips when
> making changes to support atmega163 etc.  Hopefully I won't make so
> many mistakes this time...  I'm very busy, but I want to do this so
> people stop sending me so much mail about ATmega128 support :)
> 
> Comments and suggestions welcome.  Could this plan be improved?
> 
> Thanks,
> Marek
> avr-gcc-list at http://avr1.org

Hi,

I was just about to recommend something similar. I think it is a 
great idea. This is basically how I could compile for the 
ATMega128 without having the version with "official" support for the 
ATMega128.

I basically added the option  -D__AVR_ATmega128__ to the 
command line, and specified the mcu as avr5. The default linker 
script can specify the maximum sizes as you suggested, but I 
think specific linker scripts should be added with file names based 
on the #define one needs to add to specify the specific mcu. (So 
that io.h etc can include the correct headers). It will then be easy 
to write a generic make file that will choose the correct linker script 
based on the #define that specifies the mcu.
e.g.
In a generic make file one can have:

 MCU = avr5
 DEV = __AVR_ATmega128__

 CFLAGS += -mmcu=$(MCU) 
 CFLAGS += -D$(DEV)
 LS = $(subst __AVR_,,$(DEV))
 LSCRIPT = $(subst _,,$(LS))
 LSCRIPT+=.x

The make variable LSCRIPT will then hold the specific linker script 
file name which in the above example should be ATmega128.x
If DEV was defined as __AVR_ATmega103__, then the file name 
should be ATmega103.x
In this way most people would not have to write their own linker 
scripts. And if one does not use a make file, then the default linker 
script with the maximum memory areas for each type of memory 
can be used.
Something similar can be used to specify a specific crt*.o file when 
linking.


Regards
   Anton Erasmus





avr-gcc-list at http://avr1.org