Support for native RS485 for TCP-Serial-Bridge

[TomsTek]

Overview

Add support for using MAX485 or equivalent to use TCP serial bridge with RS485 networks.

(It is an equivalent function as Modbus Bridge. (xdrv_63_modbus_bridge.ino, TasmotaModbus.cpp))

I tested the functionality of my ESP32 board with the following changes.

Tasmota version: 13.4.0 (tasmota32) (self-compiled version)

However, I'm not sure if I can implement the feature correctly in the project, so I need help.

First step: Add pin definition GPIO_TCP_TX_EN

Changes in be_gpio_defines.h

Added lines
“
{ "TCP_TX_EN", (int32_t) GPIO_TCP_TX_EN },
“

I'm not sure if it's necessary to add a line in tasmota_template_legacy.h

Changes in tasmota_template.h

Added lines

  GPIO_TCP_TX_EN,                       // TCP to serial bridge

Added lines

  AGPIO(GPIO_TCP_TX_EN),                   // TCP Serial bridge

Changes in lv_gpio_enum.h

Added lines

TCP_TX_EN = GPIO_TCP_TX_EN

The pin selector worked but has no text. So there must be an error there.

second Step: add RS485 DE-Pin functionality

Changes in xdrv_41_tcp_bridge.ino

Added lines

    if (PinUsed(GPIO_TCP_TX_EN)) {
      TCPSerial->setTransmitEnablePin(Pin(GPIO_TCP_TX_EN));
      AddLog(LOG_LEVEL_DEBUG, PSTR(D_LOG_TCP "TCP Bridge DE is used on Pin: %d"), Pin(GPIO_TCP_TX_EN));
    }

The log line is optional

Thank you in advance for support in implementing the functionality.

[s-hadinger]

Leave it to me. Thanks

[TomsTek]

Is it an idea to make RS485 (controll Driver Enable Pin) available with Berry?

[barbudor]

The C++ class TasmotaSerial on which Berry's serial class is built upon has a member setTransmitEnablePin to define the GPIO used for that. It is for exemple used in the Tasmota ModBus driver.

It should be fairly simple to extend the Berry's serial class to either

• add a serial.setTransmitEnablePin() member mapped to the C++ equivalent
• add an optional argument to the serial() contructor for that enable pin and do the call on object creation

What do you think @s-hadinger ?

[s-hadinger]

Sure, I prefer an additional method to serial class, like in C++

[s-hadinger]

It's merged, see #21269

[TomsTek]

Thanks!
I try to test it this week.

[TomsTek]

Last weekend I tested the TCP Serial Bridge with ESP32 and ESP8266 and it worked well.

Thanks for the implementation.

[jpmorrison]

Good feature to have. How does it compare to newer 485 modules that do this in hardware? It saves a GPIO and works with a PZEM energy meter. MAX13487 has a built in state machine/direction control - I haven't tested, could be fake or mislabelled MAX3485 (3.3V).

[TomsTek]

The MAX13487 really exists. Here is the data sheet from Maxim Integrated (now part of Analog Devices):
https://www.analog.com/media/en/technical-documentation/data-sheets/MAX13487E-MAX13488E.pdf

Most RS485 driver circuits that only use the two UART lines (Rx, Tx) have some kind of limitation. Only the microcontroller itself really knows whether it wants to send or receive.
Some circuits work with logic gates and timing elements to generate the information for the DE pin. The time depends on the baud rate, which you then need to know approximately. If that fits, it works too.

The MAX13487 works internally with a short time element. For this reason it is necessary that the bus lines have correct pullups and pulldowns. This is the only way to ensure that the bus has valid levels when it is not transmitting.
In addition, it always requires a 5V power supply and is an expensive RS485 driver.

Regardless, this is a fascinating piece that I didn't know about before. Thanks for the information. And I think it's good to have the choice.

[TomsTek]

The THVD1406/THVD1426 solves the supply problem (3.3 to 5 V) and is cheaper than MAX13487.
https://www.ti.com/product/de-de/THVD1406

[jpmorrison]

I saw the datasheet - I was just skeptical about the MAX13487 pcb modules on Aliexpress.
If they are real, the price difference for a finished board is negligible and includes TVS diodes.
If they are fake, maybe you lose $1?