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.
Hello,
Q1: This is a part of my project code flow explanation. I want to allocate seperate memory location in internal data for the formal parameter local variable - lid. How is it possible using Keil options. By default, it is being allocated in the overlaid DATA_GROUP . I cannot use NOOVERLAY, as the runLineTask() routine is too large.
void runLineTask(unsigned char volatile lid) //this runs forever { unsigned char volatile idata i; switch(stateChange[lid])//depending on the change in state, a case is selected // and its related piece of code is executed { case ON: case OFF: . . . . . . default: ----- } ----- ----- ----- ----- } void main(void) { -- //The basic hardware initialization and variables dseclaration -- // is done here -- -- while(1)//this is the loop which runs forever in real-time { for(i=0;i<NUM_TASKS;i++) //NUM_TASKS = 10 runLineTask(i); } -- -- -- }
Q2: What are the overhead problems on the controller if we use idata type for most most frequently used local variables (in while loops) in my project code?
Please advise.
The only control you have over where parameters are stored is by changing the memory model (or making the function reentrant).
The real question is, why do you want to do this? What is wrong with allowing the compiler to put it into DATA_GROUP?
The "volatile" as part of a function argument looks very strange. I cannot really think of any case where such a construct may be necessary.
If you really need to access a volatile (i.e. "can change without the compilers knowledge") variable in a function, why not make it a global variable ? Then you also have control over the memory location (either by using the linker or by using _at_).
Sorry, but you seem to have mixed up the definition of global variables and parameters.
Yes, the Keil compiler can use a global (shared) variable for the parameter, since it doesn't have a real stack to push the parameter to. But, the usage pattern will still be the same, i.e. the caller copies a value to this global (secret) variable. Your function gets a parameter that works as an alias to the global variable.
No other part of the code will at the same time have access to the parameter/global variable, so no other part of the program will be able to change it's value, unless you do something really stupid and plays with out-of-bounds pointers or similar. Note that if you take the address of a parameter, that pointer is only valid until you return from the function. Even if the global variable will continue to exist, that memory are is undefined according to the C language standard!
In short, a volatile parameter is meaningless unless your program is broken. But if your program is broken, you should still not have a volatile parameter, but instead fix the part of the program that tries to access this shared global variable in an incorrect way.
If you want to control the address of the variable, you could pass a pointer parameter.
void runLineTask(unsigned char volatile idata* lid) ... runLineTask (&i);
Note that the parameter in this case is the pointer, and the compiler will place it whereever it wants, not necessarily in idata. Your "lid" will live somewhere in idata.
Locating information in idata means that you must always access it indirectly, through a pointer in a register. This is somewhat less efficient that direct data access, and somemore more efficient that xdata access. idata is also commonly used for the hardware stack (SP). If you plan to use a lot of it you should be careful about your stack size.