Hi, When I execute the first putchar statement in the code below, nothing is printed to the serial window, when I execute the second putchar statement, the value I thought would print out firstly (0xFF) prints out now. In the for loop I have printed the value i, but likewise the value for i prints out after executing the second putchar statement in that loop. Any ideas why this is happening? Also I have reset the value of counter1 to 2, but as I am stepping through the putchar statements, counter1 increases. I cant see how this can happen as the only way the counter can increment is in the ADC interrupt routine, but the program doesn't jump to this routine in the meantime? If anyone can help, it would be great! Lisa
if(finished) { rec1[buf].cnt = counter1; // store counter1 value in 1st element of array buf ^= 1; // set alternative buffer up counter1 = 2; // reset counter1 to original value // print out whole structure putchar(rec1[!buf].cnt); putchar((char) (rec1[!buf].base_value >> 8)); putchar((char) (rec1[!buf].base_value)); for(i = 0; i < MAX_COUNT-2; i++) { putchar(i); putchar(rec1[!buf].x[i]); } finished = 0; }
Simulating the simulator: SBUF='A'; while(1); //Breakpoint My 'A' will still appear on the real hardware. I would expect it to also appear in the simulator serial window. Why? In the simulator, when you stop program execution, you effectively stop time. All timers, oscillators, interrupts -- all of it -- actually stops. You typically can't do that with real hardware. Or, if you do, you may create a dangerous situation that damages or destroys hardware. I'm talking about the differences in expected behaviour between debugging on the simulator and debugging on the target. The SBUF issue above was a good example, here's another: void Fn(void) { int a=4; int b; b=a; printf("%d",b); } If I break on the printf() line and try and watch a and b I can sometimes see the correct value of a and sometimes not. This may have to do with name overloading. You see, the object named A can be the accumulator, your variable A, or another global variable A. So, which A are you looking at. The same applies to B (since there is a B register on the 8051). But, this issue applies to both simulators and to emulators. There is no magical hardware solution where the emulator "knows" where to find the value of A. This information comes from the object file and, since A can be optimized out, it may very well be. So, I'm not sure how this makes simulators a waste of time. Using this as a justification, you could further generalize that debuggers are a waste of time. Jon
"Why? In the simulator, when you stop program execution, you effectively stop time. All timers, oscillators, interrupts -- all of it -- actually stops. You typically can't do that with real hardware." Yes, I realise this. The problem is that I want a simulator which gives me the same result I would get using my usual 'printf() and oscilloscope' debugging technique. I don't want a simulator which simulates an unrealistic situation. Out of interest, what happens if you break half way through the transmission of a character? Do you get one corrupt character in the serial window on interruption then possibly another character when execution resumes, or does the 'correct' character magically appear on resumption? "This may have to do with name overloading. You see, the object named A can be the accumulator, your variable A, or another global variable A. So, which A are you looking at. The same applies to B (since there is a B register on the 8051)." And again, the simulator has left me confused. I don't know what I'm looking at. "But, this issue applies to both simulators and to emulators." It may not surprise you to hear that I avoid emulators wherever possible. "There is no magical hardware solution where the emulator "knows" where to find the value of A. This information comes from the object file and, since A can be optimized out, it may very well be." Quite. "So, I'm not sure how this makes simulators a waste of time." Because I am never sure whether what I see happening in the simulator is what I will see happening on the target. "Using this as a justification, you could further generalize that debuggers are a waste of time." In large (usually not embedded) 'C' programs debuggers can be quite useful, especially when trying to track down stack corruption. On the 8051, however, I don't really see the need.
Out of interest, what happens if you break half way through the transmission of a character? Do you get one corrupt character in the serial window on interruption then possibly another character when execution resumes, or does the 'correct' character magically appear on resumption? The character is not transmitted until it's transmitted (rather profound, huh). The correct character is transmitted when the transmission time has elapsed. So, the correct character appears in the serial window. Jon