• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Driver for RS485 (netPI)
#1
Question 
Englisch/English

Hello,

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.

Deutsch/German:

Hallo!

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:
"https://forum.hilscher.com/Thread-niot-e-npi3-51-en-RS485-Industrial-Ethernet"
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.



  Reply
#2
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.
Thx
Armin
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#3
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)

  Reply
#4
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

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

  Reply
#5
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.
Armin
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#6
Hello Lukas,

we have qualified the bus driver MAX13488E meanwhile. It is working like expected. And indeed it does not need any switching between TX/RX mode and does it all automatically. With the last bit sent, the module is able to receive data and hence your existing software can remain untouched while also the minimum possible data response latency time can be reched.

The point is now the following. Before a new revision of hardware can be series released we need to redo the EMC burst test with long cables again while the new bus driver is in use. The test is scheduled in three weeks. After having passed the tests we will be producing revision 2 of this module.

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

  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  NIOT-E-NPIX-RS485 LucioFiam 6 3,986 January-21st-2023, 05:20 PM
Last Post: Armin@netPI
  USB to RS485 convetrer MGharat 5 7,659 November-15th-2021, 02:37 PM
Last Post: patribenq
  netX linux driver Irina Grinberg 4 3,467 May-7th-2020, 01:33 PM
Last Post: Armin@netPI
  niot-e-npi3-51-en (RS485 <-> Industrial Ethernet) merklethomas 6 4,724 April-26th-2019, 01:38 PM
Last Post: Armin@netPI
  [SOLVED] Usage of overlay driver adeeljsid 4 3,785 October-18th-2018, 10:13 AM
Last Post: Armin@netPI

Forum Jump:


Users browsing this thread: 1 Guest(s)