Pic micro direct to RS485 using the Uart module to MAX485 etc.
It appears it may be relatively easy, but I thought I would see if it has already been done and how it the RTS etc was handled?
And anything to watch for?
Max.

 

I assume you want to create an RS485 LAN.
I don't use RTS/CTS etc. I use a 2-wire plus GND interface.

Either one device is declared as MASTER and all others are SLAVE or you can use peer-to-peer communications.

With MASTER/SLAVE, the MASTER always initiates the transaction. Only the addressed SLAVE is allow to respond.

With peer-to-peer protocol you will have to implement collision detection.

 

The only real trick to using RTS/CTS is to arrange for line turnaround after the last bit (probably a stop bit) has been transmitted and before the first bit (probably a start bit) arrives. Various techniques have been implemented and you just need to allow some margin.

 

I assume you want to create an RS485 LAN.
I don't use RTS/CTS etc. I use a 2-wire plus GND interface.

Either one device is declared as MASTER and all others are SLAVE or you can use peer-to-peer communications.

With MASTER/SLAVE, the MASTER always initiates the transaction. Only the addressed SLAVE is allow to respond.

With peer-to-peer protocol you will have to implement collision detection.

Yes, but I meant using the MAX485 et al these require a direction signal in, I am only using the customary two wire and shield to receive/transmit to one master.
The method often used when going from RS232 to RS485 is to use the RTS signal.
I am going direct from Usart module to MAX485 or similar.
Max.

 

Right. So you need to control the DE/RE control lines on the RS-485 receiver/transmitter.

How B&B Electronics do it: they sense the data lines from the UART to control DE/RE.

You can use RTS/CTS as another option.

 

OK thanks to both, I will have to play around a little!
Max.

 

But how about doing a really minimalist version without the MAX485 (or SN75176) transceiver? Use an analog comparator to receive the data, and turn the pins into outputs when you want to transmit. PIC processors let you take an external output from the comparator and you could send that into the RX pin, but I don't see a way around the need to bit-bang the transmitted data. Or could you use a second comparator just as an inverter? There'd be a slight skew between the highgoing and lowgoing lines, but at low data rates that wouldn't be much of a concern.

If you need to check for the end of the last character in order to deactivate the transmitter, the buffer-empty flag (TRMT) is the thing to look at. Unfortunately the TXIF interrupt occurs at the start of a transmitted character, not the end, and TRMT can't trigger an interrupt. You could set a timer instead, if you have one available.

 

If you are developing your own code on MCU I would use an extra output pin to control DE/RE tied together.

 

I want to use the Uart module, I have it working right now with a MAX232 & RS232 port and a $4.00 RS232 to RS485 ebay convertor, I am looking to replace this the MAX232 with the MAX485.
I am very low on spare I/O on the pic!
Max.

 

Well, if you haven't got pins to spare, my brilliant idea of using the processor's capability instead of an interface chip isn't going to work. One thing it doesn't do is conserve I/O pins.

 

I have one spare right now, so I am trying to work around that.
Max.

 

You could use a oneshot with its input tied to transmit data; the output or its inversion controls DE/RE. Start by sending one or more pad characters to get the oneshot to enable transmit data, then send the message. Of course the oneshot will need to be retriggerable. Make sure the responders know that they should not begin transmitting until the oneshot has timed out. They can also send one or more throway pad characters at the beginning of the message.

 

If you trigger the retriggerable monostable on the leading edge of the START bit you should be ok at moderate baud.

What's your baud?

 

If you trigger the retriggerable monostable on the leading edge of the START bit you should be ok at moderate baud.

What's your baud?

Only if the delay is small and the transition from tristate to SPACE actually looks to the other end like a START bit. That is why we had a tendency to use throwaway pad characters for exactly this purpose.

 

What, MORE external chips?

 

What's your baud?

9600.
Max.

 

Another problem with using a monostable is the turn-around delay required.

The monostable has to be set to time-out greater than one character time. At 9600 baud that is >1ms.
Hence the device has to wait at least this time before being allowed to respond.

 

I never said there were no tradeoffs, and I certainly understand the downsides to using a oneshot, especially one of the analog variety. I mention it only in the context of using the data lines to control the RS485 DE/RE pin on the trnasceiver without using a separate pin from the PIC. It can be done, but there is always a price to pay. You could also adjust the termination scheme on the RS485 bus and run the data directly to DE/RE with the input at logic 1. Now you have something that resembles a CAN Bus with a dominant or driven state and recessive state whose values are determined by the termination resistors. It's not perfect either, but you should be able to make it work at 9600 baud.

 

The way I've done it is like this:
Make a transmit buffer (FIFO array of char) of a suitable size for a packet of data. That way you can just dump data into it and get on with other processing.
Use the interrupt-driven transmit capability of the PIC such that
1) Whenever you write to the FIFO enable the transmit interrupt TXIE.
2) Since the transmit buffer is empty, a TXIF will be generated indicating that the transmit buffer (not the uart shift register) is empty and can take another character.
3) The interrupt service routine sets the RS485 to TRANSMIT then fetches the next character off the transmit buffer and writes it to TXREG. The UART will start transmitting.
4) When thate character is sent, another TXIF will be generated indicating that you can load another character(*). If the FIFO is empty, check TRMT (shift register empty) and disable the RS485 transmitter. If not, the last character is being shifted out. You will get another TXIF that will satisfy FIFO empty and TXMT. Turn the RS485 off then and disable TXIE since there is nothing left to do. It will be reenabled when you drop another char onto the FIFO.

Important issues:
Disable interrupts when actually writing (or reading) the FIFO.
Be sure that you check TRMT before turning the transmitter off.

A separate but vital issue is that you need a protocol to make everybody agree on who gets the bus and when. I've pretty much used one master and many slaves. No slave can initiate transmission unless in response to the master. The master is responsible for polling slaves often enough to see what they have to say. The alternative is some sort of collision detect/restart scheme. I use CAN for that.

What language/PIC are you using? I probably have some code you can look at.

(*) Technically, you will get another interrupt right after you write the first character and before its shifted out. That's because the UART is double buffered and can hold one character ready to be sent while shifting one out. TXIE happens when the UART buffer register is empty, NOT when the shift register has finished sending the last bit. That's also why you need to incorporate the check on TRMT (nothing left to shift) before turning off the transmitter. Its a very common mistake.

 

What language/PIC are you using?

Assembly, 18F23k22.
Max.