How to use upper 128byte of AT89S52. i.e. SFRs(80H to FFH) Address indirectly with KEIL C51 for general purpose which are not in use. They are directly addressable only as SFR.
according to datasheet: 1. The lower 128 bytes of RAM (00H to 7FH) are directly and indirectly addressable. 2. The higher 128 bytes of RAM (80H to FFH) are indirectly addressable. 3. The special function registers (80H to FFH) are directly addressable only.
Please help me thanks!
if looking for advice, ignore all posts from Zeusti
You'll probably think I'm a Zeusti affiliate for saying the following, but here goes anyway.
The OP asked:
"How to use upper 128byte of AT89S52 in C51?" "one/two line example please."
Zeusti gave:
char idata *Pointer_To_IDATA_Space = 0x80;
Now, he may have the precise location of idata incorrect (it is a while since I used such a keyword), but fundamentally, I can see nothing wrong with the line.
Contrary to some of the replies, I don't see that as miguiding or misleading!
Heck - Have you people have never seen a need to access the memory in that manner (C or ASM)?
The valid example also given of:
idata char aVariable;
is an alternative, but it is only that, an alternative.
In my view it is no more or less right. The suitability of each would depend upon the particular requirement.
Rather than knocking Zeusti, it might be more helpful (at least to the OP) to explain when it might be suitable and what problems there might be.
Trevor, To my humble opinion the professor's rather unusual code originates from poor understanding of C. I particularly dislike his staunch arrogance and misguided self esteem. does he sound to you like somebody with a deep understanding of the subjects at hard? I don't think so.
one more thing Trevor: our self proclaimed "professor" has been around here for a while now (have you not encountered his pearls in the past?) doing more or less of the same like he has been trying to do in this thread. posting mistakes is alright - I do so myself sometimes - but misleading as he does (on a public forum) is another story!
"I particularly dislike his staunch arrogance and misguided self esteem."
I would not like to comment on his arrogance or esteem; wouldn't like to throw stones in this glass house ;)
"... unusual code originates from poor understanding of C."
In this instance I don't think it could be judged as unusual. I have used similar code to what he posted myself in the past; and I believe that it was fully justifed.
And concerning one other comment that was made about his code:
"you have designed a loop where your 8-bit processor will require a 16-bit counter just to be able to detect when it is time to leave the loop. What was wrong with designing the loop in a way that an 8-bit variable can be used?"
Hardly a cardinal sin! Of no relevance to idata!
Just wonder if the poster of that comment was aware that some optimising compilers recognise such constructs and convert them to a simple inline functions. In which case the size of the variable could be totally irrelevant! Maybe C51 has the ability to optimise this construct.
Maybe, one day, Zeusti will have a deeper understanding of C.
Maybe, one day, Zeusti will be capable of spelling Professor (or even Zeusti?) consistently.
Maybe it's best if I just avoid getting dragged into this any more.
Yes, I am aware of optimizing compilers.
The problem here isn't if the compiler inlines or not. The problem is that if you do use an 8-bit loop variable, you might be very surprised at the slow runtime if you write:
uint8_t i; for (i = 0; i < 256; i++) { }
or possibly:
uint8-t i; for (i = 0; i <= 255; i++) { }
The problem here wasn't what a compiler may optimize but the issue that the loop variable had to be 16-bit just so it wouldn't overflow on the end-of-loop test. That is a relevant warning. I prefer code written for an 8-bit processor with lousy 16-bit support to be written in a way where the code can stay in the 8-bit realm as much as possible.
And the comment should also be read in the light of the paragraph I wrote directly above, about the start address of the pointer in relation to the offses used in the loop. The pointer started at 0x80 and the loop index started at 0x80.
The big problem with "chief master programmer professor Zeusti" is that it impossible to know if he is shooting a random answer from his hip, or if he happens to know what he writes. Some posts indicates that he is totally 100% clueless, while some other posts are directly usable and indicates that he only makes attempts to pretend to not understand exactly the meaning of what he writes.
If he is regularly pretending to be clueless, then he obviously wants to get critique. If he really is clueless and still answers questions then the OP always deserves the right to know that he has to be careful about answers from the "professor".
"The problem here isn't if the compiler inlines or not. The problem is that if you do use an 8-bit loop variable, you might be very surprised at the slow runtime if you write:..."
Sorry, but I simply don't follow that one. His code used a 16 bit variable, so your comment of using an 8 bit one is highlighting a situation of your making ... Isn't it?
Sure, he had the pointer and index badly initialised, but that would not have affected the number of passes through the loop.
The examples you show for an overflow of an 8 bit count are, to be blunt, errors of a beginner in such matters - In the same manner, for example, as the lack of appreciation of sign-ness of a char.
Per, I really don't mean to offend - And I REALLY don't want to appear to be saying this Zeusti character is some sort of hero. Just though I should highlight what I see as a strange rejection of something that IS acceptable (re: the idata part).
And I haven't rejected the idata part.
In this case I'm not talking about a beginner stepping one step too long in their loops resulting in an ifinite loop.
But for a beginner of 8051, it is quite common/reasonable to use int all the time just because it represents the most efficient variable type on 99% of all processors in existence, and is the recommended/preferred data type in the C language.
So what I noted is that when using one of the most 16-bit unfriendly processors in existence (excluding 4-bit processors) loop constructs should when possible be written so that they do not need an int.
As you can see yourself, the loop in question could have been trivially rewritten in a way where an 8-bit variable had been ok. It doesn't matter if you know this. This thread will be read by a lot of people. It is still significant to remember the cost of 16-bit manipulation in the 8051 world.
In which case the size of the variable could be totally irrelevant! Maybe C51 has the ability to optimise this construct.
Optimization is irrelevant here. Using a 16-bit loop counter for a loop over idata exposes a fundamental misunderstanding about the '51 architecture.
No loop over idata can ever, possibly, need a 16-bit loop counter. There's always less than 256 bytes of available idata, so no loop has to run further than an 8-bit variable can reach.
"Using a 16-bit loop counter for a loop over idata exposes a fundamental misunderstanding about the '51 architecture."
Oh jeez, come on! Even the most experienced of programmers can sometimes come up with quick test functions using code templates that may include 16 bit counters. Haven't you ever done that? I know I have - And I consider myself to have more than just a fundamental understanding of the '51 architecture.
"No loop over idata can ever, possibly, need a 16-bit loop counter."
It may not be needed, but where in the rule book does it say you must not do it?
Might as well extend your comment and say 7-bit ASCII should never be stored in a 16 bit variable - Clearly ludicrous.
"It is still significant to remember the cost of 16-bit manipulation in the 8051 world."
Yes, I totally agree with that.
idata char aVariable; is an alternative, but it is only that, an alternative.
Say what? I repeat the is C you do not use unallocated memory. Especially a beginner. The compiler may use it. The stack could be there. You MAY get away with it in a 8052 but not a bigger CPU. If you are Grabbing a pointer to "Unused memory" you are not asking about it here.
Jumping out of a plane (with a chute) is alternative to waiting for it to land. It is not the same.
"I repeat the is C you do not use unallocated memory."
Eh???
If you are Grabbing a pointer to "Unused memory" you are not asking about it here.
As far as I can recall, I was not passing comment on the (lack of) allocation!
What I was trying to highlight was that a pointer to idata IS an alternative way of accessing the memory.
"Jumping out of a plane (with a chute) is alternative to waiting for it to land. It is not the same."
Ah - So you agree then?!