• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Driver for RS485 (netPI)


We are currently testing the netPI (NIOT-E-NPI3-51-EN-RE) and the expansion module NIOT-E-NPIX-RS485. After installing of Raspbian and the terminal program(Minicom), we encountered a problem when it comes to communication using the RS485 expansion module.

You have to switch a GPIO-Pin to either send or receive via the RS485 interface, as mentioned in the Thread: "https://forum.hilscher.com/Thread-niot-e-npi3-51-en-RS485-Industrial-Ethernet" by Armin@netPI from April-12th-2019, 07:19 PM

On this site "https://www.netiot.shop/epages/es767660.sf/de_DE/?ObjectPath=/Shops/es767660/Products/1322.011" the product description states that "full-duplex oepration is possible".

According to the block circuit diagramm on page 21 of the hardware description "https://www.netiot.com/fileadmin/user_upload/netIOT/netMAKER/netPI/documents/netPI_Erweiterungsmodule_HW_04_DE.pdf" full-duplex is not possible, because there are only two wires. Even half-duplex is difficult to achieve because it requires its own switching driver which manages whether you want to send or recieve using the RS485 module. And I did not find such a driver after some research.

Now here is my question: Is there a such a driver for the serial port to work with standard programs? If there is none, the system would not be usable for us in its current state.



Wir testen zurzeit den netPI (NIOT-E-NPI3-51-EN-RE) und dem Erweiterungsmodul NIOT-E-NPIX-RS485, nach Installation von Raspbian und eines Terminalprogramms(Minicom) sind wir auf ein Problem gestoßen, wenn es zum Thema Kommunikation kommt.
Man muss einen GPIO-Pin umschalten, um über die RS485-Schnittstelle entweder Senden oder Empfangen zu können, laut Forumthread:
Eintrag von "Armin@netPI" am April-12th-2019, 07:19 PM
Auf dieser Seite "https://www.netiot.shop/epages/es767660.sf/de_DE/?ObjectPath=/Shops/es767660/Products/1322.011" in der Produktbeschreibung ist zu lesen, dass "Vollduplex-Betrieb möglich" sei.
Laut Blockschaltbild auf Seite 21 der Hardware-Beschreibung "https://www.netiot.com/fileadmin/user_upload/netIOT/netMAKER/netPI/documents/netPI_Erweiterungsmodule_HW_04_DE.pdf" ist Voll-Duplex nicht möglich da es nur zwei Drähte gibt. Auch Halb-Duplex ist schwer realisierbar, da dafür eine eigene Umschaltvorrichtung/ein eigener Treiber nötig ist, die/der zeitgesteuert immer hin und her schaltet oder die die Signale räumlich voneinander trennt. Und so eine Umschaltvorrichtung/so einen Treiber habe ich nach einiger Recherche nicht gefunden. 
Nun meine Frage: Gibt es einen Treiber, damit die serielle Schnittstelle mit "standard" Programmen funktioniert. Ansonsten wäre das System für uns im derzeitigen Zustand nicht benutzbar.

Hello Lukas,

this indeed a typo in the link you referenced: https://www.netiot.shop/epages/es767660....s/1322.011.

An RS-485 interface alone can never ever be full-duplex. There is always just a single transmitter that is able to drive the RS-485 bus while all the others a listening. For me it seems that this text was copied 1:1 from the RS-232 module where full duplex is indeed supported. I will let this change today. I am sorry for this inconvenience.

A full duplex version would be indeed a pair of RS-485 interfaces usually named as RS-422 which we don't offer.

You analysed the RS-485 quite well and you looked to the schematics also. And there is indeed a pin that is switching the bus driver between transmit and receive mode and this pin needs to be controlled by the application. So today the only chance you have is to pull the GPIO before sending and to release it after sending. In the example we provided here https://github.com/HilscherAutomation/ne...npix-rs485 as a container we did that using a Node-RED application that takes control of the pin.

I agree that if you don't have any chance to intervene the serial stream and to take control of the GPIO, you can't get your application running since "nobody" is switching between transmit and receive mode. I also agree that in this case a driver is necessary. Just let me re-check the development team what they can do for us to provide such a driver.

I will be back to you.
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

Hello Lukas,

the Raspberry's "mini UART (UART1)" the RS485 module is connected to supports the function "AUTO_RTS". So in best case it should work like it is stated here: https://www.kksystems.com/rtscontrol. This means in turn the RTS signal should be asserted automatically when the "mini UART" is sending. It is de-asserted when the UART is finished sending. This would be exactly the function you need.

I am testing right now to start my local NPIX-RS485 module with BCM17 configured to no longer to work as SW controllable GPIO signal but as RTS signal instead and then to initialized the /dev/ttyS0 configured with parameter AUTO_RTS. If everything is fine then there is no need any longer to control RTS manually by software.

I keep you informed
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

Hello Lukas,

we have investigated your point and examined the BCM UART1 registers in-deep as stated yesterday in the post. To cut a long story short: the AUTO_RTS behaviour is not like we need it and we have no soltution.

When enabling the AUTO_RTS function the chip asserts indeed the RTS signal automatically (as we would need it) when you start sending BUT it does not de-assert it after sending is finished. The signal remains asserted and lets the RS-485 driver remain in transmit mode forever. For real RS-485 circuits when using the two additional signals RTS/CTS this behaviour is ok, cause then the RTS signal is de-asserted when the remote partner starts to send and fills the receive data queue ... but for the RS-485 circuitry as we use it today this is a no go.

The next things we looked at in detail were the other UART1 registers and search for a possibility to detect - with a special driver to be developed - when the transmit shift register is sending our the very last bit of a data stream to use it as a trigger to de-assert the RTS chip in the driver , in an interrupt routine for example. But unfortunately there is not any register in BCM CPU where such a bit or indication exists. So this was also a dead end here.

So neither the AUTO_RTS is usable for us nor a special driver that could do this handling in software instead of the hardware. I am sorry to say that we have no solution for you at this time. I agree that the handling of the RS485 interface is difficult if you have no possibility to change the program that uses the serial port for your use case

You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

Hello Lukas,

I have maybe promising news for you.

In the current NPIX-RS485 circuitry we are using the RS-485 bus driver SN65ALS176D from Texas Instruments that needs the TX/RX mode switch makeing you a problem. From company MAXIM there is a pin compatible bus driver available named MAX13488E that does not need this mode switch. It features the AutoDirection control function that detects wether or not the BCM CPU is sending or not automatically.

We ordered some samples of this bus driver right now and will replace the SN type with MAX type as soon as we receive them and will perform some tests. If it passes in principle we need to redo the overall product tests and will then be changing the bill of material of NPIX-RS485 and will bring out a revision no.2.

I will keep you informed.
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)


Forum Jump:

Users browsing this thread: 1 Guest(s)