Proper way to control RS485 half-duplex DE and RE pins - ESP32

[liudr]

I wonder if there is a proper way to drive the DE and RE pins of an RS485 half-duplex transceiver like MAX485 with ESP32 micropython. I've read that for an atmega328 for instance there is a TX complete interrupt that is designed to help with half-duplex so when the TX buffer and shift register are both clear, this interrupt calls the service routine to disable DE and enable RE. So on ESP32 specifically, are there any way to do a similar thing? The heuristic way would be waiting some fixed amount of time in micropython before disabling DE and enabling RE. But, since micropython is not necessarily that fast, and I'm expected to have 115200 baud rate, I don't like the wait method. The delay between the other device receiving my command and issuing a response is not well defined because I want to support multiple brands of RS485 devices.

I have a few full-duplex RS485 devices that I used with a MAX490 full-duplex transceiver and ESP32. That worked. I might be able to wire them to run at half duplex. I also have a sensor with half-duplex that I could use for tests.

[liudr]

What I have found on the internet as "RS485 solutions" are:

1. simplex mode where one device only transmits and the other only receives
2. Using software serial library of Arduino IDE so I guess the write() call only returns when done. The code that calls write() toggles DE/RE before and after the softwareserial.write().
3. Heuristic wait on both parties on RS485

[karfas]

I have no idea what the DE and RE pins are supposed to do.
Normally, a RS485 transmitter is switched on/off using the RTS signal.

"The proper way" would be to use the ESP32/ESP-IDF half-duplex mode (see https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/peripherals/uart.html). There is a UART_MODE_RS485_HALF_DUPLEX.
This is in the moment not supported by micropython.

You could try to wait in micropython for UART.txdone() or try to enable RTS flow control.
Either way, you will need to test this with your large baudrates.

[robert-hh]

The DE and RE pins switch the direction of the transceiver chip. Usually, one of the is inverted, such that you can control both with a single signal. And it must be used.

[liudr]

I didn't know that the RTS signal switches on/off transmitter. That particular ESP-IDF reference glosses over whether RTS is hardware driven in the rs485 half duplex mode. I found a more detailed description here:

https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/peripherals/uart.html#overview-of-rs485-specific-communication-options

The ESP32 UART controllers themselves do not support half-duplex communication as they cannot provide automatic control of the RTS pin connected to the ~RE/DE input of RS485 bus driver. However, half-duplex communication can be achieved via software control of the RTS pin by the UART driver. This can be enabled by selecting the UART_MODE_RS485_HALF_DUPLEX mode when calling uart_set_mode().

So I think it comes down to how much micropython supports this device-specific function of set_mode(), whether micropython ESP32 installs the uart driver, because RTS is only controlled in the uart driver, not by hardware (unfortunately).

So if I use UART.txdone(), I don't know how it's written, whether it waits for all buffered data and the last byte in the shift register to be cleared or just waiting for buffer to be cleared. Any idea?

[karfas]

So I think it comes down to how much micropython supports this device-specific function of set_mode(), whether micropython ESP32 installs the uart driver, because RTS is only controlled in the uart driver

There is no way to use micropython on the ESP32 without the UART driver from ESP-IDF.
In current ports/esp32/machine_uart.c there is no sight of RS485, therefore no support for UART_MODE_RS485_HALF_DUPLEX.

I already wrote this, isn't it ?

So if I use UART.txdone(), I don't know how it's written, whether it waits for all buffered data and the last byte in the shift register to be cleared or just waiting for buffer to be cleared. Any idea?

If you want to know "how it's written", you should use the source[ , Luke :-) ]. But who cares if it works as documented ?

uart.txdone() or uart.flush() were invented exactly for this use case (wait until the last character is sent out). See e.g. https://forum.micropython.org/viewtopic.php?f=2&t=12923 .
The drawback is that polling+reacting upon txdone(), flush() or whatever requires a few python statements,
This is most likely slower than the ESP-IDF RS485 mode, but might be sufficient (depending upon the reaction time of your RS485 devices).

[robert-hh]

For ESP32, txdone() reports True, when all bytes have been sent, and uart.flush() also waits until all data was sent. In the screenshot below, the signal in channel 1 is a GPIO pin being set before calling uart.write() and uart.flush(), and reset after uart.flush() terminated.

[liudr]

Thank you @robert-hh ! This looks great! So uart.flush() traps until all bytes are sent, correct?

DE.value(1)
uart.write('Hello!')
uart.flush()
DE.value(0)

[robert-hh]

That's right. uart.flush() does not return until all bytes have been sent. There is a timeout as fallback to avoid permanent blocking, but that is huge, like 2 times the time it requires to send a full UART transmit buffer, which by default is 256 bytes.

[liudr]

Thank you!

[liudr]

Just got time to whip up a max485 and tested a bit. Seems to work. It seems that this .flush() feature is only available in the nightly build 1.19.x versions (unstable). The most recent stable version 1.19.1 doesn't have it (checked it and it didn't exist). So is there any projection when a stable version will be released? Thanks.

BTW, I've been using 1.17 from 2019 and its .mpy isn't recognized by 1.19. I guess I have to think hard what to do with already deployed units. Maybe only support RS485 on new units?

[liudr]

Here is a table of .mpy file compatibility:

https://docs.micropython.org/en/latest/reference/mpyfiles.html#versioning-and-compatibility-of-mpy-files

I see that 1.19 has mpy version 6 while mine is mpy-cross 1.16 has version 5. I can upgrade mpy-cross 1.16 python module to current but then I won't be able to compile for my 1.17 mpy system. Is there any smart way to have more than one version of mpy-cross installed on my system? Do I have to mess with python virtual environment?