[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Dusan Ferbas
Subject: Re: [avr-gcc-list] Why are we using EICALL and EIJMP for AVR256?
Date: Fri, 18 Dec 2009 00:33:59 +0100

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)
BootInfoHeader->fn[BootInfoHeader->SectionID](BootInfoHeader->address, (unsigned short *)received_data_p, BootInfoHeader->pagesize);
#ifdef atmega2561
        EIND = eind_local;


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.


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]