RS485 issue on Linux

Dear everybody,

I'm working on a device running Linux embedded. The device owns a serial port which can act as RS485 half-duplex or RS485 full-duplex. The port SUB-D connector has two wires dedicated to the half-duplex communication and four wires dedicated to full-duplex communication. Using the standars POSIX API routines I'm able to communicate over the port using the full-duplex mode because using an oscilloscope I'm able to see the sent and received packets over the four wires.

How can I setup the port to run in RS485 mode ? Do I have to change some port settings in my software, change some settings in Linux config files or use another /dev/tty driver file ?

Best Regards

/Alessandro

Reply to
alessandro.strazzero
Loading thread data ...

Hello, I am not so familiar with Linux, but may be, i can give some hints regarding RS485 / RS422:

First, RS485 is allways half duplex. Full Duplex version is RS422. When you run RS485, your system has to switch from send to receive mode. Some adapters do this via a timeout function, if you don´t send anything, it acts as a receiver, when the tx line goes active, it switches to transmit mode...

best regards

Stefan

Reply to
Stefan

Standard motherboard serial ports don't do RS485. You'll need to buy an adapter or a serial board that does do RS485.

If you do have a serial board that does RS485, you'll have to consult the manual for the serial interface board you're using. The method used to switch from RS232 to R485 is vendor-specific.

Reply to
Grant Edwards

No, it isn't. If you use two RS485 transceivers on each end (one as a transmitter, one as a receiver), then you can do 4-wire, full-duplex (it's actually rather common).

It two-wire, half-duplex mode, that's true.

Reply to
Grant Edwards

We did some work on an R485/RS422 last year. But our UART hardware is in an FPGA (it emulates a 16550). With one additional register bit controlling RS422/RS485 mode. Via IOCTL from userland the UART driver switches the hardware in RS422 or RS485 mode. In the RS485 mode the UART hardware activates the output driver itself, if one sends data and switches off the output driver if the data is sent.

Maybe your UART driver and hardware do it in a similar way?

jbe

Reply to
Juergen Beisert

As i understood, RS485 is allways a two-wire connection with optional ground-wire. RS422 is similar and for full duplex connections.

Both can be realised as a bus-system with maximum of 32 devices on a bus, but you can also get tranceivers for maximum of 128 devices (not really usefull). Transceivers are e.g. MAX485. For a RS422 system, you need two MAX485 for each device on the bus, for RS485 one tranceiver per device.

You often find commercial adaptors from RS485/422 to RS232 or to Ethernet. The adaptors can work as RS485 or as RS4222 devices. Normaly, one pair of wires are uses for RS485 which can be switched from transmit to receive mode. The other wire pair is for receive (or transmit) only.

Example for RS485 to ethernetconverter is MOXA NPORT 5230

best regards

Stefan

Reply to
Stefan

On Sat, 28 Nov 2009 20:07:30 +0100, Stefan rearranged some electrons to say:

When properly implemented per the EIA spec, both RS-485 and RS-422 are differential, i.e. there is a twisted pair of wires for TX data and a pair for RX data.

Reply to
david

I don´t have the original EIA documents, so i can only talk about practical use.

Yes, RS-485 and RS-422 are both differential. Therefore, you have 2 wires for a rs-485 connection. One siganl is marked as A the other as B, or RX/TX+ and the other as RX/TX-. In RS422, you have 4 wires, one pair for TX+/TX- and one pair for RX+/RX-.

Therefore, this has nothing to do whith the question, if RS485 is a two wire or four wire connection.

The point is, that in such a 2 wire system, both wires are are the same time for transmission if the MAX4855 driver is switched to transmit mode and both wires are used for receive when the MAX485 is switched to receive mode.

So, the 2 wire system can only work in half-duplex mode.

Simply spoken: A = B*, or RX+ = RX-* and TX+ = TX-* so you get the original signal at the first wire and the inverted signal on the other wire. The receiver takes the result from the difference Uab.

The idea is, that if there is an electromagnetic influence on the signal, it will affect both wires in the same way, so the difference voltage is not affected. In practice, this advantage is useless because in most cases, you find faulty electrical installations, so that most RS485/RS422 Busses with more than 10 devices don´t work properly, especially when the lenght of the bus is several hundred meters.

I myself prefer the old TTY-current loop, which has worked perfectly over several 1000 meters since nearly 100 years. No idea, why anybody decided to invent such a shit like RS232.

Best regards

Stefan DF9BI

Reply to
Stefan

If you're using two RS-485 transceivers on each device, then I call that a 4-wire RS-485 connection. A 4-wire bus where there is one master (tx on one pair) and multple slaves (tx on the other pair) has been referred to as 4-wire RS-485 everwhere I've ever worked.

In my experience, RS-422 is a 4-wire point-point connection between exactly two peers using RS-422 tranceivers.

Though RS485 and RS422 transceivers are interoperable, the electrical specs for RS485 and RS422 are not the same.

--
Grant
Reply to
Grant Edwards

On Sat, 28 Nov 2009 21:12:10 +0100, Stefan rearranged some electrons to say:

Using RS485 in differential full duplex mode is not "useless". We implemented an RS485 network utilized in undersea equipment that communicated over long distances successfully. It is resistant to common mode interference.

Reply to
david

Some clear information is available in the below link -

formatting link

Karthik Balaguru

Reply to
karthikbalaguru

Juergen Beisert schrieb:

We did this similar, but the problem was, that switching between send and receive proved to be sometimes too slow. This resulted in lost answers (other side responded before the direction control had completed). Now we are using a direction control from the device driver which works fine. Dirk

Reply to
Dirk Zabel

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.