<?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>Dual data pointer registers problem</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/37188/dual-data-pointer-registers-problem</link><description> 
Hi there, 

 
I run the codes below in uVision3 V3.30 in order to 
see the effect of AUXR1 register in switching DPTR0 and DPTR1. I
choose the device as AT89S51 which provides the dual DPTR function.
But when I run the codes step by step in uVision</description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: Dual data pointer registers problem</title><link>https://community.arm.com/thread/153929?ContentTypeID=1</link><pubDate>Tue, 13 Mar 2007 08:33:09 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:57685a7a-05f2-4148-a490-6f84f66af083</guid><dc:creator>erik  malund</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;What I don&amp;#39;t agree in Erik statements is that one should be
&amp;#39;grateful&amp;#39; for the toolset functionality, and simply ignore the
bugs.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
TOTALLY MISQUOTED&lt;/p&gt;

&lt;p&gt;
I stated something like &amp;quot;&lt;b&gt;bugs should always be fixed&lt;/b&gt;,
features are up to the provider&amp;quot;.&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;I can appreciate your point, but I think you are missing one
thing here that I want to make clearer: Nobody is demanding full
simulation for every of the many 8051 derivatives on the
market.&lt;/i&gt;&lt;br /&gt;
Then why are you &amp;quot;demanding full simulation for&amp;quot; this particular
derivative?&lt;/p&gt;

&lt;p&gt;
re the posts about &amp;quot;the importance of simulation&amp;quot;; It may be that
some work well by such a method and good luck with that. I never
would, simply because of the issues I have seen that no simulation
could ever &amp;#39;predict&amp;#39;. I can see simulation as a possible useful tool
for computing dominant projects, but for an I/O dominant project, I
stand by my position that simulation is worthless or, at best, not
very useful.&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: Dual data pointer registers problem</title><link>https://community.arm.com/thread/153295?ContentTypeID=1</link><pubDate>Mon, 12 Mar 2007 21:47:36 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:a8f8a19f-767b-4af9-8e71-ee3af92310c5</guid><dc:creator>Jonny Doin</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;b&gt;Per Westermark&lt;/b&gt; said: &lt;i&gt;&amp;quot;The availability of a simulator is
often a deciding factor when choosing which compiler suite to buy for
a project, since it can allow the majority of time after reception of
a hw prototype to be spent validating the hardware, instead of first
having to decide what is hardware and what is software
errors.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;A simulator can also alow testing of some worst-case scenarios
that may be _very_ hard to generate on a real hardware platform.&lt;br /&gt;
&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
To which I fully agree. The Keil simulator, for example, has some
really powerful and nice features. You simply cannot duplicate the
functionality of the signal functions provided by the simulator
environment to generate signals and complex hardware responses.&lt;br /&gt;
To test failsafe interface code, you often must simulate behaviour
that is very difficult to obtain from real hardware, but is easily
achievable from a signal function, or a testbench.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Dual data pointer registers problem</title><link>https://community.arm.com/thread/152615?ContentTypeID=1</link><pubDate>Mon, 12 Mar 2007 21:38:47 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:4dc41a3b-a66b-43b2-bcf5-ba5c742a719a</guid><dc:creator>Jonny Doin</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;b&gt;Erik Malund&lt;/b&gt; said: &lt;i&gt;I know no &amp;quot;skilled and experienced
engineer&amp;quot; that use a simulator. All &amp;quot;skilled and experienced
engineers&amp;quot; I know use an emulator.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
An emulator is a nice tool. We have a few emulators stuck in
obscure corners of the engineering dept. steel storage cabinets. One
for each family of CPU used sometime in the past. Actually, an
emulator was a required tool back then, because you really could not
test firmware, place breakpoints and analyze trace buffers without
one. The software debuggers sucked big time, especially for
cross-development. The good and extremelly expensive emulators were
usually coupled with a sizable logic analyser (a real one), that
helped you to deglitch your board. The good stuff was based on unix
workstations, of course, not those feeble PCs.&lt;/p&gt;

