This post is a part of a series about the TouchBerry ModbusRTU autoflow issue and how have I resolved it. Other posts of the series can be found under the touchberry tag. Note that newer posts might contain more recent information.
It is quite hard to do a lot of effective work in this heat wave, but I have pushed myself to do at least a bare minimum, apart from drinking water and hiding from the sun. Thus continuing the work on enabling the full potential of the TouchBerry 10's RS485 capabilities I have learned a few new things.
To effectively send the data over the RS485 bus, only the DE pin of the UTRS485G chip has to be pulled HIGH. The RE pin should be pulled high in the same time, but it is not strictly required for the transfer. In reality, my Modbus IO device did change the coil state on the controller's request, but could not acknowledge the controller (in this case the TouchBerry) about doing so. Or in other words, with the RE pin HIGH and DE pin in whatever state, the controller sees that the Modbus command timed out, but the command was in fact received and executed by the listening device.
This probably brings us closer to the reason anything I tried related to RTS0 and autoflow did not work. Recalling the relevant bits from the original post:
| RPi pin | GPIO | ALT3 | UTRS485G pin |
|---|---|---|---|
| 11 | 17 | RTS0 | RE |
| 13 | 27 | SD1_DAT3 | DE |
As we can see, this design of the UPS shield is in fact really unfortunate,
as it would probably be better if these two paths were swapped. Having DE
pin attached to RTS0 alternate function could probably make RS485 automatic
direction control (or autoflow in short) work with just a GPIO alternate
function and possibly a stty command, maybe something as simple as could
suffice:
sudo pigs m 17 3
sudo stty -F /dev/ttyS0 crtscts
But the reality leaves us with the GPIO17 tied to RE pin with nothing to automatically drive the DE pin tied to GPIO27. I am really tempted to tie both pins together to test the RTS0 autoflow hypothesis. I could very live with such hack. Especially since the time of the final product where the TouchBerry panel is mounted is nearing, something will have to be done. The repairability of such a product with hacks of course goes down sharply, but on the other hand, prototypes like this are built with hacks most of the time anyway.
RS485 autoflow enabled chip alternative
Another possibility that I considered is to replace the basic UTRS485G chip soldered onto the UPS shield inside the TouchBerry 10 with something more advanced. By some chance I have stumbled upon IO cards from embeddedpi.com. The first featured one, a Half-duplex RS485 one called ISO-485 explains that it boasts a MAX13487. This chip's description states:
Half-Duplex RS-485/RS-422-Compatible Transceiver with AutoDirection Control
Looking at its pins, it is almost entirely pin-to-pin compatible with UTRS485G. The only exception is the pin 3, as SHDN is in place of the DE in MAX13487E. Both chips can be used the same way however. Pulling the RE and SHDN pins HIGH makes the MAX13487E seamlessly transfer and receive data over the bus without requiring any other manual action, provided that the software controls that two participants never speak at the same time. This is of course solved with the client-server relation in Modbus protocol. With UTRS485G, pulling both RE and DE high enables just transferring data down the bus, disabling the receive functionality until both RE and DE pins are pull LOW again.
My local distributor has some MAX13487E in the stock, but for instance Maxim itself has none, with the 20 week lead time! Could chip famine I also written about be the cause?
This is a 93th post of #100daystooffload.