I am using a Triscend TE505 (with 2 Data Pointers). In addition to the standard set, the debugger Registers window adds the following under 'Sys':
Sys | : +--auxr1 | +--dptr | | | +--[0] | | | +--[1] :
FUNC void ShowRegs( void ) { : printf( " %02x", AUXR1 ); ______________________^ *** error 34, line 18: undefined identifier printf( "%04x", DPTR[0] ); *** error 46, line 19: subscript requires array printf( "%04x", DPTR[1] ); *** error 46, line 19: subscript requires array printf( "\n" ); }
In the triscend data sheet, look up the DATA addresses for AUXR1, DPTR1, and DPTR2. Then, using those addresses, sfr them in the C file you wish to use them in:
sfr AUXR1 = 0xAA; // junk address for example only sfr DPTR1 = 0xBB; // " sfr DPTR2 = 0xCC; // "
printf(" 0x%02X\n", (unsigned int) AUXR1);
No, that doesn't work: the uVision Debug Functions use a C-like Language which is a subset of ANSI; it doesn't include Keil's extensions like SFRs, _at_, etc. However, they do provide builtin functions like _RBYTE which read from absolute hardware addresses. Unfortunately, the _RWORD function seems to use the wrong byte ordering, so can't be used to read a whole 16-bit DPTR in one go. :-( Just seems like another example of uVision's Not-Entirely-Integrated Development Environment (NEIDE?)
Ah, sorry. I mis-understood. I thought you were doing this at run-time. Man, I am so glad I have a Signum Systems' ICE so I don't have to mess with simulation. Sorry I couldn't help. - Mark
There is only one address for DPTR. So, the only way to change the DPTR in your program is to change the DPS register (which selects the DPTR) and then change the DPTR. To change the contents of a register in the REG window, click on the line with the register. Then, wait a second or two and click again (do not double-click). A box appears where you can type in the new value. Jon
Yes, I know how to edit registers manually; what I wanted to know was how to access them symbolically (preferably) from a uVision2 Debug Function. The uVision debugger clearly knows about these extra registers as it's able to name & display them, and lets you modify them, as you described. So why can't the same debugger's Debug Function use the same names? NEIDE! BTW: The Triscend does actually have two DPTR registers; here are their C51 definitions:
sfr DPL = 0x82; // Standard 8051 DPTR sfr DPH = 0x83; sfr DPL1 = 0x84; // Triscend 2nd DPTR sfr DPH1 = 0x85; sfr DPS = 0x86; // DPTR Selector
Ahhh, Yep - I forgot about that. Doh. You can change these in the debugger by just accessing them by their symbolic names. Jon
"You can change these in the debugger by just accessing them by their symbolic names." Nope; doesn't work:
>DPTR 0xB7BB >DPH 0xBB >DPL 0xB7 >dpl1 *** error 34: undefined identifier >dph1 *** error 34: undefined identifier >auxr1 *** error 34: undefined identifier
We see your problem. For the time being you should use the _RBYTE and _WBYTE built-in functions. However, we will add this SFR's to the Tricsend simulation. The real problem is that we do not have finialized the Tricsend simulation.
Yes, that's the workaround that I've used. When the Tricsend simulation is finalised, would it be possible to use the name "DPS" (to be consistent with the Triscend documentation) rather than "AUXR1?"