RS485 Communication with Pi Compute 3L

[moksha29]

In my application, I am connecting multiple RS485 to Pi compute module through the multiplexer(just for selection of RS485) and finally connecting data lines to the MAX485 and then to pi on UART port (GPIO14, GPIO15) and RE/DE(GPIO13).

But there is no such library or driver support for MAX485-TO-PI communication. Am not able to get data on UART port.

Herewith I am attaching the block diagram of the connection:
https://drive.google.com/open?id=1c2Pbf ... juMIrDbi-l

[Heater]

moksha29,

We have no permission to access your google drive.

...there is no such library or driver support for MAX485-TO-PI communication.

Why would you need one?

Once you have configure the GPIO UART properly it will send and receive data by writing and reading to it's device in /dev (Sorry I forget what it's called off hand.) A quick search of this forum will find you instructions and discussion of using the GPIO UART.

So just connect the GPIO UART to the MAX485's RO and DI pins.

What you may need, depending on your application, is to drive the MAX485's /RE and DE pins so as to enable reception and transmission respectively. Connect those to two other GPIO pins and drive them uing the GPIO library of you choice.

[danjperron]

I did a module using modbus and I found out that the handshake of the PI was not reliable to control the direction of the signal.

Then I added a small cpu to control the direction and it works perfectly! I don't like the idea to connect the direction with the send.It removes symetry of the signal, The output is enabled only on "space" (TTL Level low) and on mark (TTL level high) it is floating and assume that the resistor bias will change the signal polarity.


You should check What I post about it!

Right now I'm using usb to RS-485 adapter . They are so cheap that it cost less to use them than to make a direct interface to the PI.


This is my post about my module.
https://www.raspberrypi.org/forums/view ... 44&t=75189

This is my github of my multi IO module
https://github.com/danjperron/PIC_MULTI_10_IO

This is my rs-485 switcher adapter
https://github.com/danjperron/RS485switch

And finally the very cheap USB to RS485 adapter
https://www.dx.com/p/usb-to-rs485-adapt ... een-296620

[moksha29]

@Heater



https://drive.google.com/open?id=1c2Pbf ... juMIrDbi-l

[danjperron]

It is really weird that you need to multiplex the RS-485 since RS-485 is by itself a bus system. (ALl RS-485 connected together).

I thing that you should go to the bare I.C. since you are allowed to enable the receive and the transmit signal. A simple 74HC138 , on GPIO control for a,b,c input, connected to the TL-485 device will allowed to switch port .

I.M.O. I thing a USB hub with multiple USB to RS485 will do a better job. With that method you could send and receive data from each USB adapter in parallel.

[6by9]

It is really weird that you need to multiplex the RS-485 since RS-485 is by itself a bus system. (ALl RS-485 connected together).

If the devices don't support addressing, or the addresses are all set to the same value, then you need some way to switch between them.

Then I added a small cpu to control the direction and it works perfectly! I don't like the idea to connect the direction with the send.It removes symetry of the signal, The output is enabled only on "space" (TTL Level low) and on mark (TTL level high) it is floating and assume that the resistor bias will change the signal polarity.
.dx.com/p/usb-to-rs485-adapter-black-green-296620[/url]

Not a particularly great solution IMHO. RS485 is designed to be driven for both mark and space if you want nice clean edges at any modest speed, either that or your bias resistors become very low values.

serial-rs485.txt documents how RS485 is supported through the Linux kernel. Some devices have a way of enabling it via device tree, but I don't believe the Pi UART is one of them.
Most of it is offloaded into the serial core instead of being done in the driver itself.

Having said that, USB RS485 interfaces do seem to be reliable and less hassle under all circumstances I've tried them. Be a little careful on your device selection as there were some issues with the CH340/CH341 based UARTs a while back which I can't remember if they've been resolved.

[moksha29]

Is there any code through which I can read data on UART of raspberry pi from MAX485 or any library support?

Am unable to fetch the data.


https://drive.google.com/open?id=1c2Pbf ... juMIrDbi-l

[danjperron]

Is there any code through which I can read data on UART of raspberry pi from MAX485 or any library support?

What protocol are you using?

If it is modbus there is minimalmodbus.

Like I explain above the serial driver from the Pi has problem to control the max485 direction.

If you want to stick with a max485 I.C. ,

1 - Use the TX pin to enable the direction. You will need a delay and set it to ~ 12 * baud rate. Use a 555 timer. the TX pin connect to the trigger of the 555 and the output from the 555 connect to the RE and DE of the max485.

2 - Use my design with a small pic12F1840. It does the same thing and you could program it using the PI.

With the delay you don't have to worry about the max485 direction. it is done by hardware.

[moksha29]

So am trying to established communication between my two boards(ie. one board ethernet port is connected to another board ethernet port) one as a transmitter and other as a receiver. Following code am using:

Write.py:
import time
import serial
ser = serial.Serial(
port='/dev/ttyAMA0',
baudrate = 9600,
parity=serial.PARITY_NONE,
stopbits=serial.STOPBITS_ONE,
bytesize=serial.EIGHTBITS,
timeout=1
)
counter=0
while 1:
ser.write('Write counter: %d \n'%(counter))
time.sleep(1)
counter += 1


Read.py
import time
import serial

ser = serial.Serial(

port='/dev/ttyAMA0',
baudrate = 9600,
parity=serial.PARITY_NONE,
stopbits=serial.STOPBITS_ONE,
bytesize=serial.EIGHTBITS,
timeout=1
)
counter=0
while 1:
x=ser.readline()
print x



But I am not getting any data on a receiver side. Even I tried to read data on USB port but still, no data is available on the serial port.

[danjperron]

(ie. one board ethernet port is connected to another board ethernet port)

