DATA 0020H 000BH BIT_ADDR ?BA?XXACT_H BIT 002BH.0 0000H.1 UNIT _BIT_GROUP_ 002BH.1 0000H.7 *** GAP *** IDATA 002CH 000FH UNIT ?ID?XXACT_H 003BH 002DH *** GAP ***
So from what i know Bdata start from 20H and have 16byte of space. I only used 8 bytes in my program however when I want to declare a new bdata
unsigned char bdata test;
the address space overflows.
Checkign the M51 file, it appears that the IDATA is taking up the bdata space??? Is it? Why? How to solve this problem?
Have you read up on the memory architecture of the '51 chips?
They have more than one way of accessing data, which is a reason that segments can overlap.
Your BDATA segments is such an overlapping segment - making a small part of the memory bit-addressable by the use of special instructions.
I don't have the time to describe all parts of the '51 memory layout and addressing modes, and some posters on this forum thinks that linking to the Keil manual should be reason for banning.
YES i know all this memory architecture stuff... my question is why all these I used
unsigned char idata Name[10] _at_ 0x68; unsigned int idata TestCH _at_ 0x73; unsigned char idata DACSH _at_ 0x75; unsigned char idata DACSL _at_ 0x76; unsigned char idata DACDH _at_ 0x77; unsigned char idata DACDL _at_ 0x78; unsigned char idata Glevel _at_ 0x79; unsigned char idata DACCH _at_ 0x7A; unsigned char idata DACCL _at_ 0x7B; unsigned int idata BTG _at_ 0x7C; //Gate on Cnt unsigned char idata BTD _at_ 0x7E; //Gate delay unsigned char idata BTV _at_ 0x7F; //Total line-2
all these didn't overlap the bdata area. But how come I can't add more bdata varaibles???
and I am able to do so after I take out the _at_ keywords.
"But how come I can't add more bdata varaibles??? "
Because adding bdata pushes up data and idata.
Don't use _at_ unless you need your variable to match up with hardware at a specific location. You are seriously inhibiting the linker from doing it's job. The BDATA variables MUST be located within a very limited part of the '51 memory space since the instructions to perform bit operations are hard-wired.
Then you have a lot of variables that you say must be placed at fixed locations.
What do you think the linker should do if your two separate requests collides with each other? It can't ignore one of your requests, so it is forced to fail.
but there is still space in the first 128byte of internal RAM. Or doesn't the "GAP" in the M51 file means space available?
thanks I got what you saying but I am just wondering because I didn't fix any data in the bdata memory space area, why wouldn't the linker push the data out and allow me to add new bdata? There is enough space in the first 128byte of memory for this "push" procedure to be carried out.
Don't use _at_ unless you need your variable to match up with hardware at a specific location which begs the question: what kind of hardware will ever "match up" with BFATA, DATA, IDATA?
I vcan noit visualize any MMIO except as XDATA. Well, as an oddty, maybe CODE if read only.
So, to the OP get rid of the _at_ they serve no purpose.
also, re 'gaps' the linker takes all variables in a given segment as a block, so if e.g. you have a BDATA at 0x20 and no register bank switches, then, if the smallest block of variables is 0x19, you will have a gap from 0x08 to 0x1f.
Erik
thanks erik, I am still studying on why the original program owner use the _at_ keywords. As of right now I do no see any special purpose or function to it. I removed the _at_ keywords and everything seems to run smoothly(and I hope it stays that way ^^)
so you mean that gap doesn't really mean "free space"? it is actually an area for buffering?
"so you mean that gap doesn't really mean 'free space'?"
Not at all! It certainly is an unused area of memory.
What Erik is saying is that the Linker treats all data from a single module as a group, and it cannot find a group of data that's small enough to fit into the gap - therefore it can't use it.
By fixing some variables at absolute addresses, you leave the Linker only the gaps between them into which it must try to fit all your other variables.
The problem is the same as fragmentation on your PC's hard drive - and is common to many computer storage systems:
en.wikipedia.org/.../Fragmentation_(computer)
As an analogy, consider that you have a load of boxes that you want to fit into a storage area: you know that the total volume of the boxes is less than the total volume of the storage area, but the storage area has some pillars at inconvenient locations. The pillars get in the way, and make it impossible to actually arrange the boxes to fit into the area - even though you know that the volume is sufficient!
Your absolutely-located variables are the "pillars" getting in the Linker's way!
"I am still studying on why the original program owner use the _at_ keywords. As of right now I do no see any special purpose or function to it."
From this, the lesson to learn is the importance of Commenting your code to clearly explain the reason(s) why you do what you do!
GOT IT! thanks once again :) case closed will post if more questions