We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi, I have declared the constant array for storing the data since I am having a limited RAM in lpc2214 now I want to put in the value in this array how it is possible in Keil UV3 for ARM. I have tried with doing it in,standard C way, but it dosent work. I am giving here the code example.
const int arr[12][900] void main() { int i,j; for(i=0;i<=12;i++) { for(j=0;j<=900;j++) *(int *)&arr[i][j]=5; } }
Thank you very much for your reply, but can you list the step for IAP and How I can implement this in C?
"can you list the step for IAP"
That would be in the Datasheet for the particular chip, and has nothing specifically to do with Keil tools.
However, as Reinhard said, you only need to use this if you want to modify the values - and if you do want to modify the values, why are you declaring them as const?!
If you just want to assign constant values (eg, some message strings), then just add an initialisation to the array definition - in the normal 'C' manner!
"and if you do want to modify the values, why are you declaring them as const?!"
Looks like the OP is just trying to reserve some space for flash data storage. Declaring the array as const is a way of forcing its allocation to code memory. Then the IAP api could be used to store values in the 'const' array.
That is a little bit dangerous if the array is declared in the same translation unit as the code that accesses the array, since the compiler is allowed to elliminate real accesses to uninitialized const objects, or to collapse several initialized const accesses to a common alias, to save code space. RV is a very good compiler and it will always take advantage of const objects. Besides, if the const array element address can be statically determined, the compiler will not access the expected address at all, but reduce the access to a immediate constant value.
One way of forcing the data to be read from the actual address would be to declare the array as extern, and define it in a separate source file, since that would prevent the compiler to know enough about it to optimize the accesses.
WARNING: during any IAP call, the code flash cannot be used to execute code. Any active interrupts must be handled in RAM, or all interrupts must be disabled.
So, step-by-step:
1) Declare the array in a separate .c file, to conceal it from the compiler optimizer. Initialize the array with 0xFF (erased) in all positions.
2) declare it as extern in all .c files that reference it. The accesses will not be optimized-out by the compiler.
3) Use standard C to get the address of the array element you want to modify, and use the built-in IAP functions to change its contents.
That will allow you to change the contents of the array one time only, since the flash needs to be erased to be reprogrammed again. If you want a eeprom simulation, your array must be allocated in a sector of the flash that can be erased without wiping out your program code in the process. Look on the datasheet and the chip manual for the flash memory map and erasable sectors.
"Declaring the array as const is a way of forcing its allocation to code memory."
Note: that is compiler-specific, so the toolset needs changing back to ARM
(eg, const does not force stuff into CODE space in C51...)
"Note: that is compiler-specific, so the toolset needs changing back to ARM"
I saw it just after posting... I really would be nice to be allowed to edit posts after submitting :-)
Actually, in RVCT, const objects will not always be allocated into code space. For example, if you qualify the const data object as volatile, it will be allocated as a initialized, non-alterable object in RAM.
Another, more robust approach (albeit more complex) to this would be to force the linker to allocate the array at the flash area, in a specific flash page, to be able to erase the page without destroying program code. That can be done using pragmas to declare named sections, and linker commands to allocate the sections to absolute addresses.
Besides being very compiler-specific, all this IAP stuff is manufacturer specific, of course.
"all this IAP stuff is manufacturer specific, of course."
Quite possibly even chip-specific.