&lt;p&gt;
Then, some five moore&amp;#39;s cycles later, there came available massive
computing power at every desk. I have in my develop PC today VHDL
simulators that run in a few minutes RTL files that would take 5
hours to run in a HP workstation a few years ago. Linear Tech&amp;#39;s SPICE
engine runs a dozen times faster than the first UCB SPICE I used in a
SUN workstation, and the core code is very similar. That allows me to
fully characterize complex ADC and SMPS circuits in one week, before
the hardware is even laid-out. The result is that usually I make just
one PCB iteration for these designs now, and the prototype actually
works pretty much exactly the same as the SPICE models.&lt;/p&gt;

&lt;p&gt;
The same applies to firmware simulation. I have in my machine
simulators that run full-blown instrumented firmware simulations
faster than realtime. A well-planned firmware deployment MUST account
for a well-designed simulation environment. There are many situations
in which an emulator or on-chip debugger cannot substitute for a good
simulator. When hunting for hard bugs, a simulator is more productive
than an emulator, because you have a more controlled environment.
Especially in hard-realtime systems, where the on-chip debug
resources may interfere with the system computing load.&lt;/p&gt;

&lt;p&gt;
In other words, simulation is &lt;b&gt;ESSENTIAL&lt;/b&gt; to a professional
design flow. So much so that virtually every EDA tool vendor throws
real money in development of good simulation tools. For example, for
some high-reliability contracts, you must provide proof of
verification for your entire software, by means of testbench
simulation vectors and results for every function in your software,
something really expensive to do if you use a hardware emulator.&lt;/p&gt;

&lt;p&gt;
I am not dismissing the importance of on-chip debugging and
integrated trace hardware on the current CPUs. The embedded trace
macrocell in the ARM cores do really facilitate system-level
verification. But even then, the simulator is essential on the
workflow.&lt;/p&gt;

&lt;p&gt;
I see it as a much neglected part of the design flow, almost as
neglected as comprehensive firmware testing methods and
verification.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Dual data pointer registers problem</title><link>https://community.arm.com/thread/152614?ContentTypeID=1</link><pubDate>Mon, 12 Mar 2007 20:55:12 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:b6e0ef89-c899-4e5b-9842-dfa78bdf6f3c</guid><dc:creator>Jonny Doin</dc:creator><description>&lt;p&gt;&lt;p&gt;
Wow. It&amp;#39;s just amazing how a thread can develop during your drive
home from work.&lt;/p&gt;

&lt;p&gt;
This thread has been hopelessly hijacked, and as usual became a
much more interesting thread :)&lt;/p&gt;

&lt;p&gt;
&lt;b&gt;Erik Malund&lt;/b&gt; said: &lt;i&gt;&amp;quot;There are about 4711 &amp;quot;given
derivatives&amp;quot; with about 47111 &amp;#39;unique features&amp;#39; and to support them
all is not feasible with the size of the &amp;#39;51 market. &amp;quot;&lt;/i&gt;&lt;br /&gt;
I can appreciate your point, but I think you are missing one thing
here that I want to make clearer: Nobody is demanding full simulation
for every of the many 8051 derivatives on the market. That has never
been said in this thread. My whole point is that, &lt;b&gt;&lt;i&gt;If you decide
to&lt;/i&gt;&lt;/b&gt; provide simulation support for a chip feature, then you
must do it faithfully. There are many chips that are not fully
simulated, with several peripheral subsystems that are simply not
simulated. That&amp;#39;s not so big a problem, and is normally noted in the
model implementation notes. HOWEVER, if a feature is implemented,
then it must be implemented right, or else you just can&amp;#39;t rely on the
tool you are using. That is a &lt;b&gt;bug&lt;/b&gt;. And this is ok also,
because every software or firmware has bugs. Hopefully, the vendor
will come up with a future software release that fixes the bug.&lt;/p&gt;

