<?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>8051 ROM mask with different flash application</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/24915/8051-rom-mask-with-different-flash-application</link><description> 
We are planning to build a ROM mask + flash environment. That is
the lower 32K code space will be mapping to ROM-mask and the upper
32K to flash. The lower 32K will check a function table in the upper
32k (flash). 
We we put drivers and basic APIs in</description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: 8051 ROM mask with different flash application</title><link>https://community.arm.com/thread/103636?ContentTypeID=1</link><pubDate>Tue, 24 Nov 2009 07:23:59 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:498d2c38-cc1a-4458-9fdb-a0a562b5c143</guid><dc:creator>&amp;#178;erik malund</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;I have tried to group code into ROM and APP userclass. But the
generated binary seems to be different due to different
call-tree.&lt;/i&gt;&lt;br /&gt;
that&amp;#39;s the crux, a piece of separate code can not share the call tree
with some &amp;#39;unknown code&amp;#39;&lt;/p&gt;

&lt;p&gt;
the only way I can see is to modify startup.a51 for the code in
high mem not to clear whatever RAM the low code uses and then set the
high code to have &lt;b&gt;uninitialized&lt;/b&gt; RAM storage in the areas that
the low code uses. This is easily accomplished with a small assembler
module.&lt;/p&gt;

&lt;p&gt;
Another problem with your scheme is that, unless you (are ignorant
enough to) believe that the low code will never change is that the
communication will have to be by indirect pointer call which is not
the most efficient use of a &amp;#39;51.&lt;/p&gt;

&lt;p&gt;
RE low power: TI has some VERY frugal &amp;#39;51 derivatives and so does
SILabs (e.g. the &amp;#39;9&amp;#39; series)&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: 8051 ROM mask with different flash application</title><link>https://community.arm.com/thread/103633?ContentTypeID=1</link><pubDate>Tue, 24 Nov 2009 06:52:00 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:06c025ac-822c-4604-9e48-5d5399c48005</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
For high-temperature solutions, ROM is still king. Flash memory
retention times drops drastically with high temperature.&lt;/p&gt;

&lt;p&gt;
If all you need is low power consumption, then it would probably
be easier to just look for a different processor. There are a lot of
processors that will run very efficiently from a small button
cell.&lt;/p&gt;

&lt;p&gt;
I&amp;#39;m normally using the Keil ARM tools, so you will have to look
for help by someone else about how to set up a project. Just note
that the linker must know that the fixed part is really fixed. If you
just add the common code to the individual projects and compile, then
the linker will assume that it may perform optimizations etc for all
parts of the code. It is important that the linker knows that the
32kB are locked and that all it has access to is the call addresses.
I think this was last discussed in a C51 thread within the last
couple of weeks.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: 8051 ROM mask with different flash application</title><link>https://community.arm.com/thread/77942?ContentTypeID=1</link><pubDate>Tue, 24 Nov 2009 06:43:57 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:c7ff17d2-c2c3-4719-8bd2-eb4e40675a63</guid><dc:creator>demarco chou</dc:creator><description>&lt;p&gt;&lt;p&gt;
Westermark,&lt;br /&gt;
Thanks for your suggestion and please ignore my last sentence in the
starting post.&lt;/p&gt;

&lt;p&gt;
In my case, we need to have our code running fast and low power
consumption. ROM beats flash in these aspects. Updating ROM will be
achieved by ECO.&lt;br /&gt;
But we still want to expand the capability of our firmware in the
future. That&amp;#39;s why we are planning such a complicated design.&lt;/p&gt;

&lt;p&gt;
8000-FFFF [APP1] [APP2] [...]&lt;br /&gt;
-------------------------------------&lt;br /&gt;
0000-7FFF [ROM]&lt;/p&gt;

&lt;p&gt;
I am just wondering that is it possible to have 2 projects that
share the same &amp;#39;ROM&amp;#39; source code to have the same lower 32K
binary???&lt;/p&gt;

&lt;p&gt;
I have tried to group code into ROM and APP userclass. But the
generated binary seems to be different due to different
call-tree.&lt;br /&gt;
Any suggestion??&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: 8051 ROM mask with different flash application</title><link>https://community.arm.com/thread/90135?ContentTypeID=1</link><pubDate>Tue, 24 Nov 2009 06:14:21 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:5852d851-2855-47d6-a908-5d978687594e</guid><dc:creator>&amp;#178;erik malund</dc:creator><description>&lt;p&gt;&lt;p&gt;
we see this one on a fairly regular basis (invisible fixed code
similar to an OS)&lt;/p&gt;

&lt;p&gt;
my wild guess is that those that propose such a solution are
trying to &amp;quot;sell software by the piece&amp;quot;&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: 8051 ROM mask with different flash application</title><link>https://community.arm.com/thread/57309?ContentTypeID=1</link><pubDate>Tue, 24 Nov 2009 03:27:57 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:cbcacbc7-2b1a-4e4e-a3e4-4513465e4c2c</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
Why? You think you will save money by having a mask-programmed
chip? The huge cost of having errors in mask-programmed devices has
moved almost all users to pure flash solutions, in which case the
availability of mask-programmable devices quite small.&lt;/p&gt;

&lt;p&gt;
Another thing - your text sometimes suggests that it is the upper
half that is mask-programmable, and sometimes that it is the lower
half.&lt;/p&gt;

&lt;p&gt;
An important factor to consider is if your design is fulfilling
KISS principle (Keep It Simple, Stupid) - if it doesn&amp;#39;t, then you
should think twice or trice before continuing. Complicating things
tends to affect cost and quality.&lt;/p&gt;

&lt;p&gt;
&lt;a href="http://en.wikipedia.org/wiki/KISS_principle"&gt;en.wikipedia.org/.../KISS_principle&lt;/a&gt;&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>