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, the Address Window appears the pointer address 4000h and 8000h have been written into the same address saying 82h-83h - the DPS in AUXR1 didn't switch the DPTR though the instruction 'XRL DPTRSW, #DPS' definitely alters the DPS in step run. Why this happened?
DPTRSW DATA 0A2H ; DPS EQU 00000001B ; ORG 00H
MOV R7, #4 ; MOV DPTR, #4000h ; XRL DPTRSW, #DPS ; MOV DPTR, #8000h ;
LOOP: XRL DPTRSW, #DPS ; CLR A MOVC A, @A+DPTR ; INC DPTR ; XRL DPTRSW, #DPS MOVX @DPTR, A ; INC DPTR ; DJNZ R7, LOOP ;
END
Per Westermark said: "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.
A simulator can also alow testing of some worst-case scenarios that may be _very_ hard to generate on a real hardware platform. "
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. 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.
What I don't agree in Erik statements is that one should be 'grateful' for the toolset functionality, and simply ignore the bugs.
TOTALLY MISQUOTED
I stated something like "bugs should always be fixed, features are up to the provider".
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. Then why are you "demanding full simulation for" this particular derivative?
re the posts about "the importance of simulation"; 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 'predict'. 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.
Erik