&lt;p&gt;
What I don&amp;#39;t agree in Erik statements is that one should be
&amp;#39;grateful&amp;#39; for the toolset functionality, and simply ignore the bugs.
The companies I worked for have spent tens of thousands of dollars on
Keil tools every few years to purchase development tools that were
believed solid and dependable. Surely we have not counted on Keil&amp;#39;s
benevolence or goodwill, but on their craftsmanship and keenness. We
must depend on their products to make our products to ship with less
bugs.&lt;/p&gt;

&lt;p&gt;
But there is an inversion of values here: we do not expect to have
rights on a perfect product because we have paid for it. On the
contrary, we decide to buy it because we have evaluated it, and
decided that despite the few bugs, it is worthy. Product excellence
comes before the purchase decision. And that is all about it: should
it be discovered later that it is an empty promise, and a better
alternative available, customers would not buy it for the next system
development. On that perspective, I would definitely question the
decision to purchase a toolset that has a very poor quality for the
evaluation and educational versions.&lt;/p&gt;

&lt;p&gt;
As a matter of fact, that is not what happens to Keil tools. They
have their idiosyncrasies, a few nasty bugs, sometimes questionable
optimizer code, but that is just the drill on every dev toolset that
will ever be. Fact is that we have been using Keil tools for quite a
long time, and have been able to ship quite large firmware written
with it.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Dual data pointer registers problem</title><link>https://community.arm.com/thread/151837?ContentTypeID=1</link><pubDate>Mon, 12 Mar 2007 16:30:11 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:d2177e4f-d648-4c5f-8ccb-0af751eb44ca</guid><dc:creator>Per Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;a) this thread started &amp;quot;the simulator does not simulate a
&amp;quot;completely different chip&amp;quot; so, that argument is lost on me.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
My arguments about the advantages of a simulator directly follows
your comment:&lt;br /&gt;
- I know no &amp;quot;skilled and experienced engineer&amp;quot; that use a
simulator.&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;b) &amp;quot;doesn&amp;#39;t have fast enough boot time&amp;quot; boot time in
embedded????&lt;/i&gt;&lt;br /&gt;
Don&amp;#39;t restrict your thinking of boot time as the time a PC needs
until you get a login prompt.&lt;/p&gt;

&lt;p&gt;
For embedded systems, it can quite often come down to the time it
takes for a crystal or PLL to stabilize.&lt;/p&gt;

&lt;p&gt;
This is an important factor if you run your embedded equipment on
_small_ batteries and saves power by turning off the main oscillator,
and only keeping an RTC running asynchronously at a few uA. Or you
might drive the equipment from a phone line, allowing an average
consumption of 15uA until it&amp;#39;s time to pick up the line.&lt;/p&gt;

&lt;p&gt;
If the processor needs 10k or 100k clock cycles until the main
oscillator is stable and the processor may handle any real work, a
significant part of the power consumption can be spent just waiting
for the oscillator startup. Or the chip may loose a lot of data.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Dual data pointer registers problem</title><link>https://community.arm.com/thread/151090?ContentTypeID=1</link><pubDate>Mon, 12 Mar 2007 14:55:41 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:20be3039-f5ba-4062-962b-bc0df4d6bf61</guid><dc:creator>erik  malund</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;If the units are expected to be produced in 1k or 10k/year or
more, then every single project has a high tendancy to use completely
different chips than the earlier projects. Either because a new, more
cost-effective chip has been released, the previously used chips are
a number of pins too large or too small, doesn&amp;#39;t have fast enough
boot time, low enough MIPS/mA, misses a critical
peripherical,&lt;/i&gt;&lt;br /&gt;
two things&lt;br /&gt;
a) this thread started &amp;quot;the simulator does not simulate a &amp;quot;completely
different chip&amp;quot; so, that argument is lost on me.&lt;br /&gt;
b) &amp;quot;doesn&amp;#39;t have fast enough boot time&amp;quot; &lt;b&gt;boot time&lt;/b&gt; in
embedded????&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: Dual data pointer registers problem</title><link>https://community.arm.com/thread/146050?ContentTypeID=1</link><pubDate>Mon, 12 Mar 2007 14:22:33 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:9821511e-b954-497c-9f13-60916eea0762</guid><dc:creator>Per Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;I have hardware designed 3 designs ahead of what I am doing
software for. That way the hardware is there when software time
comes.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
That implies that you are either doing quite small projects, or
that your customers don&amp;#39;t have too strict requirements about lead
times.&lt;/p&gt;

