[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-gcc-list] I am porting uC/OS-II into the Mega8515 but it doesn
Re: [avr-gcc-list] I am porting uC/OS-II into the Mega8515 but it doesn't seem to work.
Thu, 11 Sep 2003 12:46:28 +0300
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
> 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
> If you've got <avr/io.h> included,
> #if FLASHEND >= 0x2000
> use absolute jmp/call
> use relative jmp/call
> 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