Aus gegebenem Anlass eine sehr konkrete Fragestellung: Welche in Deutschland erhältliche ICs vermögen jeweils eine Protokollumsetzung von einem SPI-Datenfluss auf RS-485 und von UART auf RS-485 ? Hintegrund der Frage Es müssen mehrere Signalflüsse über einen und denselben RS-485 zusammenfließen und an eine SPS weitergegeben werden. Vielen Dank im Voraus, Draco
:
Gesperrt durch User
Die RS-485 ist eine Form der Asynchronen seriellen Schnittstelle wie sie mit der UART realiseirt werden. Da braucht es zur Umsetzung nur einen Wandler für die Pegel - z.B. den MAX485. SPI und RS-485 sind ganz verschiedene Schnittstellen. Dafür braucht man mehr, in der Regel wird das auf einen kleinen µC und einen Treiber für die Pegel hinauslaufen.
Ulrich schrieb: > SPI und RS-485 sind ganz verschiedene Schnittstellen. Dafür braucht man > mehr, in der Regel wird das auf einen kleinen µC und einen Treiber für > die Pegel hinauslaufen. Ok, danke für die Antwort. MAX485 lässt sich denke ich problemlos einbauen. Und mit dem anderen kannst Du mir da weiterhelfen, ob es bereits bewährte Lösungen gibt ?
Draco Malfoy schrieb: > Ulrich schrieb: >> SPI und RS-485 sind ganz verschiedene Schnittstellen. Dafür braucht man >> mehr, in der Regel wird das auf einen kleinen µC und einen Treiber für >> die Pegel hinauslaufen. > > Ok, danke für die Antwort. > MAX485 lässt sich denke ich problemlos einbauen. Und mit dem anderen > kannst Du mir da weiterhelfen, ob es bereits bewährte Lösungen gibt ? Da wird es keine käufliche Lösung geben denn RS485 und SPI lassen sich nicht ohne weiteres miteinander koppeln. RS485 arbeitet asynchron mit festgelegter Taktrate. SPI arbeitet synchron mit beliebiger Taktrate und benötigt deshalb 2 Drähte für die gleichzeitige Übertragung von Takt- und Datensignal.
nochmal, und was ist mit MAX 3140 ? Ich verstehe es nicht ganz. Die Sache ist doch die, wir übertragen nicht protokolle sondern Daten. D.h. es muss möglich sein, aus einem Protokoll die betreffende Datenmenge zu extrahieren und in das jeweils andere Protokoll zu verpacken. Warum soll das nicht gehen, man müsste nur SPI-seitig die Taktrate und die Übertragungsgeschwindigkeit vorgeben, sodaß der Datenaustausch genau so schnell wie auf dem 485 Bus stattfindet, oder ? Und was ist mit Chips wie MAX3110E, die sind doch genau dafür gedacht ? Was heißt hier geht nicht "ohne weiteres" ? Dann geht es halt "mit Weiteres". Irgendwie muss es doch möglich sein Irgendwo muss es doch bereits erfolgte technologiische Lösungen in dieser Richtung sein, oder bin weit und breit der Einzige seit über 20 Jahren seit es diesen Bus gibt, der ein solches Problem lösen will
Draco Malfoy schrieb: > Und was ist mit Chips wie MAX3110E, die sind doch genau dafür gedacht ? Das ist ein Pegelwandler - kein Protokollwandler. Für Dein Problem gibt es keine Ein-Chip-Lösung. Welche Stückzahl steht denn bei Dir an?
der MAX3140 ist im Prinzip nix Anderes als n µC mit 485-Pebgelwandler dahinter ... braucht auch nen Quarz, Terminierung etc. kost dafür aber als Einzelstück mal grob € 6,31 interessantes Teil, ist mir bislang noch nicht untergekommen ... Also wenn es darum geht nur Bytes nacheinander über die Zweidrahtleitung zu bekommen geht der schon ... wenn da aber einmal ne Uart und mal der SPI auf den gleichen Bus geht, dann wird das schwierig am anderen Ende herauszufiltern von welcher Schnittstelle nun die eingehenden Daten kommen. Eine Möglichkeit wär die via Parity zu kennzeichnen. Z.B. UART sendet mit gerader Parität, SPI mit ungerader, dann kann der Empfänger die Bytes auseinanderhalten ...
Dieter Werner schrieb: >> Ok, danke für die Antwort. >> MAX485 lässt sich denke ich problemlos einbauen. Und mit dem anderen >> kannst Du mir da weiterhelfen, ob es bereits bewährte Lösungen gibt ? > > Da wird es keine käufliche Lösung geben denn RS485 und SPI lassen sich > nicht ohne weiteres miteinander koppeln. > > RS485 arbeitet asynchron mit festgelegter Taktrate. > > SPI arbeitet synchron mit beliebiger Taktrate und benötigt deshalb 2 > Drähte für die gleichzeitige Übertragung von Takt- und Datensignal. Lass das bloß nicht NXP hören. Die haben so viele von den Chips, die müssen die verkaufen. Schau her: www.nxp.com/documents/data_sheet/SC16IS740_750_760.pdf "The SC16IS740/750/760 is a slave I2C-bus/SPI interface to a single-channel high performance UART. It offers data rates up to 5 Mbit/s and guarantees low operating and sleeping current. The SC16IS750 and SC16IS760 also provide the application with 8 additional programmable I/O pins. The device comes in very small HVQFN24, TSSOP24 (SC16IS750/760) and TSSOP16 (SC16IS740) packages, which makes it ideally suitable for handheld, battery operated applications. This family of products enables seamless protocol conversion from I2C-bus or SPI to and RS-232/RS-485 and are fully bidirectional." fchk
Fhutdhb Ufzjjuz schrieb: > der MAX3140 ist im Prinzip nix Anderes als n µC mit 485-Pebgelwandler > dahinter Nö. Das ist eine UART mit integriertem RS485-Treibern, die wiederum via SPI von einem µC angesteuert werden kann. Das hilft "Draco" bei seinem Problem überhaupt nicht. Draco muss verstehen lernen, daß nicht alles, wo "RS485" draufsteht, mit der gleichnamig beschrifteten Schnittstelle seiner SPS verbunden werden kann, sondern daß das nur mit Geräten geht, die das gleiche Protokoll sprechen wie seine SPS. RS485 ist hier nur das Transportmedium, aber eben nicht das Protokoll. Zwei Leute, die miteinander telephonieren, benötigen nicht nur ein kompatibles Transportmedium (eben die Telephone), sondern auch ein kompatibles Protokoll -- eben die Sprache, die sie sprechen.
Rufus Τ. Firefly schrieb: > Draco muss verstehen lernen, daß nicht alles, wo "RS485" draufsteht, mit > der gleichnamig beschrifteten Schnittstelle seiner SPS verbunden werden > kann, sondern daß das nur mit Geräten geht, die das gleiche Protokoll > sprechen wie seine SPS. > > RS485 ist hier nur das Transportmedium, aber eben nicht das Protokoll. Ok, in dem Fall - hilf mir bitte, herauszufinden, welches Protokoll meine SPS spricht (Typ: VisioLogic 350-35-TR34) bzw. mehr noch, wie ich ein Protokoll meiner Wahl zur Datenübertragung dort implementieren kann. Ich bin derzeit massiv beängstigt von dem recht eingeschränkten Funktionsumfang dieser SPS und frage mich, ob die von mir deklarierte hiermit Aufgabenstellung überhaupt erreichbar ist.
Draco Malfoy schrieb: > Ok, in dem Fall - hilf mir bitte, herauszufinden, welches Protokoll > meine SPS spricht 5 Sekunden Google: > Communication options include TCP/IP Ethernet, GSM/SMS, > MODBUS and CANopen networking plus remote access for > data acquisition and program download. Modbus also.
Ist es realistisch, da was zu deichseln, was meinen Anforderungen entspricht ? Klingt eigentlich nicht sonderlich hoffnungsvoll, weil MODBUS ja ein industrieller Standard mit komplett anderem Verwendungsprofil wie SPI ist
Ich schließe diesen Thread hier mal, die Diskussion muss nicht doppelt geführt werden. Beitrag "USB-Host industrielle SPS Frequency Counter"
Thread beobachten
Seitenaufteilung abschalten