&lt;p&gt;
If the average software is 5k - 20k lines of code, then the
development must be started as soon as the major design issues have
been resolved.&lt;/p&gt;

&lt;p&gt;
If the units are expected to be produced in 1k or 10k/year or
more, then every single project has a high tendancy to use completely
different chips than the earlier projects. Either because a new, more
cost-effective chip has been released, the previously used chips are
a number of pins too large or too small, doesn&amp;#39;t have fast enough
boot time, low enough MIPS/mA, misses a critical peripherical,
...&lt;/p&gt;

&lt;p&gt;
Since the majority of the development will use chips I haven&amp;#39;t
worked with before, it isn&amp;#39;t too good to rely on a &amp;quot;write now and
test later&amp;quot; strategy. When the hardware arrives, the majority of the
software really has to work, since there will not be much time
available to validate the hw before deciding what hw changes should
be made before shipping it to notified bodies for certifications.&lt;/p&gt;

&lt;p&gt;
A software developer must not run around with a &amp;quot;hammer&amp;quot; thinking
everything is a &amp;quot;nail&amp;quot;. An emulator is good to have, but it is only
one of a number of required/needed/appreciated tools. Some problems
are best solved with a simulator. Some with a high-end digital scope
or logic analyzer. Some with an emulator. Some by running partial
builds on a PC, or on similar hardware. Some by just looking at the
code and think for a while.&lt;/p&gt;

&lt;p&gt;
One of the real strengths with a good simulator, is the ability to
perform nightly regression tests, to quickly notice if any part of
the software have suddenly started to behave differently than before.
The regression testing requires a known test pattern, or it will be
very hard to try to look at the test results.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Dual data pointer registers problem</title><link>https://community.arm.com/thread/144198?ContentTypeID=1</link><pubDate>Mon, 12 Mar 2007 12:54:26 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:9c7a1016-4a50-45ba-9e37-9dde25945183</guid><dc:creator>erik  malund</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;So you say that all &amp;quot;skilled and experienced engineers&amp;quot; sit on
their hands until they have any hardware to use with their
emulator?&lt;/i&gt;&lt;br /&gt;
1) all &amp;quot;skilled and experienced engineers&amp;quot; &lt;b&gt;I know&lt;/b&gt;&lt;br /&gt;
2) I have hardware designed 3 designs ahead of what I am doing
software for. That way the hardware is there when software time
comes.&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;If I start developing software for a product at the same time
as the hardware is being designed, I just have to settle for the
simulator - or spend time trying to create a mock-up.&lt;/i&gt;&lt;br /&gt;
You need nothing to &lt;b&gt;write&lt;/b&gt; software, only to test it.&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;If the external hardware is highly complicated, relying on high
frequencies, making use of bga chpis (for which I don&amp;#39;t have any
solder equipment), or requires sample components that may have a
significant lead time - it may not be feasible to try to hand-build
something to test on, so the software will not be possible to run in
real hardware until the first prototype has been designed, built and
delivered.&lt;/i&gt;&lt;br /&gt;
I would not do that for &amp;quot;hardware is highly complicated, relying on
high frequencies&amp;quot; a &amp;quot;hand-build something to test on&amp;quot; will not be
worth much. It will be too different re radiation etc.&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;instead of first having to decide what is hardware and what is
software errors.&lt;/i&gt;&lt;br /&gt;
I know no better tool for &amp;#39;deciding&amp;#39; that than an emulator.&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;A simulator can also alow testing of some worst-case scenarios
that may be _very_ hard to generate on a real hardware
platform.&lt;/i&gt;&lt;br /&gt;
You can test &amp;quot;worst case values&amp;quot; with a simulator, that, however
rarely is the issue. Timing conflicts (which no simulator can
simulate) is much more of a concern.&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: Dual data pointer registers problem</title><link>https://community.arm.com/thread/141739?ContentTypeID=1</link><pubDate>Mon, 12 Mar 2007 12:16:06 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:8338552a-6e20-4ee5-89ae-315ef73331b4</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
So you say that all &amp;quot;skilled and experienced engineers&amp;quot; sit on
their hands until they have any hardware to use with their
emulator?&lt;/p&gt;

