<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://community.arm.com/utility/feedstylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>upper 128byte of 89S52</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/23821/upper-128byte-of-89s52</link><description> 
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</description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: upper 128byte of 89S52</title><link>https://community.arm.com/thread/154613?ContentTypeID=1</link><pubDate>Mon, 16 Mar 2009 00:49:15 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:82ae6c52-47ea-4470-9059-4e265da01804</guid><dc:creator>Trevor Morgan</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;&lt;b&gt;&amp;quot;I repeat the is C you do not use unallocated
memory.&amp;quot;&lt;/b&gt;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Eh???&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;&lt;b&gt;If you are Grabbing a pointer to &amp;quot;Unused memory&amp;quot; you are not
asking about it here.&lt;/b&gt;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Eh???&lt;/p&gt;

&lt;p&gt;
As far as I can recall, I was not passing comment on the (lack of)
allocation!&lt;/p&gt;

&lt;p&gt;
What I was trying to highlight was that a pointer to idata
&lt;b&gt;IS&lt;/b&gt; an alternative way of accessing the memory.&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;&lt;b&gt;&amp;quot;Jumping out of a plane (with a chute) is alternative to
waiting for it to land. It is not the same.&amp;quot;&lt;/b&gt;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Ah - So you agree then?!&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: upper 128byte of 89S52</title><link>https://community.arm.com/thread/154089?ContentTypeID=1</link><pubDate>Sun, 15 Mar 2009 20:00:18 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:606730bb-5358-4df7-8a5e-483963fb25bc</guid><dc:creator>Neil Kurzmam</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;b&gt;idata char aVariable;&lt;br /&gt;
is an alternative, but it is only that, an alternative.&lt;/b&gt;&lt;/p&gt;

&lt;p&gt;
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.&lt;br /&gt;
If you are Grabbing a pointer to &amp;quot;Unused memory&amp;quot; you are not asking
about it here.&lt;/p&gt;

&lt;p&gt;
Jumping out of a plane (with a chute) is alternative to waiting
for it to land. It is not the same.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: upper 128byte of 89S52</title><link>https://community.arm.com/thread/155720?ContentTypeID=1</link><pubDate>Sat, 14 Mar 2009 13:25:41 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:9c48ff1f-b98c-46b8-a32e-8de43496d149</guid><dc:creator>Trevor Morgan</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;&amp;quot;It is still significant to remember the cost of 16-bit
manipulation in the 8051 world.&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Yes, I totally agree with that.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: upper 128byte of 89S52</title><link>https://community.arm.com/thread/155426?ContentTypeID=1</link><pubDate>Sat, 14 Mar 2009 13:22:37 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:bdbbac2b-6cf3-40e9-a9e1-284a8966cf03</guid><dc:creator>Trevor Morgan</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;&amp;quot;Using a 16-bit loop counter for a loop over idata exposes a
fundamental misunderstanding about the &amp;#39;51 architecture.&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
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&amp;#39;t you ever done that? I know I
have - And I consider myself to have more than just a fundamental
understanding of the &amp;#39;51 architecture.&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;&amp;quot;No loop over idata can ever, possibly, need a 16-bit loop
counter.&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
It may not be needed, but where in the rule book does it say you
must not do it?&lt;/p&gt;

&lt;p&gt;
Might as well extend your comment and say 7-bit ASCII should never
be stored in a 16 bit variable - Clearly ludicrous.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: upper 128byte of 89S52</title><link>https://community.arm.com/thread/155061?ContentTypeID=1</link><pubDate>Sat, 14 Mar 2009 12:57:06 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:6e82afce-7807-4fc7-98ec-f3d60ce4e715</guid><dc:creator>HansBernhard Broeker</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;In which case the size of the variable could be totally
irrelevant! Maybe C51 has the ability to optimise this
construct.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Optimization is irrelevant here. Using a 16-bit loop counter for a
loop over idata exposes a fundamental misunderstanding about the &amp;#39;51
architecture.&lt;/p&gt;

&lt;p&gt;
&lt;b&gt;No&lt;/b&gt; loop over idata can ever, possibly, need a 16-bit loop
counter. There&amp;#39;s always less than 256 bytes of available idata, so no
loop has to run further than an 8-bit variable can reach.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: upper 128byte of 89S52</title><link>https://community.arm.com/thread/155428?ContentTypeID=1</link><pubDate>Sat, 14 Mar 2009 11:48:33 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:a254150d-71e7-4309-9d60-7b96c3e65c92</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
And I haven&amp;#39;t rejected the idata part.&lt;/p&gt;

&lt;p&gt;
In this case I&amp;#39;m not talking about a beginner stepping one step
too long in their loops resulting in an ifinite loop.&lt;/p&gt;

