avr-gcc-list
[Top][All Lists]
Advanced

[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 02:16:42 +0100

Hi Andy,

believe me, we tested, debugged and it is running now in a lot of devices for several months. Did anyone tested if seeding the EIND before every eicall is slower and with bigger code size ?
(in comparison to trampolines)

Even if I admit using trampolines in a bootloader code (we are counting every byte),
 you have a problem, because 1st, only the bootloader is flashed
 and also trampolines differ for every application. The bootloader is same.

BL is linked with LDFLAGS = -Wl,-Map=$(TARGET).map,--cref,--defsym,__stack=$(StackAddr) \
-nostartfiles -nodefaultlibs -Ttext=0x01F800

Dusan

At 01:30 18.12.2009, Andrew Hutchinson wrote:
...
For 256 devices avr-gcc uses linker trampolines to allow 16 bit function pointers to reach any function located anywhere in address map.

The EIND is set to zero by gcc. (Trampolines are located in lower memory)
When a function pointer is assigned the address of function (in upper memory), a full sized jump to the function is added to trampoline table.
The function pointer gets the 16 bit address of this entry.

When the jump occurs - using EICALL, it will jump to trampoline using 16 bit address and EIND set to zero. The trampoline JMP will then take it to the function. If the function is in lower memory, the trampoline is not created by linker (though I have not checked that!)

Andy


Dusan Ferbas wrote:
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

Dusan





reply via email to

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