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, andrewhutchin...@cox.net 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 <geckosena...@gmail.com> wrote:
> On 12/14/09, Andrew Hutchinson <andrewhutchin...@cox.net> 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
_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
