• Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

USART delay transmitting data

Status
Not open for further replies.

PicChristmas

New Member
Could anyone tell me why I have to wait for 0.6 seconds for a charater to be sent? If the delays are not used the direction of the RS485 chip has switched back to Rx and the Tx data is lost.

I am using a 18F2420 PIC at 40 mhz with the buad set at 57.6 with TXSTA = b'00100100' and RCSTA = b'10010000'


Code:
		bsf PORTC, 0x1, ACCESS		; set RS485 direction to XMT
		bsf PORTC, 0x2, ACCESS		; turn off LED
		movlw char
		movwf TXREG
		btfss	PIR1, 0x4		; Write only if TXREG is ready
		bra	$ - 2
		call Delay				; 0.2 seconds
		call Delay				; 0.2 seconds
		call Delay				; 0.2 seconds
		bcf PORTC,0x2, ACCESS 	; turn on LED
		bcf PORTC, 0x1, ACCESS	; set RS485 direction to RCV
		return
 

PicChristmas

New Member
The delays and the LEDs are not the problem. I had to put the delays in for the charater to be sent out the RS485 network. If they are not there the terminal that monitors the RS485 network never gets the data sent by the PIC. The delay is in the USART and the delays in the code are there to hold the direction pin on the max485 to allow it to send data.
 

eblc1388

Active Member
I have never used the RS485 so this is a blind guess.

When you send a character, you should confirm that the MAX485 has actually sent it before you manually switch its mode back to receive. How you would do that I don't know.

This is not needed in RS232 as transmit and receive can be done in parallel but MAX485 chip can only operate in half duplex mode. You have only one pair of twisted cable for both transmit and receive.

In your original code without the delays, you have asked the PIC to select MAX485 TX mode and send a character, and after a few instructions(i.e. a few 100nS later), you changed the MAX485 mode into receiving mode. How can the MAX485 have sufficient time to do the job?

I apologise if my comment is entirely BS.
 

PicChristmas

New Member
Thanks everyone for their input. I'm still trying to figure this one out. My best guess is I am not handling the USART correctly and the Rx section of the USART is delaying the sending of transmit data.

When you send a character, you should confirm that the MAX485 has actually sent it before you manually switch its mode back to receive. How you would do that I don't know.

This is not needed in RS232 as transmit and receive can be done in parallel but MAX485 chip can only operate in half duplex mode. You have only one pair of twisted cable for both transmit and receive.
The MAX485 is a dumb device that just does level interfacing. This project is used on a half duplex 485 network and must be interfaced to it.

In your original code without the delays, you have asked the PIC to select MAX485 TX mode and send a character, and after a few instructions(i.e. a few 100nS later), you changed the MAX485 mode into receiving mode. How can the MAX485 have sufficient time to do the job?
At first there were no delays. Then when that was found the delays were added. There is going to be a small delay but it should only be enough time for the USART to shift the data out and a small amount of settle time before and after data is sent.
 

Nigel Goodwin

Super Moderator
Most Helpful Member
PicChristmas said:
Code:
		movlw char
		movwf TXREG
		btfss	PIR1, 0x4		; Write only if TXREG is ready
		bra	$ - 2
The transmit segment looks wrong?, you're transferring the data to TXREG and then checking if it was empty or not afterwards. You should check if it's empty BEFORE you write to TXREG.

This section from my tutorials shows you how it's normally done, it sends the value in the W register:

Code:
XMIT_RS232  	btfss   PIR1,	TXIF 	      ;xmit buffer empty?
     		GOTO	XMIT_RS232            ;no, wait
     		MOVWF   TXREG		      ;now send
However, you're also not allowing time for port changes to settle, it might be an idea to have a short delay after every change of direction on the port, even if only a nop or two?.
 

PicChristmas

New Member
Thanks!

The "movwf TXREG" being before the bit test and a couple of program flow issues fixed the problem.

Thanks again everyone for your help.
 
Status
Not open for further replies.

EE World Online Articles

Loading
Top