&lt;p&gt;
If I start developing software for a product at the same time as
the hardware is being designed, I just have to settle for the
simulator - or spend time trying to create a mock-up.&lt;/p&gt;

&lt;p&gt;
If the external hardware is highly complicated, relying on high
frequencies, making use of bga chpis (for which I don&amp;#39;t have any
solder equipment), or requires sample components that may have a
significant lead time - it may not be feasible to try to hand-build
something to test on, so the software will not be possible to run in
real hardware until the first prototype has been designed, built and
delivered.&lt;/p&gt;

&lt;p&gt;
The availability of a simulator is often a deciding factor when
choosing which compiler suite to buy for a project, since it can
allow the majority of time after reception of a hw prototype to be
spent validating the hardware, instead of first having to decide what
is hardware and what is software errors.&lt;/p&gt;

&lt;p&gt;
A simulator can also alow testing of some worst-case scenarios
that may be _very_ hard to generate on a real hardware platform.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Dual data pointer registers problem</title><link>https://community.arm.com/thread/138394?ContentTypeID=1</link><pubDate>Mon, 12 Mar 2007 11:59:18 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:af9ac2eb-58e1-48b5-b479-a14d26e5d1fb</guid><dc:creator>erik  malund</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;If you have to rely only on the standard core functionality,
then the simulator is worthless. If a given functionality is being
offered in a given derivative, it ough to be correctly implemented,
else it is an implementation bug.&lt;/i&gt;&lt;br /&gt;
as I posted earlier &amp;quot;to implement every &amp;#39;feature&amp;#39; of every
derivative, would be so expensive that Keil would have to price
themselves out of the market&amp;quot;.&lt;br /&gt;
There are about 4711 &amp;quot;given derivatives&amp;quot; with about 47111 &amp;#39;unique
features&amp;#39; and to support them all is not feasible with the size of
the &amp;#39;51 market. We can argue till the cows come home about how far
&amp;quot;as much as economically reasonable&amp;quot; can/should go, that decision
must reside with Mr. Keil.&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;&amp;quot;So, if you use a licenced version of the software, send a
request to Keil, if not, be grateful for what you get for free &amp;quot;Do
not look a gifted horse in the mouth&amp;quot;&amp;quot;&lt;br /&gt;
Now, that&amp;#39;s really where we differ.&lt;/i&gt;&lt;br /&gt;
Do we?, what I point out is &amp;quot;if you pay you can request&amp;quot;, if you do
not, you can only ask.&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;It often takes a skilled and experienced engineer to detect
subtle simulator flaws.&lt;/i&gt;&lt;br /&gt;
I would not know about that. I know no &amp;quot;skilled and experienced
engineer&amp;quot; that use a simulator. All &amp;quot;skilled and experienced
engineers&amp;quot; I know use an emulator.&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;Whether or not you are using the limited evaluation version or
the full suite, this should not affect the quality of the implemented
features.&lt;/i&gt;&lt;br /&gt;
agree, re &lt;b&gt;quality&lt;/b&gt; not agreed re scope. That a &amp;#39;special
feature&amp;#39; is not supported is not a matter of quality, it is a matter
of scope. What you are, in effect, saying is that if MS word does not
have a spell-checker for Swahili, it is not a quality product.&lt;/p&gt;