ethernet port ??? I thought it was suppose to be RS-485 I.C. converter and in your code you are using the serial interface ????


You example code, one is the receiver and one is the transmitter, if you are using a RS-485 I.C. converter you do nothing with the RE and DE signal.

On your first post you connect DE to GPIO13 but you don't do anything with it. Where is your handshake ???

At least set DE and RE together with GPIO13.

On the transmitter set GPIO13 to 1
On the receiver set GPIO13 to 0


it is possible to handle the RS485 via ioctl with RTS but I tried it and it doesn't work very well.
https://armbedded.taskit.de/node/322

B.T.W. RTS is available on GPIO17.

or you could try pyserial rs485 class ( I never tried it)

Code: Select all

import serial.rs485
ser=serial.rs485.RS485(port='/dev/ttyAMA0',baudrate=9600,timeout=0.1)
ser.rs485_mode = serial.rs485.RS485Settings()
ser.write('a test'.encode('utf-8'))

You must enable the GPIO17 to be RTS

[6by9]

it is possible to handle the RS485 via ioctl with RTS but I tried it and it doesn't work very well.
https://armbedded.taskit.de/node/322

B.T.W. RTS is available on GPIO17.

Out of interest, what about it didn't work?

It's been a good few years since I really played with RS485, and that was under DOS. Many UARTs didn't have a transmit complete interrupt, only transmit buffer empty (ie you can load another byte into the FIFO). Our system would drop RTS on that interrupt, and therefore required you to load an extra byte onto the end of every packet. Other than that, keying RS485 off RTS has always worked for me.

[danjperron]

Out of interest, what about it didn't work?

Speed stuff if the baud rate was too high ~115200 baud I had problem. The delay was way to high and the slave unit start to respond before the DE line was high.


Check my first response on this post. I switch to a cpu to control the line by setting the baudrate with dip switch and eventually I used an usb adapter to rs-485 which already take care of the direction.

[6by9]

Out of interest, what about it didn't work?

Speed stuff if the baud rate was too high ~115200 baud I had problem. The delay was way to high and the slave unit start to respond before the DE line was high.

Check my first response on this post. I switch to an cpu to control the line by setting the baudrate with dip switch and eventually I used an usb adapter to rs-485 which already take care of the direction.

Fair enough - I think the fastest I was going was 38400. I'm surprised there is that much latency in the core, but it depends on exactly how it is detecting the TX register empty, and that varies by UART.
Likewise for a slave to respond that rapidly when RS485 always has these sorts of turnaround time issues is a little strange. We had fibre optic transceivers to worry about, and those were a similar pain in the neck even at low speeds.
Yes there are UARTs out there which include automatic RS485 turnaround (the higher spec versions of the 16550, such as [http://snebulos.mit.edu/projects/voila/ ... adUART.pdf]the 16954[/url]) which are the only truly guaranteed way to get reliable direction control.

[danjperron]

I could confirm that serial.rs485 does work

I use a SP3485 I.C.

The only thing I had to do was to set the GPIO17 to alternate function 3

I use this code from https://github.com/mholling/rpirtscts do enable GPIO17

Code: Select all

git clone https://github.com/mholling/rpirtscts
cd rpirtscts
gcc -o rpirtscts rpirtscts.c
sudo ./rpirtscts on

P.S. You will need to set GPIO17 every time you boot the RPI.

N.B. The settings for DE and RE are inverted so you need to change RS485Settings() to RS485Settings(False,True)

Code: Select all

import serial.rs485
ser=serial.rs485.RS485(port='/dev/ttyAMA0',baudrate=9600)
ser.rs485_mode = serial.rs485.RS485Settings(False,True)
ser.write('a test'.encode('utf-8'))

[moksha29]

@danjperron

Sorry, my mistake!

it's RS485, not ethernet port.

I have connected both DE and RE together on GPIO13.

I have set GPIO13 high while WRITE and low while READ.

[rzusman]

I use RS-485 on the CM3L.

I am using a low baud rate (9,600), so my timing may not be as critical as yours, but I ended up manually controlling the TE input of the RS-485 driver (Enable TE, send data, disable TE). The only way I was able to do that was to put the driver thread to sleep for 10mS, just before I sent the data. When I did that, I got 90+% reliability, which was fine for my application. There is supposed to be a kernel driver with driver-level support of the TE line, but I never found anyone who had used it in modern times, so I just did it from user space.

In my application, the TE line must be released within a few mS of transmitting, or it will garble the data being sent back on the bus.

[danjperron]

HiassofT just publish the overlay for RTS. Maybe you should try it

viewtopic.php?f=107&t=225518#p1384353

[rzusman]

Thanks for the link, and I may experiment with it when I have the time, but I'm not sure it will do what I want.
The RTS/CTS lines are controlled by the buffer state, as I understand it, and are not really what I want , which is a TE signal that is the exact width of one byte, including the start and stop bit. This needs to be done at the hardware level, or at least right before the byte is sent to the UART. The serial driver is supposed to have this capability, but, as I mentioned above it hasn't been tested fro ages.

[danjperron]

using the python pyserial there is some variable to set the dtime before sending

Code: Select all

class rs485.RS485Settings
A class that holds RS485 specific settings which are supported on some platforms.

New in version 3.0.

__init__(rts_level_for_tx=True, rts_level_for_rx=False, loopback=False, delay_before_tx=None, delay_before_rx=None):
Parameters:	
rts_level_for_tx (bool) – RTS level for transmission
rts_level_for_rx (bool) – RTS level for reception
loopback (bool) – When set to True transmitted data is also received.
delay_before_tx (float) – Delay after setting RTS but before transmission starts
delay_before_rx (float) – Delay after transmission ends and resetting RTS