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.
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~!
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 idata Namse[10];
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
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
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
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!
But when it is (example) x[1] it does the construction in question is x[y]
try to compile both and look at the generated assembler. I do not need to see what I know
I do not need to see what I know
Oh lordy.
I will not get dragged into an Erik verus Jack style discussion.
But it is tempting!
Goodbye.
No such intention :)
Just informing you that I have actually learned a little bit from working with Keil for more than a decade