Re: [avr-gcc-list] I am porting uC/OS-II into the Mega8515 but it doesn't seem to work.

[Julius Luukko]

On Thursday 11 September 2003 10:22, Joerg Wunsch wrote:
> As Julius Luukko <address@hidden> wrote:
> >... However, I have read somewhere (possibly in this list or avr
> >freaks forums) that there might be some problems locating the stack
> >in the external memory. The stacks of the tasks get located in
> >external memory. Does anyone know, which of the avrs might have this
> >problem?
>
> Early AVRs did have some errata that prevented external stack from
> working, but current chips (like all the ATmegas except perhaps the
> 103) are not supposed to suffer from that.  Anyway, there's still the
> problem that external memory access is slower than internal RAM, so
> i'd consider locating the stack in external RAM not to be optimal.
>

When using an OS, the internal SRAM won't always be enough for task stacks. 
And to clear this case (uC/OS-II as the OS): you can put your stacks in 
either internal or external memory, you can also have a mixture of both kind 
of stacks, there is no limitation.

My test program uses 26% of the CPU's time (the OS reports this) with 
everything in the internal SRAM. If other data than the task stacks are moved 
to external SRAM, the CPU usage is 36 %. Moving also the task stacks to 
external SRAM, the CPU usage is 38 %. The tasks do not use much local 
variables, so the stacks are mainly used only for the context saving. This is 
not a very scientific test though...

> OTOH, using the absolute instructions where a relative one is
> sufficient is wasting a good bit of ROM and execution time.  There
> were ideas around to have them substituted by their relative
> counterparts during linking when the target address is within reach
> (something the IAR compiler is already doing).

I know that it wastes both time and space, but in my case I had to use 
absolute calls since depending on how much code there actually was, the 
subroutines ended up too far from the call. And since the subroutines were 
from different source files, changing the linking order was not a generally 
applicable solution. If the compiler could decide which to use, would 
definitively be nice in this case, since these calls are done in every task 
switch and OS tick interrupt.

> >In order to the assembler code be usable with avrs that doesn't have
> >a "call" instruction but only "rcall", what is the best way to check
> >this.
>
> If you've got <avr/io.h> included,
>
> #if FLASHEND >= 0x2000
>   use absolute jmp/call
> #else
>   use relative jmp/call
> #endif
>
> should work.

It does! Thanks Jörg.

-- 
D.Sc. Julius Luukko
Laboratory of Control Engineering/Department of Electrical Engineering
Lappeenranta University of Technology, FINLAND
phone:+358-5-621 6713, fax:+358-5-621 6799, www: http://www.ee.lut.fi