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?
Actually... i found out if i remove all this _at_ then the program is fine...
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 counter unsigned char idata BTD _at_ 0x7E; //Gate delay unsigned char idata BTV _at_ 0x7F; //Total line-2
but why? I didn't declare those idatas to be within the range from 20-2F...
sorry but i is not knowing you ansewr to you
do you need all _at_ for variabbles?
I am not sure... haha I am modifying the other person code but as of right now... I don't think with or without _at_ makes a difference
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.