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!!!
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?
Like the little red hen, I answered my own question with an assembly routine. Since I knew from the disassembly listing that I hadn't lost any register contents I was interested in but R7, it was a simple thing to do. Other than Jim Smith, your mothers should be ashamed of you. Majoring in ridicule rather than "How do I get this done?", finding reasons NOT to answer the question that you didn't know the answer to, being a smartass....none of that is professional behavior. And I hope, other than Jim Smith, that none of you have to deal with customers, for your company's sake.
answer the question that you didn't know the answer to You have totally not grasped what this is about. It is NOT that we do not know the answer to your question, it is that we know too many answers. In order to give the answer applicable to your situation,we needed more info. Ok go to your corner and stamp your little feet, evidently you have no interest in participating in finding the best solution to your problem, just "give me an answer or I'll get mad". Erik