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

Memory declaration problem

How come there is obviously space (gap) in the memory, but when I declare the Test[10] between the 0x34 and 0x62 the program kept saying overlap and address overflow.

IDATA 0029H 000BH UNIT ?ID?XXACT_H 0034H 002FH *** GAP *** IDATA 0063H 0001H ABSOLUTE 0064H 0004H *** GAP *** IDATA 0068H 000AH ABSOLUTE 0072H 0001H *** GAP *** IDATA 0073H 0002H ABSOLUTE

unsigned char idata Test[10] _at_ 0x34; //new declare
unsigned char idata Name[10] _at_ 0x68;
unsigned int idata TestCH _at_ 0x73;

help~!

  • Perhaps all the "_at_" nonsense is working counter-productively against the toolchain. Is all th_at_ really necessary?

  • Addresses 00..7FH are also the "data" space. This space is used by the overlay analysis in the small memory model. It's also used for any "data" variables you might have declared.

    Are you displacing other information when you add the declaration for Test? I don't know off the top of my head if the linker is smart enough to show you data usage in the idata map where they overlap, or whether is just says "nope, no declarations in just idata there".

    As long as you're forcing the locations of these variables to the lower part of the internal RAM, why not declare them "data"? Access will be a little more efficient than "idata", which is indirect (hence the 'i') via a register used as an 8-bit pointer.

  • The problem is when I put

    unsigned char data Namse[10];

    the program shows

    *** ERROR L107: ADDRESS SPACE OVERFLOW SPACE: DATA SEGMENT: ?DT?XXACT_H2 LENGTH: 0049H

    The program is very long (3600 lines) and most of the memory space has been used up. And I need more variables!
    HELP!

    right now I can't even declare
    unsigned char Namse;
    nor
    int hi;

    all gives me address space overflow...
    any suggestions?

  • by the way...
    I have two version of the program
    #1 has less code and less variables used
    #2 lot more code and more variables used

    however...
    in program #1 Name is declared as:
    unsigned char idata Name[10] _at_ 0x68;

    in program #2 is declared as
    unsigned char idata Name[10] _at_ 0x62;

    and when i tried to change the 68 to 62 in program #1... it overflows again...
    WHY? HOW!
    can somebody please direct me to where I can find the answers???????

  • unsigned char data Namse[10];

    the program shows

    *** ERROR L107: ADDRESS SPACE OVERFLOW SPACE: DATA SEGMENT: ?DT?XXACT_H2 LENGTH: 0049H

    unsigned char idata Namse[10];

    the program shows

    NO ERROR(S)

    Errik

  • WHY? HOW!

    Because instead of using them, you're trying to fight the tools for no apparent reason. And so far it looks like the tools are winning by a comfortable margin.

    What makes you think you have to make your own decisions about memory allocations for individual variables? The linker/locator and the compiler are quite good at that job as it is. Why interfere with their work?

    For the record: if you're going to have that variable in _idata_, the 0x6* range is hardly the best place to put it. The linker would have known that. But you told it you know better.

  • ohhh.... i see... so i shouldn't have use _at_
    thanks hans....

    and erik you are right.. but how come??? thx~

  • "ohhh.... i see... so i shouldn't have use _at_
    thanks hans...."

    Ah yes, two days later made it ripe and fit for consumption.

  • and erik you are right.. but how come???

    I know you will hate me for this, but

    this question is so basic thet there is no point in answering it. You need to get your basic understanding of the '51 brought to an, at least, rudimentary level.

    so STUDY, STUDY, STUDY
    first read "the bible"
    then work through the getting started guide.

    Erik

    here are the links to "the bible"
    Chapter 1 - 80C51 Family Architecture:
    www.nxp.com/.../80C51_FAM_ARCH_1.pdf

    Chapter 2 - 80C51 Family Programmer's Guide and Instruction Set:
    www.nxp.com/.../80C51_FAM_PROG_GUIDE_1.pdf

    Chapter 3 - 80C51 Family Hardware Description:
    www.nxp.com/.../80C51_FAM_HARDWARE_1.pdf

    the getting started guide is on the Keil CD

  • Errik

    Why you want to put in idata?

    You know data access is more faster

    AND idata like this no good on 8051!

  • When one memory area is full, it doesn't matter if it is faster or not. Something must be moved.

    That is why it is important to look at variables and make as small arrays as possible, and to use byte instead of short/int and to use bit variables where applicable.

  • Per

    That is why it is important to look at variables and make as small arrays as possible, and to use byte instead of short/int and to use bit variables where applicable.

    Yes you are right.

    But have I seen memory size of chip in thred messages? no.

    So if 8051 then idata is waste of time (8051 has no separate idata space).

  • refar,

    The 8051 doesn't have a separate idata space, but the 8052 does. I'm also willing to bet that we're not really talking about an original 8051, so using idata is a pretty safe bet. Still, perhaps not the best idea given than each byte of idata you use takes away from stack space, but such is life.

    -Jay Daniel

  • Why you want to put in idata?
    You know data access is more faster
    AND idata like this no good on 8051!

    it makes no difference! when it is x[y]

    try to compile both and look at the generated assembler

    Erik

  • it makes no difference! when it is x[y]

    Correct

    But when it is (example) x[1] it does

    try to compile both and look at the generated assembler.

    Ok might not be all the time.

    But when you use only 8051 compatible core (as I often have to) every little bit helps - I know!