I need to assign many variables in the multiple RPAGEs (due to total number of vars exceed the one RPAGE size)
To access a var in RPAGE, the Freescale technical document TN238 shows as follows:
#pragma DATA_SEG __RPAGE_SEG PAGED_RAM
unsigned char rub_far_var;
#pragma DATA_SEG DEFAULT
A pointer pointing to such a variable can be defined as follows:
unsigned char * __rptr ptr_on_far_var;
Then assign the pointer to this var
ptr_on_far_var = &rub_far_var;
if you want to access this var, you need to use this pointer.
ptr_on_far_var = 5;
if (ptr_on_far_var == 5)
{
...
}
My question is that can I just assign __far var instead?
all I need to do is as follows:
#pragma DATA_SEG PAGED_RAM
unsigned char __far rub_far_var;
rub_far_var = 5;
if (ptr_on_far_var == 5)
{
...
}
the compiler should know where to allocate the var in the RPAGE, retrieve the var from the correct RPAGE
and function the same as __rptr. So I don't need to assign an extra pointer for every variable in the code.
It seems to work. I would like a confirmation.
Solved! Go to Solution.
Yes, you can access variables in paged ram directly. far keyword or __rptr pointers are not necessary for this. Then only thing compiler needs is rounding paged variables with required pragmas, BOTH, in C file where variables are defined, AND in H file, in case variables are exported to other C files with extern keyword. Compiler needs to see #pragma's to know where to allocate variables (in PAGED_RAM or not), and how to access variables __RPAGE_SEG for access via R-page window at 0x1000..0x1FFF or __GPAGE_SEG for access using global addressing.
in H file
#pragma DATA_SEG __RPAGE_SEG PAGED_RAM
extern int my_rpage_var;
// and more R-page vars here
#pragma DATA_SEG DEFAULT
in C file
#pragma DATA_SEG __RPAGE_SEG PAGED_RAM
int my_rpage_var;
// and more R-page vars here
#pragma DATA_SEG DEFAULT
foo()
{
my_rpage_var = 5;
}
Since you are going to use more R-pages, be aware you need to care about default -PSegxxx setting, which is -PSegNonDef and is not compatible with R-page addressing of multipage PAGED_RAM PLACEMENT. Your choices are
1. Add -PSegObj to compiler command line and use __RPAGE_SEG with PAGED_RAM. Without this compiler may fail switching RPAGE when necessary to access object on different RPAGE.
2. Using __GPAGE_SEG instead of __RPAGE_SEG you don't need to add -PSegObj. This would be fine with global addressing, since even 64k of RAM fits single G-page, so default more speed effective -PSegNonDef would be fine.
3. Since R-page addressing with default -PSegNonDef could be more effective (more CPU instructions choices for non-global addressing), instead of using PAGED_RAM placement, you need to define dedicated placements for each R-page. Say RAMPAGE_F8, RAMPAGE_F9, etc, and use only these placements with __RPAGE_SEG. You will then start allocating paged variable to RAMPAGE_F8 first, then, when linker reports lack of space in RAMPAGE_F8, you will place variables to RAMPAGE_F9 etc.. This would be safe and also faster with default -PSegNonDef
Yes, you can access variables in paged ram directly. far keyword or __rptr pointers are not necessary for this. Then only thing compiler needs is rounding paged variables with required pragmas, BOTH, in C file where variables are defined, AND in H file, in case variables are exported to other C files with extern keyword. Compiler needs to see #pragma's to know where to allocate variables (in PAGED_RAM or not), and how to access variables __RPAGE_SEG for access via R-page window at 0x1000..0x1FFF or __GPAGE_SEG for access using global addressing.
in H file
#pragma DATA_SEG __RPAGE_SEG PAGED_RAM
extern int my_rpage_var;
// and more R-page vars here
#pragma DATA_SEG DEFAULT
in C file
#pragma DATA_SEG __RPAGE_SEG PAGED_RAM
int my_rpage_var;
// and more R-page vars here
#pragma DATA_SEG DEFAULT
foo()
{
my_rpage_var = 5;
}
Since you are going to use more R-pages, be aware you need to care about default -PSegxxx setting, which is -PSegNonDef and is not compatible with R-page addressing of multipage PAGED_RAM PLACEMENT. Your choices are
1. Add -PSegObj to compiler command line and use __RPAGE_SEG with PAGED_RAM. Without this compiler may fail switching RPAGE when necessary to access object on different RPAGE.
2. Using __GPAGE_SEG instead of __RPAGE_SEG you don't need to add -PSegObj. This would be fine with global addressing, since even 64k of RAM fits single G-page, so default more speed effective -PSegNonDef would be fine.
3. Since R-page addressing with default -PSegNonDef could be more effective (more CPU instructions choices for non-global addressing), instead of using PAGED_RAM placement, you need to define dedicated placements for each R-page. Say RAMPAGE_F8, RAMPAGE_F9, etc, and use only these placements with __RPAGE_SEG. You will then start allocating paged variable to RAMPAGE_F8 first, then, when linker reports lack of space in RAMPAGE_F8, you will place variables to RAMPAGE_F9 etc.. This would be safe and also faster with default -PSegNonDef
Hi Edward,
Thanks for your response.
what if I remove the _RPAGE_SEG and just declare #pragma DATA_SEG PAGED_RAM. Now I want to pass that var or a pointer to the foo() function.
foo(my_rpage_var)
{
}
Does this var or pointer need to add __far keyword? it did not work if I don't include __far.
Thx, Tim
Yes, you can avoid __RPAGE_SEG and __GPAGE_SEG, but then paged variables and pointer to paged variables have to be used with far (__far) keyword. Compiler has to know that particular variable is "not easy to access". Either it must see var declared/defined below the #pragma XXX_SEG __RPAGE_SEG (or __GPAGE_SEG), or variable has to be defined/declared with far keyword.
Function taking pointer to paged variable, also pointers which may point to paged variable need to use far keyword. Or __rptr.
Regards
Edward