This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Need to print out the register contents

I have studied the MCS-51 Instruction set (8051 instruction set summary) but I do not see how to print out the registers' contents.
Can't find anything about this in the Help either. Help!!!

  • "Printing" is a fairly complex operation. It will usually involve setting up a serial port and calling some functions such as printf() in C. You won't find much discussion of the topic in the instruction set manual because it takes hundreds or thousands of instructions to do everything that printf() does. It's a layer well above the instructions themselves.

    If you can set up a project that does serial I/O, printing the registers is just a matter of passing those values to your print routine.

    If you want to view registers in a debugger, then there's probably a window just for that. You might also make use of the fact that the four banks of registers are also the first 32 bytes of internal RAM.

  • Sorry, but I need a little more clarity. How do you call out the specific registers, e.g. R1? Is there some kind of special character that says, "Hey, guy, this is an internal register, not just some variable named R1." Or, to put it another way, how do I define the register in my calling program? I hope this is clearer.

  • Alice, I fear that you are confused about what to expect from your microcontroller.

    To make progress, please tell us WHY you want to do this and WHAT it is you wish to achieve.

  • OK< I want to examine (not in the Disassembly listing) what is in the registers by printing the contents of the registers out.
    I suppose I CAN go into the routines I am supposedly debugging and change them, but that is intrusive testing. I would rather have them return and let me see what the registers are at that time. Through the disassembly listing, I have already noted that all the registers' contents are left intact by the infamous PRINTF, but Reg 7.

    Is that clearer?
    And no, I don't expect this micro=controller to be as user-friendly as the old Rational machine, which would even correct your Ada syntax as you typed it in. But I'm afraid Keil's 'HELP' ain't.

  • "...the old Rational machine, which would even correct your Ada syntax..."

    I think you are very confused!

    It was not the processor doing that for you - it was your Software tools; ie, some software running on your development system.

    That is a very, very, very long way removed from the actual Target processor!

    If you are debugging, why can't you just look in the 'Registers' window of the debugger?

  • Denigrating the customer doesn't really help a whole lot. I can easily trap the register contents, watch them all day within the debugger. I want to print those contents out from the calling program, and I would think this tool could help me do that with some kind of special character.

  • you say "registers" and "printf()".
    Registers, as such, are totally uninteresting in "C" programming, except in the case where printf() would not help you any. If, for instance, you have an incorrectly coded ISR that screw up a/some register(s), involving printf() will generate other effects which would/could mask what you are hunting. Also, which registers? Bank0 or bankn?

    If the simulator can not help you, go buy an ICE.

    I have studied the MCS-51 Instruction set (8051 instruction set summary) but I do not see how to print out the registers' contents.
    Instruction set and printf()??? Did you expect to find a "pront register opcode"?

    You need to describe what you are doing as well as what you want (print out the register contents)

    If any of the above offend you, remove the offence by being clear what you are doing: C or assembler - never stated reason for register dump - never stated why the simulator can not help - never stated.

    Erik


    Erik

  • "I can easily trap the register contents, watch them all day within the debugger."

    So what's the problem, then??

    If you want it printed, get the debugger to print it!

    "I want to print those contents out from the calling program"

    Do you actually understand how function calls happen down at the processor hardware level?
    The calling program cannot see inside the function as it runs!
    The values left in the registers when the function returns may or may not be useful.

    "I would think this tool could help"

    What tool, precisely?

    "with some kind of special character"

    What makes you think that?
    How do you think this "special character" might work? Where do you think you would put it?

  • There's no excuse for a professional to be nasty. I've been trouble-shooting for too long, and as a systems analyst, know that by asking questions rather than blaming the questioner, you can usually get the info you need to answer the question. There are no stupid questions, just stupid replies; and what's this forum for anyhow, if not to help people?
    I'm not using Keil's PRINTF, by the way, but my own. It sounds as though you haven't ever actually printed out the internal register's contents from the evasions and offensive remarks on this board. Won't do it again.

  • "...as a systems analyst..."

    Now I understand!

  • Why is it that the "experts" on this forum always fire back some smart-assed "why do you want to do that?" reply to a honest question instead of keeping quiet when they don't have an answer?

  • Jim,

    As someone who's been on the fired-at end of their remarks sometimes, I think I understand. For instance, in this case, what they're trying to avoid is answering Alice's question about how to print out the register contents only to deal the very next day with something like "Why don't the registers have the data I expect?"

  • "Why is it that the "experts" on this forum always fire back some smart-assed "why do you want to do that?" reply"

    Because very often, the question as asked makes no sense!

    In such cases, it is very often better to take a step back and ask what is actually trying to be achieved, rather than just try to debug a "solution" to an unknown problem!

    It is also common that the "solution" itself is flawed - and is the source the questioner's difficulties.

  • Ok Alice, let us use a parable:
    You say "my car makes a pinging noise"
    we reply "which make and model"
    you answer "none of your business"
    we reply "cant help you"
    you say "snobby mechanics"

    Got it?

    Erik

  • "Why is it that the "experts" on this forum always fire back some smart-assed "why do you want to do that?" reply to a honest question instead of keeping quiet when they don't have an answer?"

    If you 'phone your doctor and ask "How do I remove one of my kidneys", what would you expect his answer to be?

    1) With a knife.
    2) Why do you want to do that?

    or should he just keep quiet?