Like I described already here:
the official image is seriously broken. RS232 and RS485 not working.
I am willing to sponsor fixing these issues.
How to, whom ?
I've added support for both versions of the RUT95x board to ath79 this year, use those devices in many places (incl. serial) and haven't had any issues. From the first looks I guess you have chosen the wrong image: there are two incompatible versions of that board, you recognize them by the number of pins of the power connector (2 on the older H7V3C0 variant vs. 4 on the more recent variant). Getting this wrong results on modem, UART, LEDs and many other things being unusable.
Feel free to contact me for assistance.
Thanx for responding.
I am aware about the 2 different versions.
So I asked on Teltonika about this alrady:
As my device is from rather new Batch 084, it should not contain PCA9539, and therefore not be the H7V3C0-variant, as I understand.
Thus, I am building my custom image for simple RUT955.
BTW: I also tried H7V3C0 image on my device, having much more issues.
(Opening the case of my RUT955 seems not possible without causing damage.)
Of course, I also tried the pre-built image for the RUT955, having same issues (kernel tainted).
Actually, for development, I am using the RS232(DB9) for modbus connection, as temp workaround.
May be, you could provide one of your running images for me to try ?
There could be a 3rd variant around right now, as I noticed on Teltonika forum, that about middle of year there were signal problems on the RS485 connection:
You are right about your board being one of the recent versions having the 74HC595 SPI shifter instead of I2C GPIO PCA9539, hence not the variant I (probably wrongly) labeled H7V3C0.
I've recently acquired one more of them, also having "Batch 084" printed on it (it used to be a sticker in earlier versions...). I do not have a scope at hand (my DSO-Quad got stolen recently) to verify the electric properties of the RS485 and haven't ever tried it for more than receiving NMEA-0183 stuff (ie. only having RX of RS-422 hooked).
Feel free to contact me via email (daniel@makrotopia.org) to discuss your use case, I'm willing to work on whatever can be fixed in software and also got some RS-485 Modbus devices (EPEver Tracer-1215BN MPPT solar charge controller) to test with.
Congrats.
Used modbus/RTU on RS485 to the RUT955 via USB-RS485 converter.
Will take some time to try your workaround, though, as we exchanged the RUT955 to another device.
@tophirsch well spotted! I must admit I never tried the RS-485 port, I wrote the driver changes for the ar93xx_uart driver in the kernel looking at the vendor implementation as a reference and it looked like things were working, but the device wasn't actually even near me nor anything connected to the RS485 UART.
Then I finally got hold of the actual device, used it for a few months without encountering any RS-485 capable things to talk with and then the crappy XTX flash chip died after only hundred read/write cycles 
sent it back, got refunded...
Anyway, so long story short: It's very beautiful to hear that RS-485 now actually works! Great job finding the off-by-one in the pinctrl! Please post a patch after making sure that RX and TX both work. The DTR may or may not be needed for half-duplex RS-485, if you have a chance to try, please do 
Sidenote: I was struggling quite a bit to come up with all the pinctrl masks for that device and I'm still not sure if it's actually smart to hook the GPIO level shifter to the hardware SPI bus together with the flash and SDIO or to run only the NOR flash in hardware and software-drive the other two SPI devices... LED blinking frequency wasn't very stable with either option and doing it in hardware at least costs less CPU cycle...
update: push to git. as things were not working before, it can't really get worse and we can just try.
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=53a7d5d614050a38a4e78f5a9e153e7612d587f0
@daniel besides the RS-485 bug it looks like a very good implementation so far. Thanks for that. 
Good to know about the sensitive flash chip. Maybe, if it's possible, I should consider booting from the internal microSD card.
Half-duplex RS-485 is working fine. Maybe in a few days I will get my hands an a second RUT955. Then I will test the full-duplex functionality and let the devices talk to each other. Fingers crossed.
Regarding the spi shift register I just tested the LEDs by switching them on and off. I don't think that a stable blinking frequency is that important, because the hooked up LEDs are only for the cellular signal strength indicator and the system status. So, if this is not causing any issues with the other spi devices, I agree with keeping the shift register connected to the hardware controller.
Many thanks for doing the commit. 
Good to hear that things are working fine!
Unfortunately, booting from SD Card would require replacing the bootloader, as it is it doesn't have mmc-spi driver built with it. An the failing block was within the area used for kernel, so supposedly even moving rootfs to SD Card would not have prevented this. For a moment I thought about just ordering a 32M Winbond chip for $2 (which should last for decades and at least 10000s of cycles)....
Did you test the RS485 on the RUT955 with a real, second device ?
I did a lab setup, to connect the RUT955/RS485 (2 wire) to a USB-RS485 adaptor on my Win PC.
I could see data from the RUT955 coming into my PC, but bad data. Like some problem with the speed/parity/stop-bit settings, which I modified on the RUT955 using stty.
I used various settings, like 38400/E/1, or 9600/N/1, and I could recognize different bad data on my PC. The program on the PC I used before successfully for comms between PCs USB-RS85 and a second RS485-USB on the RUT955, so it should not be an issue.
Yes, I successfully verified the full-duplex communication. Both devices were connected via 4 wires and I was able to send data from one to another via picocom with default settings.
Bridging the driver and receiver ports for half-duplex mode worked also flawlessly using an usb-rs485 dongle.
In both cases there were no corrupted data or something similar.
Did you tried to interchange the A and B port at your usb-rs485 device?
Which software are you using for serial communication on your windows pc? I could recommend HTerm.
- Yes
- mod_RSSim ; besides modbus comms (which I use for serious testing) it can also display hex dump of data.
Thank you for confirmation. So I have to dig further.
It works now. Had to exchange the USB-RS485. Its always the hardware
1 Like