can any one give me the meaning of following line
#define COUNT 2000 #define KEY2 0x2F #define KEY1 0xF8
COUNT,KEY2,KEY1 are the name's given which we going to use next in the prog. but what is 2000,0x2F,0xF8 is address i.e memory location or simply just value.
Hmmm... don't know what went wrong there!!
#define LEN 128
defines a macro named LEN. When LEN is used in your program (or in preprocessor directives) it is replaced with the text 128.
That is all it does - nothing more, nothing less. The preprocessor simply goes through your source text; everywhere it finds "LEN" it replaces it with "128"
This is basic 'C' stuff - nothing specifically to do with Keil, embedded systems, or the 8051. You need to go back to your 'C' textbook.
"KEY2 0x2F means port location address"
It has no specific meaning at all - it is just a pure text substitution. You (or the author of the code) may choose to use it with that meaning, but it is not inherent in the #define you show
"val 0xF8 means read the value from given address"
No: again, it says nothing about reading, values, or addresses.
#define COUNT 2000
it mean's when ever the COUNT appears replace it with 2000;
#define val 0x0f
it mean's when ever the val appears goto the memory location 0x0f and pop-up the value
or it's meaning is totally un explanable because it know's only by auther
#define COUNT 2000 it mean's when ever the COUNT appears replace it with 2000
Correct!
#define val 0x0f it mean's when ever the val appears goto the memory location 0x0f and pop-up the value
No!! It has exactly the same meaning as in the first example!
It means purely and simply that wherever val appears it will be replaced with 0x0f
eg,
#define val 0x0f int fred; int array[16]; fred = val; // assigns the value 15 to fred array[val] = 3; // assigns the value 3 to array[15] if( fred > val ) // Tests if the value of fred is greater than 15
Remember, 0x0F (hex) is 15 (decimal)
"its meaning is totally un explanable because it known only by author"
Absolutely - if the author is thoughtless enough to not provide any documentation (whether in the form of comments ot otherwise).
As you say this is "sample" code, you need to ask yourself whether your time is going to be better spent trying to understand the "sample", or if you'd be better off just writing it yourself from scratch!
do not waste time "asking yourself", you WILL "be better off just writing it yourself from scratch"
The only value of "sample" code I know of comes after you have written the code for what you want to do yourself. At such time you understand what it is all about and, at that time, sometimes - not always a look at "sample" code can give a hint to where the error in what you wrote is.
Erik
i have put one more question in forum can u answer that sinciarly i.e. truly
can u answer that sinciarly who would know if micro can asnwer but himself?
I think your time would be better spent in studying your 'C' textbook rather than worrying about Keil's internal policies!
http://www.keil.com/forum/docs/thread8516.asp
sorry but there is some thing that u don't know and on that thing u r working
y r u 2 la-z 2 rite "you" etc?
just in case, as so often it is, the poster can not understand "back at you" here it is spelled out
If you are too lazy to write you, why should we not be too lazy to answer?
"As you say this is "sample" code, you need to ask yourself whether your time is going to be better spent trying to understand the "sample", or if you'd be better off just writing it yourself from scratch!"
Then what will the other person do, sit jobless?
"Better off just writing it yourself from scratch!" Then i wonder what is there for the other person to do, to sit jobless?
"Then what will the other person do, sit jobless?"
What other person?
If you mean the one who provided the "sample", then they ought to be fired for writing such rubbish, and setting such a bad example!
"If you mean the one who provided the "sample", then they ought to be fired for writing such rubbish, and setting such a bad example!" Thats right, So, i'l fire the "sample program" for giving all the trouble ... why i never thought about it earlier...