how can i obtain the current values of registers like accumulator,B,stack pointer,PSW,DPTR,etc in C?? i am currently working on a trainer/development kit for 8051..One of the commands to be executed is R<CR> Once this command is executed,the values of all the registers like A,B,SP,PSW,DPH,DPL,R0,R1,R7 should be displayed on screen...how do i retrieve these register values in C?
I know very little about C51 but maybe you can try something like this: Write an assembly-only module that exports functions that return the register values you need. Write C code to call these functions. Put these into the same project. Link. Run.
"how do i retrieve these register values in C?"
the approach will depend on what kind of registers you are trying to read.
something like x=DPH; should work, for registers that are not impacted by the statement itself - look at the disassembly for sure.
for registers whose value will be impacted by the statement (PC for example), you may have to do manual adjustments.
Because the 'C' (almost certainly) will impact the register values, you should consider whether doing this in 'C' is really a good idea...
"Because the 'C' (almost certainly) will impact the register values,"
it depends on the particular registers to be read. they are not always impacted.
"Because the 'C' (almost certainly) will impact the register values, "
the right sentence is:
Because the 'C' (almost certainly) can impact the register values. C doesn't always impact the register values.
The tough part is to have a program debug itself.
So it wouldn't really be meaningful to have a main loop that detects a 'R' and then dumps the registers - it would not dump the register values when you are inside any of your algorithms, but instead dump the register values while dumping the register values.
One thing to consider is to have an ISR that picks up characters from the serial port, and is using a different register bank. It could dump a number of registers from the main register bank. For stack pointer, it would know how much data that has been pushed on the stack.
But in the end, dumping of register values is only meaningful if reasonably well hidden from the main program.
The right sentence is:
"the 'C' certainly can impact the register values"
And I think it's highly likely (to the point of being almost certain) that it will imact at least the accumulator, SP, and PC.
So it is still well worth considering doing this in Assembler - where you can be absolutely certain about what registers are affected - and how.
"I think it's highly likely"
true. and that means that it may not impact some registers for some operations. so your original sentence of "...will impact" is simply wrong.
I think we will find that in the end, something like what the OP wanted to do may not be doable for all cases / registers.
and this isn't unique to 8051.
"your original sentence of "...will impact" is simply wrong"
That's why I actually said,
"... (almost certainly) will impact..."
"(almost certainly) will impact..."
ok. take a typically statement of "x=REGISTER_Y;", for the 40+ registers on a typical 8051, tell us how many of them will CERTAINLY be impacted by that read statement and how many of them will NOT CERTAINLY be impacted by that read statement.
since these registers are in the memory,cant i just keep a pointer to these locations and read the values from those locations??
The specific registers you mentioned were:
"A,B,SP,PSW,DPH,DPL,R0,R1,R7"
They are not all together in one single, contiguous block of memory; They aren'y even in the same 8051 address spaces.
- so you can't have just 1 pointer.
It sounds like what you're actually trying to do is to make a Debug Monitor?
Rather than re-invent the wheel, why not use one of the existing open-source solutions?
eg, www.pjrc.com/.../paulmon2.html
Or, at least, study it to see how this stuff is done...
well i meant a separate pointer for each register,but i guess since these SFRs are directly accessible, something like x=ACC should work..but this doesn't work for PC..how can i retrieve values of PCH and PCL?
But, again, why re-invent the wheel?
Why not, at least, look at existing solution to see how they do this?