> I have a program for the AtMega2561 that is more that 128K > and that make use of function pointers. The compiler is > WinAvr as of March 13, 2009. > > As I understood when a function body is in the upper 128K, > and the address of this function is taken, the compiler (or > linker) generates a small stub in the "trampoline" area in > lower memory that contains a jump to the function body. > The "address of" operator then returns the address of this > stub, rather that the address of the function itself. > This way an indirect jump through the pointer (only 16 bits) > ends up, being the EIND register always zero, to the stub, > which in turn makes a full jump to the function.
Trampolines work only for statically linked functions, not function pointers. This is a known bug and cannot easily be fixed. The root of the problem is that GCC's architecture does not lend itself to 24-bit entities. As you noted, function pointers are 16 bits, which limits the range to 128K of flash (since all AVR instructions are 2 bytes wide, the program counter addresses 2 byte words). GCC could be modified to run with 32-bit (4 byte) pointers, but the ATTiny folks would yell like mashed cats if that were done universally. I suppose that a switch could be placed telling GCC whether to use 16 bit or 32 bit pointers, but then the avr-libc library would need to be compiled both ways leading to problems of making sure that the correct library is linked with the correct compiled source. All of the above could be done. However, the GCC team are notoriously low on volunteers. Interested in taking this project on? I thought not. For the moment, the only solution is to place the target of all function pointers in the bottom part of the ATMega2560/1's flash. If you check my post on FreeRTOS for the ATmega2560/1 on AVR Freaks (http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=70387 ) you will find that I describe how to place function pointer targets in low flash. I should point out that there *is* another fix for the problem: I understand the IAR and CodeVision have compilers capable of handling the larger ATMega series. Oh wait, those cost *money*. Well, Cheap Fast Good - choose two. Best regards, Stu Bell DataPlay (DPHI, Inc.) _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list