Strange problem with the HSEROUT and HSERIN

[PJALM]

I have been trying to setup a RS-485 network between multiple PICs using the MAX3077E Full Duplex transceiver and everything works great even at 115200 Baud as long as i send a single byte.

Once I start sending more thats when things go wrong.

This is what I am trying to send:

HSEROUT [ACK,ToAddress,Command,Parameter.LowByte,Parameter. HighByte]

and this is the Receiving side:

HSERIN [WAIT(ACK),ToAddress,Command,Parameter.LowByte,Para meter.HighByte]

ACK, ToAddress and Command are all BYTE

Using this code i sometime get 3 bytes but most of the time i only get 2 bytes plus it will not receive again until i reset the pic.


Does anyone know why this would be a problem? I even reduced the speed to 300 Baud with the same results.

[Jerson]

Are you facing a hardware turnaround issue here?

Jerson

[Ioannis]

I faced the same problem when connected the two PIC systems with 485. With direct connection no problem occured. Seems to be the switching delays from the drivers, but up to this momment could not find a solution. So I send one character at a time(*). On the scope everything seems to be right. Termination also was tested.

(*) One could suggest that pacing could help. It did not (very strange though...)

Ioannis

[PJALM]

The only problem with sending one character at a time is that I have 8 devices on the rs485 bus so i need to be able to address them.

Is there an easy way to do so while sending the characters 1 at a time?

[Jerson]

This is a typical problem faced in RS485 based systems. You have to make allowance for the receiver to get a character, buffer it, process it and come back to the point where it is ready to read the next character. I have not worked with a hardware serial port PIC till now, but having experience with the 8051 family, I know that these things matter.

So, what I do is to send a packet to the slave - wait for a few ms for it to reply / handle the packet and then send the next packet if needed.

So, the turnaround time I mentioned is not character to character but packet to packet.

Jerson

[PJALM]

Jerson, this sounds like a soulution but what do you mean by a packet? Do you have an example you have done that might be of help to me?

Thanks.

[Jerson]

Hi PJALM

I don't have any examples in PIC as I am an 8051 major. I have done a couple of projects on PIC but no comm stuff yet.. So, from the 8051 side this is how I did it.

A typical command packet would be something like

STX id cmd arg1 arg2.... ETX where


STX = 02h, ETX = 03h, id is the slave ID, cmd is the function you want the slave to execute.

This packet would be received in the background by an interrupt routine, buffered in a RX buffer. This would then be retreived by the mainline program. The mainline will identify the id byte to be its own and formulate a response to send. So, if you see, there is a delay between the complete packet being available to the slave/many slaves and the Id'ed one responding. We have to account for this delay to receive the response successfully.

I hope this will lead you to a positive solution

Jerson

[PJALM]

Thanks again Jerson.

This is exactly what I am trying to do , I guess now I just have to figure out how to use the buffer in the USART.