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?
unsigned char idata Name[10] _at_ 0x68;
This is within the DATA space - hence it could cause DATA to overflow (or to stop overflowing, if you remove it)
Where can I get details on 74HCT74?
Thank you.
It is obvious that you don't believe in adding the above text in Google. Why is that?
It is obvious that you believe in stealing other peoples threads. Why is that?
If you ever visit a school - would you walk into an ongoing music lesson and ask about details on a 74HCT74?
again why you not start be new threed???? again why you not question is keil producet????
again but i helping you i think yes you know
again you take threed from other man
plz why you no use google or yahoo or book??
data for 74hct74 is easy from google at
www.datasheetcatalog.com/.../74HCT74.shtml
Kalib - as long as you help is this thread, he will continue to steal threads. Why change a winning pattern?
as long as you help is this thread, he will continue to steal threads
i think you be right so i stop now
i still learn about this forem
sorry
but how about bdata???
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.