&lt;p&gt;
Erik&lt;/p&gt;

&lt;p&gt;
The worst part of this is that there is an undertone here that
states &amp;quot;so what if those that pay will have to pay more&amp;quot; I want my
free version to be as I want it.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Dual data pointer registers problem</title><link>https://community.arm.com/thread/134951?ContentTypeID=1</link><pubDate>Mon, 12 Mar 2007 11:30:16 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:e20318b8-19ec-4d1a-a909-fb4cfdb4cb71</guid><dc:creator>Jonny Doin</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;&amp;quot;the 8252, based on what I have seen in posts here and
elsewhere is &amp;quot;a popular chip&amp;quot; &lt;b&gt;among amateurs&lt;/b&gt;.&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Your point being, what? Do you really think that defects in a
toolset should only be classified as bugs if they affect the high-end
users?&lt;/p&gt;

&lt;p&gt;
&amp;quot;A popular chip&amp;quot; means that it is a target chip for which the
toolchain is used by many.&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;&amp;quot;...just about as many variants as there are derivatives that
have it.&amp;quot;&lt;/i&gt;&lt;br /&gt;
That&amp;#39;s irrelevant. If you have to rely only on the standard core
functionality, then the simulator is worthless. If a given
functionality is being offered in a given derivative, it ough to be
correctly implemented, else it is an implementation bug.&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;&amp;quot;So, if you use a licenced version of the software, send a
request to Keil, if not, be grateful for what you get for free &amp;quot;Do
not look a gifted horse in the mouth&amp;quot;&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Now, that&amp;#39;s really where we differ. It often takes a skilled and
experienced engineer to detect subtle simulator flaws. Much more
common is the user to try to find the bugs in the simulated code
rather than write test suites to validate the development tools.
Whether or not you are using the limited evaluation version or the
full suite, this should not affect the quality of the implemented
features.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Dual data pointer registers problem</title><link>https://community.arm.com/thread/123703?ContentTypeID=1</link><pubDate>Mon, 12 Mar 2007 09:42:38 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:97cd58bc-7cfd-4fdb-8c35-000d6212dbf6</guid><dc:creator>erik  malund</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;But that is not what happens in the case at hand. Having
simulation support for a chip feature requires the feature to be
fully modelled. The dual DPTR support is not a obscure aspect of the
core behavior, it is a much used trivial feature. Although it is not
&amp;#39;standard&amp;#39; for the original 8051core, it is provided by many
derivatives. Besides, the AT89S8252 is a popular chip from a
mainstream vendor.&lt;/i&gt;&lt;br /&gt;
the 8252, based on what I have seen in posts here and elsewhere is &amp;quot;a
popular chip&amp;quot; among amateurs.&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;it is provided by many derivatives.&lt;/i&gt; in just about as many
variants as there are derivatives that have it. Some are a sfr bit,
that can be toggled by &amp;#39;inc&amp;#39;, some are a SFR bit that can be bit
addressed, some are a SFR bt that can not be bit addressed, not to
mention that that the actual bit usually is a different one.&lt;/p&gt;

&lt;p&gt;
So, if you use a licenced version of the software, send a request
to Keil, if not, be grateful for what you get for free &amp;quot;Do not look a
gifted horse in the mouth&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: Dual data pointer registers problem</title><link>https://community.arm.com/thread/112724?ContentTypeID=1</link><pubDate>Sun, 11 Mar 2007 13:13:29 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:e9920bcf-e35b-4c8d-8998-af901b37009b</guid><dc:creator>Jonny Doin</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;I would not classify this as a &amp;#39;bug&amp;#39;, I would classify it as
&amp;quot;expecting more than what is reasonable&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
I do agree that lack of simulation support for a particular chip
feature cannot be classified as a simulator bug, but maybe as a
limitation on the simulation capabilities for that particular
target.&lt;/p&gt;

