www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik RS485 galvanisch trennen


Autor: Stephan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen

Einige werden jetzt denken, schon wieder das alte Thema.

Meine Frage ist jedoch, kann ich eine RS485 nicht auch mit einem 
Übertrager galvanisch trennen, also das differentielle Signal einfach 
auf den Übertrager und das wars (natürlich beim Sender und Empfänger)?
Wenn ich mich recht erinnere wird dies bei Ethernet doch auch so 
gemacht.

Geht dies, oder nicht bzw was spricht dafür bzw dagegen?

Vielen dank im voraus.
MfG Stephan

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Stephan (Gast)

>Wenn ich mich recht erinnere wird dies bei Ethernet doch auch so
>gemacht.

Ja, aber

>Geht dies, oder nicht bzw was spricht dafür bzw dagegen?

Das geht nur, wenn dein Leuitungscode gleichspannungsfrei ist. Also 
Manchester (10M Ethernet), oder 4B5B (100M Ethernet) oder 8B10B (GB 
Ethernet). Einfaches RS232 ist NICHT gleichspannungs.

MFg
Falk

Autor: Stephan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen

@Falk

Das heißt, wenn ich meine zu versendenden Daten entsprechend codiere 
(Manchester, 4B5B, ...) und dann in meinen UART schiebe, RS485 Baustein, 
Übertrager und auf der anderen Seite das gleiche Spiel sollte dies doch 
funktionieren.
Oder habe ich dies falsch verstanden?

MfG Stephan

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Stephan (Gast)

>Das heißt, wenn ich meine zu versendenden Daten entsprechend codiere
>(Manchester, 4B5B, ...) und dann in meinen UART schiebe, RS485 Baustein,
>Übertrager und auf der anderen Seite das gleiche Spiel sollte dies doch
>funktionieren.

Eigentlich schon.

MFg
Falk

Autor: Gast4 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist es nicht so, dass ein fester Pegel anliegt, wenn gar nichts kommt?
Das waere dann pure Gleichspannung.

Gast4

Autor: der mechatroniker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Das heißt, wenn ich meine zu versendenden Daten entsprechend codiere
> (Manchester, 4B5B, ...) und dann in meinen UART schiebe, RS485 Baustein,
> Übertrager und auf der anderen Seite das gleiche Spiel sollte dies doch
> funktionieren.

Es gibt fertige Bauteine zur galvanischen Trennung, die machen im 
Prinzip genau das, z.B. die ADuM12xx von Analog (siehe Prinzipschaltbild 
im Datenblatt).

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stephan schrieb:
> Hallo zusammen
>
> @Falk
>
> Das heißt, wenn ich meine zu versendenden Daten entsprechend codiere
> (Manchester, 4B5B, ...) und dann in meinen UART schiebe, RS485 Baustein,
> Übertrager und auf der anderen Seite das gleiche Spiel sollte dies doch
> funktionieren.
> Oder habe ich dies falsch verstanden?

Hallo Stephan,

völlig falsch. Die Gleichspannungsfreiheit per Manchester muss am 
TxD-Ausgang des UARTs gegeben sein, nicht beim Laden der Daten. 
Prinzipiell ist das bei asynchroner Übertragung garnicht möglich, weil 
bei asynchron in den Pausen eine konstante 1 gesendet wird. Manchester 
lässt sich daher nur bei synchroner Übertragung aktivieren.

Du könntest also synchron arbeiten, wenn die Hardware das zulässt, ist 
aber beim PC normalerweise nicht der Fall.

Es gibt ICs, die den ausgehenden Datenstrom mit höherer Frequenz 
zerhacken und dann übertragen, aber die sind teurer als Optokoppler.

Gruss Reinhard

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Reinhard Kern (Firma: RK elektronik GmbH) (rk-elektronik)

>völlig falsch. Die Gleichspannungsfreiheit per Manchester muss am
>TxD-Ausgang des UARTs gegeben sein, nicht beim Laden der Daten.

Ja, wird aber praktisch dennoch funktionieren. Sei es über eine Päambel 
zunm einpegeln des Mittelwerts oder wie auch immer.

