[En-Nut-Discussion] atmega2560 support

[Thiago A. Corrêa]

Hi Dusan,

   That's nice. Would you be interested in sending back your changes
for inclusion in upstream ethernut? I could add them, with proper
credit, of course. I had to upgrade my WinAVR install because we were
going to start a project using atmega1284p, but we had to go back to
644p because, despite being available on evaluation boards, 1284p
isn't yet in "production" until next year. :(
   Thanks for the compiler tip, will try that, with some luck perhaps
it will just work *smile*

   Anyway... so, did you explicitly set __AVR_3_BYTE_PC__? I can't
seam to find where it's being set, as I said in an earlier mail.

Kind Regards,
   Thiago A. Correa

On Fri, Jul 11, 2008 at 5:28 AM, Dusan Ferbas <dferbas at etech.cz> wrote:
> Hi Thiago,
>
> we put a lot of effort to run code on ATmega2561.
> Currently now, nearly all features works, but I am convinced it will
> not work once we reach 128kB flash boundary.
>
> I do not recommend to use WinAVR 20080610. With this, our code does
> not run. Worse, code size is greater, even they claim, compiler optimizes more.
> We use gcc version 4.2.2 (WinAVR 20071221).
> You can see my discussion at
> http://lists.gnu.org/archive/html/avr-gcc-list/ (look for eicall, eind, 2561).
>
> I discussed bootloader issue with Andy Hutchinson and realized, that
> compiler does not support wider (>16 bits) function pointers.
> Compiler generates eicall instructions (EIND + Z is used for 3 byte
> calls), but it never handles EIND register.
> So if you have indexed calls in your application, it will work only
> in lower 64kW.
> (Unless you manually do call with asm)
>
> BTW, anyone experienced with EIND & eicall ?
> (because it works for us in bootloader area when entered after power
> up, but not if we call it from application)
>
>>At 21:41 6.6.2008, hutchinsonandy at aim.com wrote:
>>CALL  can reach all 4M of address space.
>>
>>EICALL is special version of ICALL - which would be appropropriate
>>for non-constant function pointers. And this would be the area in
>>which near/far pointer support would be useful. However, the true
>>functions pointers inside compiler are only 16bits, so its not a
>>trivial change.
>>
>>But your code has constant pointer. So CALL  should be ok.
>>
>>Andy
>
> Dusan
>
> ------------
> At 17:01 10.7.2008, "Thiago A. Correa" <thiago.correa at gmail.com> wrote:
>>Hi,
>>
>>    I've done some of the work required to support Atmega2560 (mostly
>>preprocessor defines thanks to 2561 support already in the tree). But
>>I'm not able to "boot" the board to the user code. If I try to run the
>>code thru JTAGICE mkII it just sits there blinking without ever
>>reaching any code as it does with atmega128's.
>>...
>
> Dusan
>
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>