Banked RAM for IP code section

[reallive1]

Hi, we plan on migrating from HCS12DP512 to HCS12XDP512 in order to have more RAM.  Most of our code are taken from IP core(Intelectual Property Core) of wich we do have access to the source code but would wish not to edit it.

After reading other post, we concluded that all variable that are to be taking place in paged RAM must be followed by a pragma section. 

If we make abstraction of driver issue, is there a way to compile our code, currently running on 9S12DP512, for the 9S12XDP512 without modification?

We tried to do so with a demo version provided by Freescale.  As I expected, result are that compilation works but link failed with L1102: Out of allocation space in segment RAM at address 0x3FA6.

Tests were made with default project for Banked memory model with Metrowerk 4.6.  Since RAM section in default PRM is 8k, the received error was expected.

Any clue?
Thanks
Fred.

[Alban]

Hello,

The code is probably incompatible without modification.

The Interrupt Controller is different and if you use interrupt nesting, code requires modification.
Ditto if your code is using HPRIO to promote an interrupt on top of others.
On S12X you have 7 different levels of interruption priority. On S12 you only have one level with promotion of one vector possible.

Memory Controller is also improved. On S12, you only have ONE paging register called PPAGE. On the S12X, you will have a dedicated RAM paging register called RPAGE.
S12X also offer Global addressing (GPAGE) allowing to access any location from any piece of code without touching PPAGE/RPAGE... and using the new dedicated global access instructions.

You have an application note available to describe differences between S12 and S12X. You could have a look and ask questions if you want to know more.

Alban.

[reallive1]

Hi

As I said, if we make abstraction of driver issues, I figured out that RPAGE, PPAGE, GPAGE and EPAGE does give you some advantage when you are writing down your own code.  Problem is that we do have 2 IP core wich require from 4.5Kbytes to 5Kbytes, not including memory requiement for driver, services, OS, etc..., witch bring us close to the 12K phisical barrier of the 9S12DP512, thus the need for us of a micro like the 9S12XDP512. 

We tried to build the stack(without driver implementation), but it failed to link as mentioned earlier.  With the 9S12DP512, we never had to take care of the PPAGE(exeption made in our OS context switch) as the compiler/linker was taking care of making relevent function call and memory placement.  How can I make Metrowerk to take care of all the xPAGE register?

How can I compile this simple code:

unsigned char array1[4096], array2[4096], array3[4096];

void main(void)
{
    unsigned int x,y,z;
    for(;
    {
        array1[x]++; array2[y]++; array3[z]++;
        x++; y++; z++;
        x %= 4096; y %= 4096; z %= 4096;
    }
}

As application note, help, other post, as mention, placing FAR in front of the variable will make the code run properly.  Unfortunatly, we do wish to revise our IP core as it would take quite a long time.  Basicly, is there a way to make code( C code) in a maner that we do not have to take care of xPAGE register?  Of course, we do understand that specific OS port as well as physical driver will have to deal with these register. Most of our IPs core code are strict ANSI C compliant( FAR keyword is not ANSI C compliant)

Thanks for your time
Fred

[CompilerGuru]

If you want to place array1 into the paged area you have some options:

- use the banked memory model
in the banked memory model, the compiler requires you to explicitly place this array, as by default it will end up non banked.
E.g.

#pragma DATA_SEG __RPAGE_SEG MyOwnSegName
unsigned char array1[4096];
#pragma DATA_SEG DEFAULT.

With this in place array accesses will work just fine, however if you do have pointers to this array,
then they will also need to be qualified. Either with __rptr or __far (for access via RPAGE or GPAGE)

If this version is an option for you depends on your setup, can you add the pragma? Are there pointers or just array accesses with indexes?
If you dont know or are not sure, well, then this may not be an option for you.

- if the code which is accessing a certain array is just executed in a certain context, then it may be possible to set RPAGE before that code gets executed.
For example in a OS case, every thread may have its global variables on another RPAGE and the OS could set RPAGE before that task would get executed. So the task code would not have to know about the paging at all.

Depends on your setup if this works, but I could imagine that.

- use the large memory model
Well, on the HC12/HCS12 I would think very carefully before using this.
On the HCS12X the overhead is still significant, but much less than for the HC12/S12. Basically in the large memory model the compiler will use 3 byte pointers and set GPAGE for everything and and the new G-load/stores for every access.
So that significantly more code than for the banked memory model, but for the HC12/S12 such far accesses did require a runtime routine call.
So using the large memory model would satisfy all needs for the ANSI compatibility, but it might not be an option because of the code size or execution time behavior. It all depends on your use case.


Especially the OS - task switch approach would be rather efficient. Not sure what does work for your use case though-

Daniel


Message Edited by CompilerGuru on 2007-07-06 01:36 PM

[Steve]

You'll get the best answer for this from the tools folks but essentially you place your arrays in paged memory using the linker #pragma directives and associated linker entries
Something like:
#pragma DATA_SEG __RPAGE_SEG PAGED_RAM

unsigned char array1[4096], array2[4096], array3[4096];

where PAGED_RAM describes the RAM pages you want the arrays to occupy. From then on code that accesses the array will use RPAGE. I don't know if that will work inside precompiled code though.

Have a look at TN238 which you will find in this zip file: http://www.freescale.com/files/soft_dev_tools/doc/support_info/CW_816-bit_Technical_Notes_SP.zip

[Alban]

Hello Fred,

Adding the FAR is to specify that you want to force Global access (23-bit addressing).
You can change the location of variables from the linker parameter files (PRM).
This way, you chose where the variables will be without touching at the code itself.

Alban.