RS485 half duplex chip MAX485 with ESP32

[liudr]

I'm trying to use MAX 485 on ESP32 to talk to devices on RS485 running MODBUS. I've done this with full-duplex chips such as MAX491 or half-duplex chips MAX 485 with ATMEGA. I'm reading the serial object doc and according to the doc, the serial.flush() will wait until all data are sent. On the other hand, serial.txdone() may still have one last unsent byte when it returns True.

https://docs.micropython.org/en/latest/library/machine.UART.html#machine.UART.flush

I'm just checking to see if calling serial.flush() is the right way to do:

1. Enable transmit
2. Send data to MAX 485
3. Call serial.flush()
4. Disable transmit

I'm a bit hung up the txdone() having last byte unsent issue because I recall ATMEGA328 has a txdone interrupt that indicates ALL bytes done, including the last byte in the shift register.

Thanks.

[liudr]

After re-reading the doc, and interpreting the "esp8266" as "both esp32 and esp8266", I concluded that I must add a short delay after serial.flush() returns and before disabling transmit in order to not garble my message. I added a 5ms delay with time.sleep(0.005) but can't help thinking that this could block the sensor from sending immediate responses to esp32. So I wonder if there is any better way, such as interrupts, to implement a proper half-duplex RS-485 protocol. Sounds like it should have been supported since there's so many RS-485 sensors.

[liudr]

The sensor's response time is a bit tricky. I know that time.sleep() isn't an accurate way to way. So I wonder if I should keep transmit enabled always so I use the received message to determine whether all bytes have been sent out. Then disable transmit.

[robert-hh]

I had implemented the flush feature. From my tests it looked well on ESP32. See the screen shot below. Channel 1 is set to 1 before writing 10 bytes, and reset after flush() had finished.

from machine import UART, Pin
import time

u=UART(1, 9600, tx=4, rx=5)
p=Pin(15, Pin.OUT, value=0)

def flush(n=5):
    p(1)
    u.write("z"*n)
    u.flush()
    p(0)

[liudr]

Thank you for your response! Does this mean that p(1) then u.write() takes a whole millisecond to do? I see a 1ms delay between the two? I will test a bit more on my end.

[robert-hh]

I noticed it before as a habit of the ESP-IDF driver for UART waiting a little bit after a call to write before shifting out data. i do no know the reason. It's always about a ms, independent of the speed. There is no delay in the MicroPython code. If I add another pin toggle after the return from u.write(), the figure is a below. So it seems that the call to u.write() takes ~1ms.

[liudr]

OK I finally found some time to look at the waveforms. I removed the delay between serial.flush() and DE(0). It seems that the output was disabled after about 40-50us of the end of the stop bit on my scope, which is pretty good. Again, thanks for taking the time to show me what you see on your analyzer.