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
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