<?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>AT89S8253 Include</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/20142/at89s8253-include</link><description> 
I&amp;#39;m having to upgrade some sources from the obsolete AT89S8252 to
the 253. 

 
I&amp;#39;m having trouble though working out the inlude file to use in
the project. At first glance it seems to be the &amp;quot;REG8253.H&amp;quot; file
which states in its header that it is for</description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: AT89S8253 Include</title><link>https://community.arm.com/thread/123647?ContentTypeID=1</link><pubDate>Thu, 08 Feb 2007 08:29:11 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:feef8982-6f03-4053-b45f-c32500ffbd16</guid><dc:creator>Ed Deep</dc:creator><description>&lt;p&gt;&lt;p&gt;
From my recent wanderings of upgrading chips, I have found this
scenario you tell about frequently.&lt;/p&gt;

&lt;p&gt;
One should not go blind with these headers files at all. You must
comb these files and make them appropriate. Trust the manual.&lt;/p&gt;

&lt;p&gt;
Some musings:&lt;/p&gt;

&lt;p&gt;
First comes this habit of using snippets from many sources, so one
uses some header files from here and there and some have been
upgraded or modified and when you realize a small change somewhere in
the program will create several dozens of errors. (Using snippets is
euphemism for COPYWARE).&lt;/p&gt;

&lt;p&gt;
Second, there are some inconsistencies in the naming. Some people
like EA some type Ea or ea or whatever. Again, some dozen errors are
created.&lt;/p&gt;

&lt;p&gt;
And finally, some of the headers have been trimmed for some
examples and do not cover for all functions. I have several examples
of this with ATMEL. Some features are not going to be used, so they
are not in the file at all.&lt;br /&gt;
Sometimes a new feature is introduced and you have some old features
renamed as well.&lt;/p&gt;

&lt;p&gt;
This is just to say that you are not alone. This happens a
lot.&lt;/p&gt;

&lt;p&gt;
Ed&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: AT89S8253 Include</title><link>https://community.arm.com/thread/112642?ContentTypeID=1</link><pubDate>Wed, 07 Feb 2007 07:18:18 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:a9cd9bd3-429a-44f2-b2d4-6f895a008093</guid><dc:creator>erik  malund</dc:creator><description>&lt;p&gt;&lt;p&gt;
by simple reasoning it is obvious that the Keil REGxxx.h files can
not be &amp;#39;tested&amp;#39; by Keil, just visualize the effort for each and every
new chip (I have no doubt the files are &amp;#39;checked&amp;#39;). Thus it should
not be expected that they (especially new ones) will not have errors.
So, if a bug &lt;i&gt;could&lt;/i&gt; be due to an error in the REGxxx.h file it
is always prudent to check the SFR assignment against the datasheet.
This, of course is a non-problem for ICE users &amp;quot;why does a move to
SFRxxx not set it&amp;quot; but I would assume the Keil simulator uses the
same file.&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: AT89S8253 Include</title><link>https://community.arm.com/thread/98894?ContentTypeID=1</link><pubDate>Wed, 07 Feb 2007 05:03:23 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:a403721b-3ec4-49d7-812a-533d86a5a0bf</guid><dc:creator>David Lewis</dc:creator><description>&lt;p&gt;&lt;p&gt;
Never mind.&lt;/p&gt;

&lt;p&gt;
I&amp;#39;ve now found that Keil have produced a different version of the
REG8253.H files for download.&lt;/p&gt;

&lt;p&gt;
This one is correct, and removed the errors in the file supplied
with the compiler.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: AT89S8253 Include</title><link>https://community.arm.com/thread/74804?ContentTypeID=1</link><pubDate>Wed, 07 Feb 2007 04:58:57 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:53246999-7e5e-4ccf-a444-1a855fb87c1a</guid><dc:creator>David Lewis</dc:creator><description>&lt;p&gt;&lt;p&gt;
I was just trying to confirm (or deny) whether or not the supplied
Keil include files were correct.&lt;/p&gt;

&lt;p&gt;
My initial presumption was that Keil have supplied the correct
inlude file for the chip and that I&amp;#39;d missed something somewhere,
hence my post here.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: AT89S8253 Include</title><link>https://community.arm.com/thread/47758?ContentTypeID=1</link><pubDate>Wed, 07 Feb 2007 04:42:46 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:0f2d2b7a-0265-4784-8148-22d3248be994</guid><dc:creator>Andy Neil</dc:creator><description>&lt;p&gt;&lt;p&gt;
The &lt;b&gt;Datasheet&lt;/b&gt; is the definitive document (with due regard
to any &lt;i&gt;Errata&lt;/i&gt;).&lt;/p&gt;

&lt;p&gt;
There is nothing magic about the header files - if they don&amp;#39;t give
you what you need, modify them to suit, or write your own from
scratch.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>