This is a bit of funny one (see code below). Basically (1),(2),(3),(4),(5) and (6) all transmit their data successfully via SBUF. This was captured by Hyperterminal. However (7) only transmitted correctly when assignment to next state was made at (a) and not (b). The code below is commented in its non working state. Any thoughts? This has happened in v7.0 and v7.5 of C-Compiler for C51. I have just upgraded compiler, but I can not believe it is the compiler what am I doing wrong? Declarations in Global.h //------------------------------------------- extern unsigned char flag_DLE; extern unsigned char next_state; #define WAIT_FOR_START_SEQUENCE 0x00 #define WAIT_FOR_CHAR 0x01 #define STX 0x05 #define ETX 0x04 #define DLE 0x0F //------------------------------------------- Definition in main.c //------------------------------------------- unsigned char flag_DLE; unsigned char next_state; . . . . Code in void main()in main.c //------------------------------------------- (1) SBUF = STX; Dly(10); (b) next_state = WAIT_FOR_START_SEQUENCE; (2) SBUF = STX; Dly(10); //(a) next_state = WAIT_FOR_START_SEQUENCE; (7) SBUF = next_state; Dly(10); rcv_msg_pos = 0x00; (3) SBUF = rcv_msg_pos; Dly(10); (4) SBUF = WAIT_FOR_START_SEQUENCE;; Dly(10); (5) SBUF = WAIT_FOR_CHAR; Dly(10); (6) SBUF = ETX; Dly(10); //-------------------------------------------
The delay routine may not be accurate. Moving the one line may create different sequences of machine instructions, which may affect the timing. Since SBUF is loaded with next_state, case (b) means the code generator has to remember the state longer than case (a). Register usage might be significantly different. Take a look at the .lst or .cod files to see the generated code. How fast is your CPU? (Clocks and cycles/instruction) How accurate is Dly(), and is there any possibility that it doesn't wait quite long enough? I'd second Erik's suggest to wait on TI (transmit interrupt) to know when SBUF is empty. That removes any need to worry about clock rates or instruction timing. What other code references next_state? Any other interrupt handlers or tasks that might be doing something a little earlier or later once this state variable changes?