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

[David Smead]

I'm just getting into the AVR, so I hope I'm not duplicating anything.

It seems to me that you want a define for the instruction set being used,
not a device.  Somewhere else, typically the make file, you tell the
linker where to locate segments.

With other microcomputer development I'm accustomed to linking the last
file with declarations such variables as last_code, last_ram, last_page0,
etc.  Now a simple script that's executed from the makefile can flag an
error on overruns.

I admit to hating `Integrated Development Environments' because they
usually are too restrictive and take too much effort to circumvent.

-- 
Sincerely,

David Smead
http://www.amplepower.com.

On Mon, 4 Feb 2002, Peter Jansen wrote:

> 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,
>
>

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