RS485 sending text (sometimes work and sometimes not)

lisek_lichu · Joined: 27 Aug 2012 Posts: 23

Hello,

I'm trying to write a little project to make a communication between few PIC 16F628A and one PC.

communication diagram (for test only one PC and only one PIC) is below:

PC <-> MAX232 <-> MAX485 <-> ........<->MAX485<->PIC

My code is really simple:

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

Get creative. Do some experiments. Run a test program that doesn't
use the while() loop or most of the code inside it:

Ttelmah · Joined: 11 Mar 2010 Posts: 19539

First, how is the PC controlling the enable it's end?. What circuitry/code involved?.
With standard 2 wire RS485, comms is 'half duplex', with only one end able to talk at a time. I'd suspect that when you send data from the PC, _it_ is setting it's enable to take over the bus, and is then not releasing it. Normally if you are using some of the off the shelf packages that are supplies as 'demos' for RS485 cards, they take command when characters are sent, and stay holding the bus, until an ETX, or EOL is sent.
Second comment (not the problem, but may cause problems in the future), bus termination. RS485, is designed to have termination at each end of the bus. Also (depending on the drivers you are using), the termination should be designed to bias the bus to the 'off' state. Texas have some good application notes about this.
As PCM programmer says, start a little simpler. Verify you can send in each direction, and get 'valid'' data, and that the bus goes idle when you are not sending. I suspect this is the problem at the PC end.

Best Wishes

RF_Developer · Joined: 07 Feb 2011 Posts: 839

If you are using stream names, in this case you're calling the serial stream "PC", then you should use that name in the kbhit call, or anywhere else to do with serial/RS232 comms:

gpsmikey · Joined: 16 Nov 2010 Posts: 588 Location: Kirkland, WA

One thing I didn't see (although I have not had my coffee yet either) is a delay after sending before you turn off the enable on the transmit side. My favorite trick is to send a character to the uart, then disable the output so I can listen for the next message or whatever forgetting that you need to delay a character time at least so it can be shifted out.

mikey
_________________
mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3

Ttelmah · Joined: 11 Mar 2010 Posts: 19539

If you use the CCS 'enable' option in #USE RS232, it waits for the character to be sent, before disabling this.
I'm still most suspicious of the 'enable' handling at the PC end... Smile

Best Wishes

lisek_lichu · Joined: 27 Aug 2012 Posts: 23

Thanks for fast reply.

lisek_lichu · Joined: 27 Aug 2012 Posts: 23

lisek_lichu · Joined: 27 Aug 2012 Posts: 23

lisek_lichu · Joined: 27 Aug 2012 Posts: 23

Ttelmah · Joined: 11 Mar 2010 Posts: 19539

Remember the 'off' state on the RS485 bus, gives 'high' at the PIC. This is where the 'on' confusion comes.
If you are disabling the receive on the transceiver, when you send, then you also need a pull-up resistor on the line from the transceiver to the RX pin on the PIC. If not, then you will also receive every character you send.

Best Wishes

lisek_lichu · Joined: 27 Aug 2012 Posts: 23

Ttelmah · Joined: 11 Mar 2010 Posts: 19539

The problem is if you talk 0/1, or high/low, versus idle/active.

In TTL async serial, the 'idle' state, is 5v at the chip. So 'high', or '1', is the idle state. When nothing is being received, this line needs to 'idle high'.
Now over RS485, the 'idle' state, is to have the 'A' line at least 200mV above the 'B' line. The bus is defined, so that if this is not true, and the lines are just allowed to float, the receiver output, will hold the last level received, which can result in you continuously receiving zero bytes....

Now separately you have the control of the RS485 buffer. There are two lines, /RE. and DE. You can wire two different ways:
The first, you leave the receiver permanently enabled, and just turn the driver on/off when you want to talk. Done this way, you will receive every character you send (which can be a diagnostic that the data is going onto the bus), but means your software has to be able to cope with this.
For the second, you wire the /RE, and DE lines together, and turn off the receiver, when transmitting. Key here is that since you are turning the receiver 'off', _you_ have to ensure that the RO line is pulled high (idle) when not driven by the receiver, or you _will_ start receiving spurious characters as the line floats.

Now a third thing. Timing of the 'enable' line.
The chip itself has 1.99999 characters of hardware buffering in the transmit. One actual 'buffer', and the output shift register. The CCS code, when asked to control the 'enable' line, checks the TRMT bit (transmit shift register empty), and only raises the 'enable', when this goes true. This means the code has to wait for the characters to send, rather than just getting on while the hardware transmits. If you want to control the line yourself, you need to do the same, or provide a delay (the latter is slightly more dangerous, since if too short, the characters may not finish transmitting, while if too long, you may miss the start of a reply, if this is really fast). A delay is OK, provided there is a slight pause before the other end replies.

Best Wishes