[En-Nut-Discussion] ATmega2561

[Harald Kipp]

Hi Rob, Dusan,

>> 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.
>>     
I tried to figure out the trampoline mechanism in GCC, but gave up due 
to lack of time. Somehow it seems to work.

>
> '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. 
>   
GCC uses a different way to handle function pointers. As the trampolines 
are located in the lower half, GCC needs 16-bit function pointers only. 
But, as I said, I didn't fully understand it.

> 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__)?
>   
I started with the first, but the second is definitely better and 
pre-defined in avr-libc. I'd prefer to use it for ICC as well, which 
requires extending the ICC specific header file.


> So, like you, I would like to ask Harald: what is the current status of
> GCC/NutOS for the Mega256?
There are very few egnite customers using it. After the last release I 
haven't heard about any new problems. But that means nothing, as most of 
them are busy people and may currently work on other projects.


> - adding -g-dwarf-2 -O0 to compile NutOS and the application makes the
> codesize increase by > 40K (?)
>   
Probably a result of -O0 and the way your code is written. The GCC 
optimizer does a very good job. When switched off, it really compiles 
one to one. An example:

The final binary of

int foo(int bar)
{
  int rc;
  rc = bar * 2;
  return rc;
}

will not differ from

int foo(int bar)
{
  return bar << 1;
}

...as long as the optimizer is enabled.

I have not tested it yet, but you may try to use less aggressive 
optimizations (-O1 or -O2) and still get debugable code.

> - loading the .elf file into Studio (V4.13) takes ages and finally nothing
> works 
>   

I tried a few samples with AVR Studio 4.13 Build 528. Compared to 
previous versions it works great. Still got trapped in interrupts or the 
idle thread sometimes or even crashes from time to time. IMHO, it is 
usable now. I also experienced long load times, but not that annoying 
really. Though I didn't test real apps, but "pumped up" the existing 
samples with some useless dummy routines.

Harald

P.S. For those who may not know: AVR Studio 4.13 Beta is available at
http://www.atmel.no/beta_ware/