MC9RS08KA8 RAM and INT issue

[JakeP]

I'm using an MC9RS08KA8 for a simple application that does some basic math, PWM, and ADC and I'm having 2 unusual problems that I'm having trouble with...

1) I need to do math wiith 32 bit variables (unsigned ints), however whenever I declare a variable of size 32 bits and I go to build the project the compiler says that it's out of RAM.  I know it's not out of RAM because I can declare 2+ word size variables instead of the single 32 bit variable and it will compile successfully.  I've used 32 bit variables with HCS08 processors before and it wasn't an issue.  Do RS08s not like 32 bit variables??

2)  I have also run into a problem when I compile the project the compiler says its out of RAM even when I know its not.  The processor I'm using has ~256 bytes, but the compiler seems to think it only has 126.  I went into the build options in the CPU bean and found that I had to manually enable the 5th area of ram that has an extra 96 bytes, but even after doing so the compiler says it runs out of RAM at the same address as before I enabled the additional area of RAM.  For some reason the additional area of RAM doesn't seem to recognized.  What's up here??

I'm using codewarrior 10 and have all the defaults set in the project options.

Any help is greatly appreciated!!

Thanks

[CompilerGuru]

Not all the RAM is equal, the first 14 bytes are especially cheap to access, then there is the zero page (which also contains some registers and a 96 byte page window) and then there is the paged/far RAM.

Sounds like you are running out of one of the cheaper sorts of RAM (I guess near). So you have to explicitely place some of the less often used variables in far ram. Did not use use the RS08 compiler for many years, so all this just out of memory, and without any guarantees (or samples :smileyhappy: ).

Basically check your map file and your prm file to see where there is unused ram and then place rarely used variables in there.

The RS08 supports long as 32 bit integers (int's are 16 bit). Of course using longs will create quite a bits of code and also use a few runtime routines depending on the operation.

Daniel

[bigmac · Accepted solution]

Hello,

For the RS08 devices, the situation is a little more complex because they do not have a stack.  Therefore, the compiler needs to create temporary variables that are allocated to the .overlap section within RAM.  The total size of this section will normally significantly exceed the total memory requirement for the project global variables.  As Daniel suggested, check the actual RAM allocations within the project map file.

As an example, I created a very simple project with two 32-bit global variables, one 16-bit global variable, and one 8-bit global variable.  The project contained two simple functions, with both returning a 32-bit value.  One function required a 16-bit and a 32-bit parameter, and the second function required two 32-bit parameters.

unsigned long func1( unsigned int x, unsigned long y);

unsigned long func2( unsigned long x, unsigned long y);

This project required a total of 40 bytes of RAM (in addition to the "reserved" tiny RAM).  The globals occupied 11 bytes, and the remainder were temporary variables, according to the map file..

A method of reducing the number of temporary variables, is for function parameters to be called by reference, rather than be called by value.  This is particularly so for any 32-bit parameters.  The function prototypes then became -

unsigned long func1( unsigned int x, unsigned long *y);

unsigned long func2( unsigned long *x, unsigned long *y);

The result of doing this was to reduce the total RAM requirement from 40 to 31 bytes, a very worthwhile reduction.

Of course, MCU types that provide a stack, including the MC9S08 types, can have run-time problems if the stack size is made too small, perhaps because of limited RAM.

Regards,

Mac

[JakeP]

Thanks for the feedback guys, I've had to sideline this project for a little while but I'll try to get back to it and give it a shot soon. 

Thanks!

Jake