&lt;p&gt;
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.&lt;/p&gt;

&lt;p&gt;
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.&lt;/p&gt;

&lt;p&gt;
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&amp;#39;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.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: upper 128byte of 89S52</title><link>https://community.arm.com/thread/155060?ContentTypeID=1</link><pubDate>Sat, 14 Mar 2009 10:29:52 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:23971fe5-26b5-48ee-9f46-e8c815e6142a</guid><dc:creator>Trevor Morgan</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;&amp;quot;The problem here isn&amp;#39;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:...&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Sorry, but I simply don&amp;#39;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&amp;#39;t it?&lt;/p&gt;

&lt;p&gt;
Sure, he had the pointer and index badly initialised, but that
would not have affected the number of passes through the loop.&lt;/p&gt;

&lt;p&gt;
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.&lt;/p&gt;

&lt;p&gt;
Per, I really don&amp;#39;t mean to offend - And I REALLY don&amp;#39;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).&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: upper 128byte of 89S52</title><link>https://community.arm.com/thread/154615?ContentTypeID=1</link><pubDate>Sat, 14 Mar 2009 08:38:24 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:2e7d94d7-7888-4850-9b8a-eb12cc8e85f7</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
Yes, I am aware of optimizing compilers.&lt;/p&gt;

&lt;p&gt;
The problem here isn&amp;#39;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:&lt;/p&gt;

&lt;pre&gt;
uint8_t i;
for (i = 0; i &amp;lt; 256; i++) {
}
&lt;/pre&gt;

&lt;p&gt;
&lt;br /&gt;
or possibly:&lt;/p&gt;

&lt;pre&gt;
uint8-t i;
for (i = 0; i &amp;lt;= 255; i++) {
}
&lt;/pre&gt;

&lt;p&gt;
&lt;br /&gt;
The problem here wasn&amp;#39;t what a compiler may optimize but the issue
that the loop variable had to be 16-bit just so it wouldn&amp;#39;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.&lt;/p&gt;

&lt;p&gt;
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.&lt;/p&gt;

&lt;p&gt;
The big problem with &amp;quot;chief master programmer professor Zeusti&amp;quot; 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.&lt;/p&gt;

&lt;p&gt;
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 &amp;quot;professor&amp;quot;.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: upper 128byte of 89S52</title><link>https://community.arm.com/thread/154616?ContentTypeID=1</link><pubDate>Sat, 14 Mar 2009 07:54:18 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:8eff66f1-0634-487f-91dc-4f27089cdc07</guid><dc:creator>Trevor Morgan</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;&amp;quot;I particularly dislike his staunch arrogance and misguided
self esteem.&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
I would not like to comment on his arrogance or esteem; wouldn&amp;#39;t
like to throw stones in this glass house ;)&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;&amp;quot;... unusual code originates from poor understanding of
C.&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
In &lt;b&gt;this&lt;/b&gt; instance I don&amp;#39;t think it could be judged as
unusual. I &lt;b&gt;have&lt;/b&gt; used similar code to what he posted myself in
the past; and I believe that it was fully justifed.&lt;/p&gt;

&lt;p&gt;
And concerning one other comment that was made about his code:&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;&amp;quot;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?&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Hardly a cardinal sin! Of no relevance to idata!&lt;/p&gt;

&lt;p&gt;
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.&lt;/p&gt;

&lt;p&gt;
Maybe, one day, Zeusti will have a deeper understanding of C.&lt;/p&gt;

&lt;p&gt;
Maybe, one day, Zeusti will be capable of spelling Professor (or
even Zeusti?) consistently.&lt;/p&gt;

&lt;p&gt;
Maybe it&amp;#39;s best if I just avoid getting dragged into this any
more.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: upper 128byte of 89S52</title><link>https://community.arm.com/thread/154097?ContentTypeID=1</link><pubDate>Sat, 14 Mar 2009 07:05:39 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:3129ebe3-6afc-4d04-abee-0ce936a9e297</guid><dc:creator>Tamir Michael</dc:creator><description>&lt;p&gt;&lt;p&gt;
one more thing Trevor: our self proclaimed &amp;quot;professor&amp;quot; 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!&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: upper 128byte of 89S52</title><link>https://community.arm.com/thread/154096?ContentTypeID=1</link><pubDate>Sat, 14 Mar 2009 06:58:47 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:e66cafde-b9e4-462a-9e7c-18bb663ebac4</guid><dc:creator>Tamir Michael</dc:creator><description>&lt;p&gt;&lt;p&gt;
Trevor,&lt;br /&gt;
To my humble opinion the professor&amp;#39;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&amp;#39;t
think so.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: upper 128byte of 89S52</title><link>https://community.arm.com/thread/153503?ContentTypeID=1</link><pubDate>Sat, 14 Mar 2009 06:45:10 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:534d259e-c535-48d8-b1f0-b046a1b520c1</guid><dc:creator>Trevor Morgan</dc:creator><description>&lt;p&gt;&lt;p&gt;
You&amp;#39;ll probably think I&amp;#39;m a Zeusti affiliate for saying the
following, but here goes anyway.&lt;/p&gt;

