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!
the student commmments help me improve the exampel!
void clear_internal_idata_space ( void ) { char idata *Pointer_To_IDATA_Space = 0x80; unsigned char Counter; for ( Counter = 0x00; Counter <= 0x7F; ++Counter ) Pointer_To_IDATA_Space [ Counter ] = 0; }
but the idata is a real eamplel of how to see the memory.
Zeusti.
idata char aVariable; is all he needs
This is C you do not write to unallocated space.
data char aVariable; idata char aVariable; pdata char aVariable; xdata char aVariable;
Then use the variable normally.
char aVariable; This goes into the space chossen by the memory model you chose.
Aha, I see.
Look, "Professor", I really don't want to hurt your feelings but you need to, urgently:
* Open a C text book and read it (I know there are no pictures there like you are probably used to, but try it anyway). * Learn how a C51 works. * Stop this arrogance campaign which, frankly, makes you look less "professor" than you would like to admit. * Stop giving wrong and misleading advise to people that think you are some kind of big-shot which you are not. Anybody that has a minimum knowledge regarding programming (not necessarily embedded) can see that! Spare us.
Tamir is right!
Don't misguide!
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.