We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
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
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