Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
???
08/09/11 13:21
Modified:
  08/09/11 15:29

Read: times


 
#183280 - Oh Details Details
Responding to: ???'s previous message
More attention to details needed.

In this routine from your original code posting...

;-------SERIAL DATA TRANSFER.

SEND:	MOV	SBUF, 50H
	MOV	SBUF, 51H
	MOV	SBUF, 52H
H_1:	JNB	TI, H_1
	CLR	TI
	RET


You have made several mistakes. First off, why reference the internal memory addresses as 50H to 52H. You should make use of the buffer label, "ASCI_RSULT" that you created and used in other places in the code. You could have used ASCI_RSULT+0, ASCI_RSULT+1 and so forth to make it clear where the data that you are loading into SBUF is coming from. Alternatively, and possibly better, would be to make a loop similar to that used in your DEC_ASCI_CONVRT routine to reference the buffer via the R0/R1 pointer register. (The loop will look even more attractive after you comprehend my next comment).

Another problem with this code is a common one made by beginning programmers that are using the UART for the first time. Outputting to the SBUF register does start a serial output operation but when you output three things in rapid succession like you have done only some of the data is going to end up being sent out the UART. At best the first byte goes out and then the 3rd byte. Since this routine gets called from your main loop it is questionable just what does end up making it out the UART. This comes into play because it takes quite some time to send out a serial byte at your selected baud rate. The UART on an 8051 type MCU is designed to move the first SBUF written value into the serial transmit shift register when any previous shifting is complete. Until that time it is not safe to load another byte into SBUF because it will simply overwrite the value that is being held there. (You see that the buffering in front of the UART transmit shift register is just one level deep. The SBUF does NOT have a FIFO stack underneath that can hold as many bytes as you care to shove into it). The MCU has the TI bit that gets set when the value being held in SBUF gets transferred to the transmit shift register. When you see TI become set then you know it is safe to proceed to load another value into the SBUF. So you should be looping and checking the TI bit for each byte you intend to send out the UART. I could also suggest that in the case of your program it probably makes the most sense to check the TI bit each time _BEFORE_ you output anything to the SBUF. This way the routine does not need to make any assumptions regarding whether the UART was left shifting out a value while from the previous call to SEND. Note that the need to perform the TI polling for each byte suggests that in may make sense to install a loop around the whole TI loop polling and the SBUF output.

Michael Karas


List of 17 messages in thread
TopicAuthorDate
need help to display timer count on hyperterminal and LED'S            01/01/70 00:00      
   Attention to Details            01/01/70 00:00      
      divide by 10            01/01/70 00:00      
         Hundredth digit is quotient of division by 100            01/01/70 00:00      
            thanks            01/01/70 00:00      
               Debugged with pen and paper?            01/01/70 00:00      
                  Debugged            01/01/70 00:00      
                     Decimal or hexadecimal?            01/01/70 00:00      
                        decision            01/01/70 00:00      
                           So take up the challenge then            01/01/70 00:00      
                              agreed            01/01/70 00:00      
                        Actually BCD!!            01/01/70 00:00      
   Oh Details Details            01/01/70 00:00      
      update            01/01/70 00:00      
         Issues            01/01/70 00:00      
            better to check before sending            01/01/70 00:00      
               Even Better....            01/01/70 00:00      

Back to Subject List