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

[Peter Jansen]

Marek,

Sorry its taken awhile to get back to this, work......

Should the -mmcu options on the compiler command line specify the memory
layout any way. Would it not be better to use this option to set the
instruction set for the device? The linker scripts could then be a
default set that will work in most cases. In embedded work its neccacary
to look at and understand the linker script anyway to make a new project
work.

A define the could be used to select the correct ioxxxx.h file or
included specifically with the project.

>  - 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 size).

Yep sounds good, I have forgotten to pick up defining the __stack
veriable which seems to be missing for the 128.
 
>  - keep the existing avr85xx etc. emulations for now (may be removed
>    later, when no longer used for a few years...).

Ok
 
>  - 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.

Or force people to look at the linker scripts when starting a new
project. The method I put in for the 128 works but I agree its a mess.
 
>  - 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 so can 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.

Ok
 
>  - then, after the next stable release of GCC, the old avr85xx etc.
>    emulations may be removed from binutils.

Ok
 
> 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...

I think I would encorage people to write there own linker script so they
understand what is going on.
 
> 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 :)

I would agree about the 128 stuff. Its hard to predict how may devices
Atmel is going to release.

Regards,

-- 
Peter Jansen
Smart Container
Level 1, NIC Building
Eveleigh
NSW       1430
AUSTRALIA
avr-gcc-list at http://avr1.org