[En-Nut-Discussion] ATmega2561

[PragmaLab]

> Hi guys,
> 
> what is the state of ATmega2561 & Nut/OS ?
> 
> I noticed that extended PC byte was added to AVR context switching . 
> In NutThreadCreate(), this byte was originally seeded from fn 
> address, but now it is zeroized. This limits thread functions to 
> start only in lower 128kB of flash.
> 
> Can they then call functions in upper 128kB ?

Hello Dusan,

for ICC, threadcreation and switching in NutOS seems to work well for a
while now. For GCC I tried it yesterday (GCC 4.1.1, NutOS 4.3.3). It seemed
to go OK as well, but did not check yet if indeed threads were running
>128K. Your posting made me look at the code ('context_icc.c' and
'context_gcc.c'). My conclusion is that setting the extra byte to '0' wil
prevent running threads >128K. Check the code for ICC, that part does make
sense. 

Other question that raised my mind when looking at the code, why did someone
introduce a different #define for GCC (ICC: #ifdef __AVR_ATmega2561__, GCC:
#ifdef __AVR_3_BYTE_PC__)?

So, like you, I would like to ask Harald: what is the current status of
GCC/NutOS for the Mega256? 

Other related question I have is about debugging with GCC (AVRStudio). With
ICC (COFF) it is no problem to source-level debug the code (both application
as well as NutOS) in the Studio debugger (MKII JTAG-ICE). WinAVR and Atmel
now claim that with GCC (elf/dwarf-2) it should not be a problem any more. 

But:

- adding -g-dwarf-2 -O0 to compile NutOS and the application makes the
codesize increase by > 40K (?)
- loading the .elf file into Studio (V4.13) takes ages and finally nothing
works 

Does anybody else has experimented with debugging application + NutOS in
AVRStudio for the new GCC? Is it normal the code increases when adding
debug-info? Normally it shouldn't but maybe optimisation is switched of when
using -g ?

Thanks,

best regards,

Rob van Lieshout