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
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 'mov dptr' always loads the dptr0.
I routinely use the Philips AT89C668 using the dual dptrs, and the simulator behaves exactly as the silicon for that part.
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 :)?
So I guess that might be the bug in uVision simulator
I would not classify this as a 'bug', I would classify it as "expecting more than what is reasonable"
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.
I know that in the mind of most the issue is "why does keil not full simulate MY chip" but none of us is the only customer Keil has, and the chip we use is not the only '51 derivative.
Reasonable expectations keep tools affordable, unreasonable expectations makes them available only to the largest/richest companies.
Erik
the above could, of course, be reported as a request but still is not a 'bug'.
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.
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.
View all questions in Keil forum