>Manchester lässt sich daher nur bei synchroner Übertragung aktivieren.

Stimmt nicht. Manchester hat mit synchron (mit Takt) oder asynchron 
(ohne Takt) gar nichts zu tun. Vor allem, weil Manchestercode bei 
synchroner Übertragung relativ sinnlos wäre.

MFG
Falk

Autor: R. Max (rmax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner schrieb:

> Vor allem, weil Manchestercode bei
> synchroner Übertragung relativ sinnlos wäre.

Es scheint mir eher so zu sein, daß Manchester typisch für synchrone 
Übertragung und bei asynchroner zwar nicht sinnlos aber doch unüblich 
ist, denn normalerweise braucht man hier keine seiner beiden 
Eigenschaften: Taktrückgewinnung findet nicht statt und 
Gleichspannungsfrei ist man eh nicht.

Bei synchroner Übertragung muß man nochmal unterscheiden zwisch "mit 
Taktleitung" und "mit Taktrückgewinnung aus dem Datensignal". Für 
letzteres ist Manchester einer der möglichen Leitungscodes. Aber selbst 
bei einer Übertragung mit Taktleitung kann Manchester sinnvoll sein, 
wenn sie gleichspannungsfrei sein muß.

Ich verweise auf die Wikipedia-Artikel zu "Synchrone_Datenübertragung", 
"Leitungscode" und "Manchester-Code".

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Reinhard Max (rmax)

>Es scheint mir eher so zu sein, daß Manchester typisch für synchrone
>Übertragung

Beispiel?

>und bei asynchroner zwar nicht sinnlos aber doch unüblich
>ist, denn normalerweise braucht man hier keine seiner beiden
>Eigenschaften: Taktrückgewinnung findet nicht statt und
>Gleichspannungsfrei ist man eh nicht.

Eben!

>Bei synchroner Übertragung muß man nochmal unterscheiden zwisch "mit
>Taktleitung" und "mit Taktrückgewinnung aus dem Datensignal".

Nöö, zweiteres wäre ja asynchron ala RS232!

>bei einer Übertragung mit Taktleitung kann Manchester sinnvoll sein,
>wenn sie gleichspannungsfrei sein muß.

Beispiel einer praktischen Anwendung?

>Ich verweise auf die Wikipedia-Artikel zu "Synchrone_Datenübertragung",
>"Leitungscode" und "Manchester-Code".

Na dann stell doch gleich die Links hier rein.

Der "Artikel" "Synchrone_Datenübertragung" ist schlicht falsch. Da 
werden diverse Sachen vermischt. Sendepausen gibts auch bei synchroner 
Übertragung, z.B. SPI.

MfG
Falk

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner schrieb:
>>Bei synchroner Übertragung muß man nochmal unterscheiden zwisch "mit
>>Taktleitung" und "mit Taktrückgewinnung aus dem Datensignal".
>
> Nöö, zweiteres wäre ja asynchron ala RS232!
>

Du solltest dich wirklich mal mit den Grundlagen von asynchron und 
synchron befassen, dann würdest du hier nicht solchen Unsinn verzapfen. 
Da steht z.B. laut und deutlich  drin, dass für die Taktrückgewinnung 
genügend Flanken vorhanden sein müssen und daher ab einer bestimmten 
Anzahl Nullen oder Einsen künstlich ein Logikwechsel eingeführt wird - 
wenn das für dich asynchron ist, hast du dir wohl die Definitionen 
selbst ausgedacht, mit der bekannten Technik hat das nichts zu tun. 
Vielleicht hast du ja auch einfach synchron und asynchron geistig 
vertauscht, dann machen deine Äusserungen immer noch etwas mehr Sinn als 
so.

Das Niveau hier im Forum ist oft erstaunlich hoch, aber manchmal finden 
auch Sturzflüge in unbekannte Tiefen statt.

Gruss Reinhard

Autor: R. Max (rmax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner schrieb:
> @  Reinhard Max (rmax)
>
>>Es scheint mir eher so zu sein, daß Manchester typisch für synchrone
>>Übertragung
>
> Beispiel?

Schau' Dir das Beispiel in http://de.wikipedia.org/wiki/Manchester-Code 
an. Siehst Du da irgendwo die für eine asynchrone (UART) Üertragung 
üblichen Start- und Stopbits?

>>und bei asynchroner zwar nicht sinnlos aber doch unüblich
>>ist, denn normalerweise braucht man hier keine seiner beiden
>>Eigenschaften: Taktrückgewinnung findet nicht statt und
>>Gleichspannungsfrei ist man eh nicht.
>
>Eben!

OK, wenn der Manchester-Code also nach Deiner Aussage von weiter oben 
bei synchroner Übertragung sinnlos ist und Du mir hier zustimmst, daß 
man ihn für asynchrone Übertragung eigentlich nicht braucht, wofür 
braucht man ihn dann überhaupt?

>>Bei synchroner Übertragung muß man nochmal unterscheiden zwisch "mit
>>Taktleitung" und "mit Taktrückgewinnung aus dem Datensignal".
>
> Nöö, zweiteres wäre ja asynchron ala RS232!

Falsch. Asynchron ist, wenn beide Seiten unabhängige Taktquellen haben, 
synchron ist, wenn eine Seite den Bit-Takt (und nicht nur die 
Wortgrenzen wie bei RS232) von der anderen Seite bezieht. Ob das per 
separater Leitung oder durch eine entsprechende Leitungscodierung 
geschieht, ist unerheblich. Beispiele für synchrone Datenübertragung 
ohne Taktleitung sind ISDN und DSL.

>>bei einer Übertragung mit Taktleitung kann Manchester sinnvoll sein,
>>wenn sie gleichspannungsfrei sein muß.
>
> Beispiel einer praktischen Anwendung?

Ob das irgendwo praktisch angewendet wird, weiß ich nicht, aber wenn 
sowohl Takt- als auch Datenleitung per Übertrager galvanisch getrennt 
werden sollen (um mal wieder halbwegs zum Thread-Thema zurückzukehren), 
kann man Manchester nehmen, um die Leitung gleichspannungsfrei zu halten 
(auch wenn es in dem Fall wahrscheinlch bessere Möglichkeiten gibt).

> Der "Artikel" "Synchrone_Datenübertragung" ist schlicht falsch. Da
> werden diverse Sachen vermischt. Sendepausen gibts auch bei synchroner
> Übertragung, z.B. SPI.

Falsch würde ich nicht sagen, aber vielleicht etwas ungenau. Der 
entscheidende Unterschied ist eben, ob der Empfänger seinen Bit-Takt mit 
dem Sender synchronisiert wie bei ISDN und Ethernet oder gar seinen Takt 
direkt vom Sender bezieht wie bei I²C und SPI, oder ob die Takte von 
Sender und Empfänger eben asyncron laufen und von sich aus genau genug 
sein müssen, damit die Übertragung klappt.

Autor: Seppl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Denke mal über die galvanische Trennung zwischen TxD-Ausgang bzw. 
RxD-Eingang des Uart (oder was auch immer) und dem RS485-Treiber nach. 
Der RS485-Treiber muß dann natürlich über einen DC-DC-Wandler oder eine 
galvanisch getrennte Versorgung betrieben werden.

Diese Lösung habe ich schon mehrfach angewendet, etwas aufwändig, 
funktioniert aber prima.

Gruß

Seppl

Autor: Joachim R. (bastelbaer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da schliess ich mich seppl an. Das Ganze ist z.B. bei dem DMX-Interface 
[[http://www.digital-enlightenment.de/usbdmx.htm]] per Optokoppler, 
DC/DC-Wandler und RS485-TTL-Wandler realisert und läuft super.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Reinhard Kern (Firma: RK elektronik GmbH) (rk-elektronik)

>Du solltest dich wirklich mal mit den Grundlagen von asynchron und
>synchron befassen,

Hab ich gemacht, vor langer Zeit im Studium der Kommunikationstechnik.

> dann würdest du hier nicht solchen Unsinn verzapfen.

Das sagt der Richtige ;-)

>Da steht z.B. laut und deutlich  drin, dass für die Taktrückgewinnung
>genügend Flanken vorhanden sein müssen und daher ab einer bestimmten
>Anzahl Nullen oder Einsen künstlich ein Logikwechsel eingeführt wird -

Ja und? Hat das einer bestritten?

>wenn das für dich asynchron ist, hast du dir wohl die Definitionen
>selbst ausgedacht, mit der bekannten Technik hat das nichts zu tun.

Wer lesen kann ist klar im Vorteil. Lies meine Postings nochmal.

>Vielleicht hast du ja auch einfach synchron und asynchron geistig
>vertauscht,

Nö.

>Das Niveau hier im Forum ist oft erstaunlich hoch, aber manchmal finden
>auch Sturzflüge in unbekannte Tiefen statt.

Literaturtip, nur für dich.

http://de.wikipedia.org/wiki/Arroganz

@ Reinhard Max (rmax)

>Schau' Dir das Beispiel in http://de.wikipedia.org/wiki/Manchester-Code
>an. Siehst Du da irgendwo die für eine asynchrone (UART) Üertragung
>üblichen Start- und Stopbits?

Was führt dich zu der irrigen Annhame, asynchrone Übertragung muss 
Start- und Stopbits haben? Nur weil RS232 seit über 40 Jahren exitiert 
und hier in jedem 3. Posting durchgekaut wird, heisst das noch lange 
nicht, dass es die ultimative Definition einer asynchronen Kommunikation 
ist.

>OK, wenn der Manchester-Code also nach Deiner Aussage von weiter oben
>bei synchroner Übertragung sinnlos ist und Du mir hier zustimmst, daß
>man ihn für asynchrone Übertragung eigentlich nicht braucht,

Auch du hast eine Leseschwäche. Wo stimme ich dir hier zu?
Du hast eher synchron und asynchron in deiner Aussage verwechselt.

"Es scheint mir eher so zu sein, daß Manchester typisch für synchrone
Übertragung und bei asynchroner zwar nicht sinnlos aber doch unüblich
ist, denn normalerweise braucht man hier keine seiner beiden
Eigenschaften: Taktrückgewinnung findet nicht statt und
Gleichspannungsfrei ist man eh nicht."

>braucht man ihn dann überhaupt?

Hää?
Für asynchrone Kommunikation zur a) Taktrückgewinnung und b) 
Gleichstromfreiheit, damit es per Übertrager oder Kondensator gekoppelt 
werden kann. Siehe Ethernet, ISDN, whatever.

>Falsch. Asynchron ist, wenn beide Seiten unabhängige Taktquellen haben,
>synchron ist, wenn eine Seite den Bit-Takt (und nicht nur die
>Wortgrenzen wie bei RS232) von der anderen Seite bezieht.

Ja.

> Beispiele für synchrone Datenübertragung
>ohne Taktleitung sind ISDN und DSL.

Jain. Der Begriff asynchron/synchron wird nun mal vielschichtig 
verwendet. Auf Bit-, Bytes und Blockebene. Da reden wir teilweise 
aneinander vorbei.

>> Beispiel einer praktischen Anwendung?

>Ob das irgendwo praktisch angewendet wird, weiß ich nicht,

Das war aber meine Frage ;-)

> aber wenn
>sowohl Takt- als auch Datenleitung per Übertrager galvanisch getrennt
>werden sollen (um mal wieder halbwegs zum Thread-Thema zurückzukehren),
>kann man Manchester nehmen, um die Leitung gleichspannungsfrei zu halten

Hat keiner bestritten.

>(auch wenn es in dem Fall wahrscheinlch bessere Möglichkeiten gibt).

Eben.

>Falsch würde ich nicht sagen, aber vielleicht etwas ungenau. Der
>entscheidende Unterschied ist eben, ob der Empfänger seinen Bit-Takt mit
>dem Sender synchronisiert wie bei ISDN und Ethernet oder gar seinen Takt
>direkt vom Sender bezieht wie bei I²C und SPI, oder ob die Takte von
>Sender und Empfänger eben asyncron laufen und von sich aus genau genug
>sein müssen, damit die Übertragung klappt.

Nein, synchronisieren muss der Empfänger IMMER! Auch bei RS232. Dass es 
dabei verschiedene Mechanismen gibt ist eine andere Frage.

MFG
Falk

Autor: Thilo M. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab's so realisiert, bin zufrieden damit.
Was hinten dranhängt is' ja egal, ob MAX232 oder RS485.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thilo M. schrieb:

> Ich hab's so realisiert, bin zufrieden damit.

Wieso hast du 6N139 verwendet, statt der hier naheliegenden 6N137?

Was ist der Sinn von Q1,Q2? Das können die Koppler doch selbst 
übernehmen.

Autor: Thilo M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der 6N139 hat nur 1.6mA Iforward an den Sendedioden, entlastet den 
Sender etwas.
Q1 und Q2 deshalb, weil die Flanken durch die optische Kopplung 
verschliffen werden, deshalb wäre die Baudrate sehr begrenzt. Mit den 
übersteuerten Transistoren kommt hinten ein sauberer Rechteck 'raus (das 
Datenblatt empfiehlt sogar Logikgatter).

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner schrieb:
> Wer lesen kann ist klar im Vorteil. Lies meine Postings nochmal.

