USART delay transmitting data

[PicChristmas]

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'

		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

 

[Jay.slovak]

LOL That's only for LED indication! You can skip those delays and it will work (even faster).

 

[PicChristmas]

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.

 

[Jay.slovak]

Ups sorry, I thought you got this code from somewhere and didn't know why it's there...

 

[eblc1388]

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]

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]

		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:

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]

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.