&lt;p&gt;
The OP asked:&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;&amp;quot;How to use upper 128byte of AT89S52 in C51?&amp;quot;&lt;/i&gt;&lt;br /&gt;
&lt;i&gt;&amp;quot;one/two line example please.&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Zeusti gave:&lt;/p&gt;

&lt;pre&gt;
char idata *Pointer_To_IDATA_Space = 0x80;
&lt;/pre&gt;

&lt;p&gt;
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.&lt;/p&gt;

&lt;p&gt;
Contrary to some of the replies, I don&amp;#39;t see that as miguiding or
misleading!&lt;/p&gt;

&lt;p&gt;
Heck - Have you people have never seen a need to access the memory
in that manner (C or ASM)?&lt;/p&gt;

&lt;p&gt;
The valid example also given of:&lt;/p&gt;

&lt;pre&gt;
idata char aVariable;
&lt;/pre&gt;

&lt;p&gt;
is an alternative, but it is only that, an alternative.&lt;/p&gt;

&lt;p&gt;
In my view it is no more or less right. The suitability of each
would depend upon the particular requirement.&lt;/p&gt;

&lt;p&gt;
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.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: upper 128byte of 89S52</title><link>https://community.arm.com/thread/152815?ContentTypeID=1</link><pubDate>Thu, 12 Mar 2009 05:12:24 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:1415fbc4-abeb-4de0-817a-d38ff3e564c0</guid><dc:creator>erik  malund</dc:creator><description>&lt;p&gt;&lt;p&gt;
if looking for advice, ignore all posts from Zeusti&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: upper 128byte of 89S52</title><link>https://community.arm.com/thread/148076?ContentTypeID=1</link><pubDate>Wed, 11 Mar 2009 16:18:26 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:6318f6fa-ae12-4049-ab03-d4f7c5306d35</guid><dc:creator>James Scott</dc:creator><description>&lt;p&gt;&lt;p&gt;
Tamir is right!&lt;/p&gt;

&lt;p&gt;
Don&amp;#39;t misguide!&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: upper 128byte of 89S52</title><link>https://community.arm.com/thread/147488?ContentTypeID=1</link><pubDate>Wed, 11 Mar 2009 00:43:49 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:ce8930a5-eb65-4c1c-b811-edcb6eed4894</guid><dc:creator>Tamir Michael</dc:creator><description>&lt;p&gt;&lt;p&gt;
Look, &amp;quot;Professor&amp;quot;, I really don&amp;#39;t want to hurt your feelings but
you need to, urgently:&lt;/p&gt;

&lt;p&gt;
* 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).&lt;br /&gt;
* Learn how a C51 works.&lt;br /&gt;
* Stop this arrogance campaign which, frankly, makes you look less
&amp;quot;professor&amp;quot; than you would like to admit.&lt;br /&gt;
* 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.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: upper 128byte of 89S52</title><link>https://community.arm.com/thread/147487?ContentTypeID=1</link><pubDate>Wed, 11 Mar 2009 00:39:09 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:4f5e0acf-8328-480e-bf15-f35a397356e6</guid><dc:creator>Tamir Michael</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;the student commmments help me improve the exampel!&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Aha, I see.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: upper 128byte of 89S52</title><link>https://community.arm.com/thread/147489?ContentTypeID=1</link><pubDate>Tue, 10 Mar 2009 15:44:11 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:9c9c8843-898a-48f6-8e64-2733cbb7d76d</guid><dc:creator>Neil Kurzmam</dc:creator><description>&lt;p&gt;&lt;p&gt;
idata char aVariable; is all he needs&lt;/p&gt;

&lt;p&gt;
This is C you do not write to unallocated space.&lt;/p&gt;

&lt;p&gt;
data char aVariable;&lt;br /&gt;
idata char aVariable;&lt;br /&gt;
pdata char aVariable;&lt;br /&gt;
xdata char aVariable;&lt;/p&gt;

&lt;p&gt;
Then use the variable normally.&lt;/p&gt;

