Electronic – Can a 485 network work if the DE (driver enable) pin of the transceiver is always on

beaglebone blackrs485

We are using a Beaglebone Black with the Osso Cape (https://github.com/nexlab/Osso) for comunicating with other equipment using a 485 connection and Modbus RTU.

The driver enable (DE) pin of the cape's DS485 chip is tied to the GPIO 2_24, while the RO and DI pins were tied to the UART1 RX and TX respectively.

We haven't write any code to act on the GPIO2_24 at all, other than a cape overlay that sets it as output and pin Mode GPIO.

We were troubleshooting some communication problems when we noticed something strange: Using an oscilloscope, we saw that the driver enable (DE) pin was always high, but somehow the Beaglebone was able to normally send requests and receive correctly responses from the other equipement.

Normally I would expect that the 485 comms only worked with the DE pin HIGH when transmitting and LOW when finished, to avoid driving the bus when other equipment respond.

In other capes we used, this was controlled using UART4 RTS, but I could not explain why it seems to work in this case.

Is there any explanation on why it works with the DE always on?

EDIT: The datasheet (http://www.ti.com/lit/ds/symlink/ds485.pdf) says:

Due to the multipoint nature of the bus, contention between drivers may occur. This will not cause damage to the
drivers since they feature short-circuit protection and also thermal shutdown protection. Thermal shutdown
senses die temperature and puts the driver outputs into TRI-STATE if a fault condition occurs that causes
excessive power dissipation which can elevate the junction temperature to +150°C.

Maybe the chip senses contention and goes to high-impedance state, then being able to receive the response from the other equipment?

Best Answer

It is quite possible that the state with the driver always on would allow communications to work in both directions due to the overall current limit and effective output impedance of the driver.

You do want to correct this however because the driver in this condition will be under unnecessary stress and drawing way more current from your power sources than necessary. A stressed driver chip may very well have a shortened life. The correction of course is to devise the programming necessary to drive the GPIO to turn off the driver once transmission is complete.

Turning off the driver at the correct time can, in some cases, require some careful work. Due to the fact that the sending UART port will spend time sending the last loaded data bytes after the final data is loaded there is a need to comprehend when sending is complete. Some considerations...

Some UARTs are capable of generating an interrupt when the actual serial data pipe plus any FIFO buffered data has been sent. This can be leveraged as the time to turn off the UART.
If there is no actual UART EMPTY indicator then you may need to use a time delay in the software to get to the time when to turn off the driver. This could be a timer interrupt delay or an inline software delay.
In practical applications of RS485 interfaces it is often the best practice to assign one device as the master initiator of transaction packets on the interface. All other devices are then slave responder devices. It is a good idea for a slave responder device to delay a bit from receiving a transaction packet till sending the start of its response packet. This delay allows time for the master initiator to get off the bus before the slave tries to send. Likewise the master should delay between receipt of a response packet and start of sending the next initiator packet to allow the slave device to get back off the bus.

Related Solutions

Electronic – Running CAN bus with RS-485 transceiver

It can probably be made to work, although I wouldn't call it a "production solution"!

One thing you'll need to do is invert the DEN signal as CAN is low-dominant, not high-dominant.

You'll also need to adjust the termination as although both CAN and RS485 are designed to be terminated by a single 120ohm resistor at each end of the bus, the additional bias resistors that RS485 usually includes will pull the bus lines to voltages slightly "either side of the centre-point", whereas CAN needs to idle recessive at ~2.5V on both lines.

IIRC, there is about 0.5V of differential voltage allowed before a dominant bit is detected.

Electronic – BeagleBone Black CAN bus setup

There is concept called device tree overlay and you can think of it as request for specific pin setup on the device itself.

Some pins on the board are by default dedicated for specific purpose, SPI or I2C or just general purpose but some like CAN need to be defined to be used and that's the thing we need to do.

Folder /lib/firmware contains list of pre-configured binary overlay files which could be loaded and that would setup specific list of pins for specific purpose.

At the beginning those file are defined as source file which are regular text file with some specific syntax but in the moment we want to use them we need to compile them with dtc command.This is the reason why we have dts extension for the source and dtbo for binary.

So the process for CAN goes as follows:

Inside /lib/firmware create file BB-DCAN1-00A0.dts :

/dts-v1/;
/plugin/;

/ {
    compatible = "ti,beaglebone", "ti,beaglebone-black";

    /* identification */
    part-number = "dcan1pinmux";

    fragment@0 {
        target = <&am33xx_pinmux>;
        __overlay__ {
            dcan1_pins_s0: dcan1_pins_s0 {
                pinctrl-single,pins = <
                    0x180 0x12  /* d_can1_tx, SLEWCTRL_FAST | INPUT_PULLUP | MODE2 */
                    0x184 0x32  /* d_can1_rx, SLEWCTRL_FAST | RECV_ENABLE | INPUT_PULLUP | MODE2 */
                >;
            };
        };
    };

    fragment@1 {
        target = <&dcan1>;
        __overlay__ {
             #address-cells = <1>;
             #size-cells = <0>;

             status = "okay";
             pinctrl-names = "default";
             pinctrl-0 = <&dcan1_pins_s0>;
        };
    };
};

Now it is needed to create overlay binary with the following command in the same directory:

root@host:/lib/firmware# dtc -O dtb -o BB-DCAN1-00A0.dtbo -b 0 -@ BB-DCAN1-00A0.dts

Finally execute:

 root@host:/lib/firmware#echo BB-DCAN1 > /sys/devices/bone_capemgr.*/slots

Now load kernel modules:

root@host# modprobe can
root@host# modprobe can-dev
root@host# modprobe can-raw

Build can tools:

root@host# svn co svn://svn.berlios.de/socketcan/trunk
root@host# cd trunk/can-utils/
root@host# make

Setup bus speed:

root@host# ip link set can0 up type can bitrate 500000
root@host# ifconfig can0 up

Best Answer

Related Solutions

Electronic – Running CAN bus with RS-485 transceiver

Electronic – BeagleBone Black CAN bus setup

Related Topic