&lt;p&gt;
But that is not what happens in the case at hand. Having
simulation support for a chip feature requires the feature to be
fully modelled. The dual DPTR support is not a obscure aspect of the
core behavior, it is a much used trivial feature. Although it is not
&amp;#39;standard&amp;#39; for the original 8051core, it is provided by many
derivatives. Besides, the AT89S8252 is a popular chip from a
mainstream vendor.&lt;/p&gt;

&lt;p&gt;
In this particular case, it very much can be classified as a bug
in the implementation of the simulator, on the basis that a simulated
feature does not duplicate the real hardware behavior.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Dual data pointer registers problem</title><link>https://community.arm.com/thread/112725?ContentTypeID=1</link><pubDate>Thu, 08 Mar 2007 08:20:27 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:5a109ba9-3d6e-45a7-a4d1-dc55c96816c7</guid><dc:creator>erik  malund</dc:creator><description>&lt;p&gt;&lt;p&gt;
the above could, of course, be reported as a request but still is
not a &amp;#39;bug&amp;#39;.&lt;/p&gt;

&lt;p&gt;
I have no doubt Keil would consider such a request, whether they
would allocate the resources to fully support the particular
derivative you use, is another story. Here, of course, also is the
factor that, if Keil act as a business, a request for improvement
from a licenced user would, more likely, be considered than a request
from a freeloading eval user.&lt;/p&gt;

&lt;p&gt;
Since I consider Keil a honorable company, I would assume that if
the reported was a REAL bug (not support of the pecularities of a
particular derivative) it would not matter what the source of the
information was.&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: Dual data pointer registers problem</title><link>https://community.arm.com/thread/99008?ContentTypeID=1</link><pubDate>Thu, 08 Mar 2007 07:23:46 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:21fdeec8-a3b2-43ca-8d64-bb86f7a868ad</guid><dc:creator>erik  malund</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;So I guess that might be the bug in uVision simulator&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
I would not classify this as a &amp;#39;bug&amp;#39;, I would classify it as
&amp;quot;expecting more than what is reasonable&amp;quot;&lt;/p&gt;

&lt;p&gt;
Expecting Keil - or any other simulator maker - to adapt to every
intricacy of all of the 4711 derivatives out there is the same as
expecting tools nobody can afford.&lt;/p&gt;

&lt;p&gt;
I know that in the mind of most the issue is &amp;quot;why does keil not
full simulate MY chip&amp;quot; but none of us is the only customer Keil has,
and the chip we use is not the only &amp;#39;51 derivative.&lt;/p&gt;

&lt;p&gt;
Reasonable expectations keep tools affordable, unreasonable
expectations makes them available only to the largest/richest
companies.&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: Dual data pointer registers problem</title><link>https://community.arm.com/thread/74901?ContentTypeID=1</link><pubDate>Thu, 08 Mar 2007 04:59:39 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:a06c6b78-dfe0-406d-82e8-b150e045364c</guid><dc:creator>Xin Yang</dc:creator><description>&lt;p&gt;&lt;p&gt;
So I guess that might be the bug in uVision simulator. In the real
hardware the dual DPTR should be switched by setting the DPS. Can I
say that(lazy to have a go on the hardware :)?&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Dual data pointer registers problem</title><link>https://community.arm.com/thread/47922?ContentTypeID=1</link><pubDate>Wed, 07 Mar 2007 20:21:55 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:ef3dd6be-f107-4223-a607-224f328a6095</guid><dc:creator>Jonny Doin</dc:creator><description>&lt;p&gt;&lt;p&gt;
Interesting. I duplicated your described behaviour in the
simulator selecting the AT89S51. The simulator seems to simply ignore
the dual dptr existence. Even the AT89S8252 simulation is flawed: you
can increment the second dptr, but &amp;#39;mov dptr&amp;#39; always loads the
dptr0.&lt;/p&gt;

&lt;p&gt;
I routinely use the Philips AT89C668 using the dual dptrs, and the
simulator behaves exactly as the silicon for that part.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>