• State Not Answered
  • Locked Locked
  • Replies 15 replies
  • Subscribers 22 subscribers
  • Views 2145 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Init variable's memory content during comiple-link stage

Amit Alon

Hello,

Some of the variables that my program uses(may contain also big ,multidimensional arrays) have default values, which are used during the code operations and may be modified during the program's runtime.

defining a variables using:

volatile xdata arrayName = [0x01, 0x03, 0x02, 0x04...];
Will case code generation that will occupy more then twice the size of the array. It will generate code are that will hold the array's default values, as well as code that in the beginning of the program startup will copy theses values into the arrays themselves.

On the other side, writing the code as follows:
volatile code arrayName = [0x01, 0x03, 0x02, 0x04...];

(Use of code area, instead of xdata area)

Will cause the array to be generated as part of the code.
There will not be any code line that will init the array into these values, and the init values will be directly located at the generated HEX file, at the place where the array is located, during the compile-link stage.
This is good since it saves time (of the variables init) and more important – it uses much less memory area.
The problem is that defining a variable as code, will prevent it from being modified.

My question:
Is there a way to define variables, that the init value of them will be located in the array's place during the compile-link stage, and that will be modifiable during the program runtime ? can you please tell me the syntax for such a declaration ?

Thanks.
Amit A.

Parents
  • 0 in reply to Andy Neil

    Andrew,

    First of all thanks for your answer, time, and good will.

    About what you wrote: "…In that case, you could remove the initialization from the 8051 code, and supply it separately to your loader":
    I thought of this bypass-solution and came to conclusions that I will do that as a last option, if I will have no other way to do it as I wanted to do.
    There are 2 problems when working as you have suggested:
    1) Complexity and vulnerability issues: A separate application will have to mange the default values of some of the code. This is a window for bugs and mismatches, since the SW is becoming dependet on external tool and stops from functioning as a stand-alone code. There is also new dependency between the memory locations declared in the code using the "_at_" declaration and the location where the tool will put the values, which brings more complexity to the application. Another issue is the SW version's control. Now a build of the SW will be independet from the default values of the arrays and the variables.
    2) Keil's HW Debugger's issue: The Keil HW Debugger uses the linker's generated OMF file. This file will be loaded into the RAM, and this means that the Keil's debugger will not load the external default values when using it as a debugger.

    About the XCONST: I use the BL51 linker, not the LX, so it probably is not relevant anyway, and no matter what the answer is about if this declares any constant or variable memory type.

    Keil's support:
    Do you have any solution to the problem mentioned in this thread ?

    Thanks,
    Amit.

Reply
  • 0 in reply to Andy Neil

    Andrew,

    First of all thanks for your answer, time, and good will.

    About what you wrote: "…In that case, you could remove the initialization from the 8051 code, and supply it separately to your loader":
    I thought of this bypass-solution and came to conclusions that I will do that as a last option, if I will have no other way to do it as I wanted to do.
    There are 2 problems when working as you have suggested:
    1) Complexity and vulnerability issues: A separate application will have to mange the default values of some of the code. This is a window for bugs and mismatches, since the SW is becoming dependet on external tool and stops from functioning as a stand-alone code. There is also new dependency between the memory locations declared in the code using the "_at_" declaration and the location where the tool will put the values, which brings more complexity to the application. Another issue is the SW version's control. Now a build of the SW will be independet from the default values of the arrays and the variables.
    2) Keil's HW Debugger's issue: The Keil HW Debugger uses the linker's generated OMF file. This file will be loaded into the RAM, and this means that the Keil's debugger will not load the external default values when using it as a debugger.

    About the XCONST: I use the BL51 linker, not the LX, so it probably is not relevant anyway, and no matter what the answer is about if this declares any constant or variable memory type.

    Keil's support:
    Do you have any solution to the problem mentioned in this thread ?

    Thanks,
    Amit.

Children
  • 0 in reply to Amit Alon

    It will generate code are that will hold the array's default values,
    The size needed, where else would you get them from?

    as well as code that in the beginning of the program startup will copy theses values into the arrays themselves.
    That is so little code, that, if that hurt you, you are in deep doo-doo anyhow.

    I think you are trying to make the "'51 PC" (your question and "multi-dimenisional arrays" indicate that this is the case) as so many other mistaken individuals, if that is what you are trying to do, then do not expect '51 tools to help you.
    The '51 is not (and has never been intended to be) a "load before run" device".. It is a "program in permanent storage device", so that is what the tools are made to support, thus they work the way they do.

    As it has been suggested, if you do not like that the tools work in '51 mode, do not use the tools, make your own.

    Erik