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

[Joerg Wunsch]

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.

Details about that old errata should be found in the respective errata
sheets on the Atmel WWW server.

>> I have to replace Julius's os_cpu_a.asm "call" into "rcall" because
>> mega8515 only accept this. ("call" is a invalid opcode in Mega8515?)

>That's a bit surprising to me, since the data sheet of mega8515 lists
>"call".  Why doesn't avr-as allow this?

That's probably a mistake.  Maybe Marek can say something about that.
My guess is that all <= 8 KB devices (where rcall/rjmp can reach the
entire ROM address range) don't allow for the absolute call/jmp
instructions in gas right now.

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).

>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.

-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/