Hab ich:
Zitat:
>Bei synchroner Übertragung muß man nochmal unterscheiden zwisch "mit
>Taktleitung" und "mit Taktrückgewinnung aus dem Datensignal".

Nöö, zweiteres wäre ja asynchron ala RS232!
Zitat Ende

Das ist eine glasklare Behauptung:

Synchron mit Taktrückgewinnung = asynchron ala RS232

nur leider völlig absurd.

Auf diesem unterirdischen Niveau gibt es keinerlei 
Verständigungsmöglichkeit.

Reinhard

Autor: STK500-Besitzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wo gewinnt man denn bei RS232 den (Bit-)Takt zurück?
Wenn der Sender eine andere Baudrate verwendet als der Empfänger, dann 
gewinnt man einen Blumenkohl oder Hyroglyphen, erkennt aber keine 
sinnvollen Daten.
Bei Manchester wird der Empfänger durch die Präambel auf den Sender 
synchronisiert. Der Sender muss eigentlich nur die Taktrate für eine 
Übertragung konstant halten. Bei der nächsten, kann er eine andere 
Taktrate wählen.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  STK500-Besitzer (Gast)

>Wo gewinnt man denn bei RS232 den (Bit-)Takt zurück?

Mit der fallenden Flanke des Startbits. Und implizit während der 
Übertragung eines Bytes aus dem notwendigen, kleinen Frequenzfehler. OK, 
kann man sich streiten.

>Bei Manchester wird der Empfänger durch die Präambel auf den Sender
>synchronisiert.

Auch, aber nicht nur. Während des weiteren Datenempfangs muss im 
Allgemeinen fortlaufend der lokale Oszillator nachgeführt werden, sonst 
läuft die Phase  bei langen Datenpaketen weg. Stichwort PLL.

> Der Sender muss eigentlich nur die Taktrate für eine
>Übertragung konstant halten.

Jaja, wenns nur so einfacvh wäre wie man es hier sich bunt ausmalt.
Stichwort Phasendrift zwischen Sender und Empfänger.

> Bei der nächsten, kann er eine andere Taktrate wählen.

Klar, und wo wird sowas gemacht? So ziemlich niergends.

MfG
Falk

Autor: STK500-Besitzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Klar, und wo wird sowas gemacht? So ziemlich niergends.

Kann... muss aber nicht...

Autor: Zefix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schöne Grüße von R.V.L. Hartley, ihr habt beide recht ...
Das ist das schöne an nicht genormten Definitionen jeder Depp
kann irgend was rein interpretieren! In diesem Sinne ...

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.