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.

I've spent past few days fighting two things: heat wave and a no-autoflow TouchBerry 10 - part 1 and part 2. Today, after a slew of experiments and a few read forums and articles later, I decided to order the MAX12487 - a half-duplex RS485 IC with the autoflow baked in, to replace the UTRS485G that requires manual direction control, making most MdobusRTU hard utilities and libraries hard/impossible to use.

Problems with RTS

The GPIO17 can be configured into RTS mode via ALT3 function (RTS0 to be specific). No matter what I tried, I could not make RTS pin to do anything on the scope automatically during the transmission. Many sources point to the fact, that this feat is complicated. The sources that claim how to do it, sometimes do not specify the Raspberry Pi model or they omit if they use /dev/ttyS0 called mini-uart or if they use the serial under /dev/ttyAMA0. Some kind of dtoverlay work is probably necessary. Even if I could make the RTS work, there are still problems with this proposal.

The first problem is that as I have already outlined in previous articles, the RE pin on the UTRS485G is supposedly connected to the GPIO17 on the TouchBerry 10 and we actually need the DE pin, that is connected to GPIO27. Inspecting the UTRS485G IC itself on the UPS shield PCB however shows that RE and DE pins are clearly connected together, as they should be, creating doubts about the support I have gotten from IndustrialShields. So even if the RTS worked, it would be automatically switching the wrong pin. Pulling GPIO27 HIGH makes transmission seamless. Most definitely this pin itsefs is controlling both DE and RE on the UTRS485G. To be sure, I have ordered SV-SOIC8 test clip along with some IDC 40 clips to extend the Raspberry 40 pin header via cables, as the UTRS485G is on the bottom of the UPS shield, not reachable via clips when the shield is actually inserted into Raspberry. I was considering the Pomona POM-5250 which is quite a well-known clip piece but my local dealer had it twice the price of the former one. Hopefully this decision turn out fine. It is better to have at least some SO8 clips, than not to have any when an urgent EEPROM flash is required.

The second problem is as bad, maybe worse as the first. As I have later found out, the RTS pin has an inverted polarity, meaning it stays HIGH and goes LOW during the transmission. Fail. Close to almost impossible to change just in software itself.

Reasons for choosing MAX13487E

There are numerous people around claiming the MAX13487E is a good choice for ModbusRTU applications. There is a slight distinction in pin functionality and have made a deeper analysis in the part 2, but they are generally pin-to-pin compatible with most other RS485 half-duplex ICs in SO8 package, including UTRS485G. The biggest problem when replacing components like these is the voltage levels, but again, these two parts are both 5V, so no problems. The conversion to 3.3V for Raspberry UART levels is already done on the UPS board.

The choice of UTRS485G is strange. For instance, there is a review comment for SparkFun Transceiver Breakout - RS-485 which uses another obscure part, the SP3485 IC. User #499376 then states:

I would not have purchased this board. Why? Because the obscure SP3485 chip that it uses does not have automatic flow control and is therefore not compatible with many popular open source libraries for RS485 and in particular Modbus RTU.

Unfortunately there don't seem to be a lot of other choices except certain parts in online auctions and building one's own board with MAX488, MAX13487E or another flow-control transceiver.

This user basically confirms what I have learned the hard way here. Then there are people claiming full or at least partial success with MAX13487E on the Electronics StackExchange. Another positive references can be found here and here.

Next steps

The fun could also present itself as a random email response from the IndustrialShields about how to do it properly in software, but since I have tried so many things, my hopes for this scenario are quite low to be honest. Hopefully autoflow will work when the ICs are replaced and I will be able to use ModbusRTU on TouchBerry 10 without more time spent on the issue.

This is a 95th post of #100daystooffload.