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

[Julius Luukko]

Hi Eric and all,

(I hope that someone else than Eric also reads this)

On Wednesday 10 September 2003 06:44, Eric Guo wrote:
> I am just new to uC/OS and AVR world, but I have already used gcc two
> months & read the uC/OS-II book  at least once.
>
> Now I am porting uC/OS to mega8515, using Julius Luukko's mega128 porting
> at-avr-jlu-210703.tgz (already replace the file avr_isr.h).
> http://ee.lut.fi/staff/Julius.Luukko/ucos-ii/index.html
>

I'm interested in supporting as many of the avr's as possible in my port, so 
please inform me of any changes you need to make in order to get it usable.

> I am using external memory mode (HTT62256SRAM 32K), So I change makefile
> LDFLAGS = -Wl,-Map=$(TARGET).map,--cref
> into
> LDFLAGS =
> -Wl,-Map=$(TARGET).map,--cref,-Tdata=0x800260,--defsym=__heap_end=0x807fff.
> to relocate .data and .bss section into the external memory.
>

I have now tested the example program with external memory with mega128 so 
there shouldn't be any problem. 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?

> I also add following lines to test.c
> /*
> ***************************************************************************
>*********************************** *                                  
> Preinit the external memory
> ***************************************************************************
>*********************************** */
> void my_init_mem (void) __attribute__ ((naked)) \
>     __attribute__ ((section (".init1")));
>
> void my_init_mem (void)
> {
>       MCUCR=(1<<SRE);
>       EMCUCR=(1<<SRL2);
> }
> to enable external memory at early stage.
>

I expect that you have tested the external memory without uC/OS-II? I didn't 
check your initializations from the data sheet.

>
> I replace UART0 into UART several place in the test.c in order to seem the
> classic uC/OS-II output.
>
> 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?

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. Do I have 
to check every chip like this

#if defined(__AVR_AT90S2313__) || defined(__AVR_AT90S4433__) || # etc

or is there any other way. I need to have the "call" instruction for bigger 
chips, since depending on the uC/OS-II configuration, the subroutines might 
be located too far for calling them with rcall.

> After done this, the Mega8515 seems still doesn't work. I am using
> WinAVR-20030424 but have no ICE, so it is very different to debug this
> problem.
>
> Who have already done this? Can you give me some advice?

You'll have to be a bit more specific about "not working". Do you have any 
leds in your board that you could flash to see a proper operation? Decrease 
the number of tasks from the default and put a longer delay to the tasks, 
e.g. half a second

OSTimeDlyHMSH(0,0,0,500);

and instead of sending anything to the UART, just flash a led with each task.

I'm considering putting a bit simpler example program to the port, but haven't 
had the time.

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