Re: [avr-gcc-list] Why are we using EICALL and EIJMP for AVR256?

[Dusan Ferbas]

Hi, your case is, that a bootloader (BL) uses trampolines.

I described a case in this list (June 2008 and Mar 2009), where an 
application calls a BL, where eicall resides.
There is a wiki page about it: http://www.ethernut.de/nutwiki/Nut/ATmega256x

Because of enabled interrupts during time, when BL is called, we are using:
#ifdef atmega2561
        unsigned char eind_local;       // asm ("r17");

        eind_local = EIND;
        EIND = 0x3F800 >> (16 + 1); //highest bit (for atmega2561 == 
1, because in words)
#endif
        BootInfoHeader->fn[BootInfoHeader->SectionID](BootInfoHeader->address, 
(unsigned short *)received_data_p, BootInfoHeader->pagesize);
#ifdef atmega2561
        EIND = eind_local;
#endif

Dusan

At 14:35 15.12.2009, address@hidden wrote:
> Thanks, it would be nice if this was documented.
>
> I noticed it when reviewing addressing modes and a omission in call patterns.
>
> void  (*fptr)();
>
> fptr = main;
>
> (*fptr)();  //Will use EICALL - should be CALL main
>
>
> which become readily apparent with inlined code.
>
>
> Andy
>
>
>
> ---- Sean D'Epagnier <address@hidden> wrote:
> > On 12/14/09, Andrew Hutchinson <address@hidden> wrote:
> > > The patterns for AVR mega 256 use EICALL an EIJMP
> > >
> > > Both require EIND to be set to provide upper address bits
> > >
> > > However, we are using linker trampolines for both, so in either case the
> > > 16 bit jump or call is to the trampolines.
> > >
> > > Are not the trampolines always located in first 128Kbytes? Thus we
> > > should be using ICALL and IJMP and not needing to set use EIND at all.
> > >
> > > What have I miss-understood?
> > >
> >
> > Hi,
> >
> > Yes this confused me a lot too, but the reason is because the
> > trampoline is not in the first 128kbytes for a bootloader, so if the
> > compiler uses eijmp and eicall, then it is possible to do indirect
> > calls there too, but it still works fine in normal code.
> >
> > Sean