&lt;p&gt;
char aVariable;&lt;br /&gt;
This goes into the space chossen by the memory model you chose.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: upper 128byte of 89S52</title><link>https://community.arm.com/thread/146327?ContentTypeID=1</link><pubDate>Tue, 10 Mar 2009 00:54:28 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:864f16e8-c48a-418c-bf9d-7b00ddc72d6f</guid><dc:creator>Advanced Zeusti</dc:creator><description>&lt;p&gt;&lt;p&gt;
the student commmments help me improve the exampel!&lt;/p&gt;

&lt;pre&gt;
void clear_internal_idata_space ( void )
{
  char idata *Pointer_To_IDATA_Space = 0x80;
  unsigned char Counter;

  for ( Counter = 0x00; Counter &amp;lt;= 0x7F; ++Counter )
    Pointer_To_IDATA_Space [ Counter ] = 0;
}
&lt;/pre&gt;

&lt;p&gt;
but the idata is a real eamplel of how to see the memory.&lt;/p&gt;

&lt;p&gt;
Zeusti.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: upper 128byte of 89S52</title><link>https://community.arm.com/thread/144565?ContentTypeID=1</link><pubDate>Tue, 10 Mar 2009 00:48:06 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:dddd2660-0b43-4d08-be6e-c3a51a11253f</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
Interesting code there, professor.&lt;/p&gt;

&lt;p&gt;
So if the pointer gets initialized to 0x80, and you then use it as
an array with offset values of 0x80 to 0xff, exactly where will you
address the memory?&lt;/p&gt;

&lt;p&gt;
And another thing - 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?&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: upper 128byte of 89S52</title><link>https://community.arm.com/thread/144566?ContentTypeID=1</link><pubDate>Tue, 10 Mar 2009 00:20:47 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:05d47624-3c50-4565-bd88-4e81c081d42d</guid><dc:creator>Advanced Zeusti</dc:creator><description>&lt;p&gt;&lt;p&gt;
nooooooooooo............&lt;/p&gt;

&lt;p&gt;
the line you want is this ...........&lt;/p&gt;

&lt;pre&gt;

  char idata *Pointer_To_IDATA_Space = 0x80;

&lt;/pre&gt;

&lt;p&gt;
Zeusti.&lt;/p&gt;

&lt;p&gt;
the one who does.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: upper 128byte of 89S52</title><link>https://community.arm.com/thread/142233?ContentTypeID=1</link><pubDate>Mon, 09 Mar 2009 23:55:55 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:46344462-b16a-4629-a1b9-6abaee665482</guid><dc:creator>Advanced Zeusti</dc:creator><description>&lt;p&gt;&lt;p&gt;
Yes, for you, here is a real exampel. not Please read the manual.&lt;/p&gt;

&lt;pre&gt;
void clear_internal_idata_space ( void )
{
  char idata *Pointer_To_IDATA_Space - 0x80;
  int Counter;

  for ( Counter = 0x80; Counter &amp;lt;= 0xFF; ++Counter )
    Pointer_To_IDATA_Space [ Counter ] = 0;
}
&lt;/pre&gt;

&lt;p&gt;
Professor Zeusti.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: upper 128byte of 89S52</title><link>https://community.arm.com/thread/139074?ContentTypeID=1</link><pubDate>Mon, 09 Mar 2009 15:00:27 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:fabbedfc-2aa1-41b6-8244-ca9ca8634058</guid><dc:creator>erik  malund</dc:creator><description>&lt;p&gt;&lt;p&gt;
IDATA&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: upper 128byte of 89S52</title><link>https://community.arm.com/thread/130442?ContentTypeID=1</link><pubDate>Mon, 09 Mar 2009 14:55:43 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:91638e02-5e14-40ad-acba-f1a8fd831db2</guid><dc:creator>James Scott</dc:creator><description>&lt;p&gt;&lt;p&gt;
How to use upper 128byte of AT89S52 in C51?&lt;br /&gt;
please help me.&lt;br /&gt;
one/two line example please.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: upper 128byte of 89S52</title><link>https://community.arm.com/thread/125286?ContentTypeID=1</link><pubDate>Mon, 09 Mar 2009 14:37:30 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:04e7b5bf-f28b-4ef1-a67f-dba97bafd575</guid><dc:creator>erik  malund</dc:creator><description>&lt;p&gt;&lt;p&gt;
in C if your variable is in XDATA, DPTR is used, no concern of
yours.&lt;/p&gt;

&lt;p&gt;
Erik&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: upper 128byte of 89S52</title><link>https://community.arm.com/thread/114749?ContentTypeID=1</link><pubDate>Mon, 09 Mar 2009 14:20:43 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:60583e0a-4307-49f2-b0f0-1d231ee505be</guid><dc:creator>James Scott</dc:creator><description>&lt;p&gt;&lt;p&gt;
I know how to do it in assembly.&lt;br /&gt;
But in C51 i miss this easy DPTR things.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>