Bidirektionalitaet von RS232 und Handshake

[Michael Schlegel]

Hallo,

ich bin auf folgendes kleineres Problem der guten alten RS232
Schnittstelle gestoßen:
- Verbindung von 2 DEE mit Null-Modem Kabel,
- da ich mit TxD und RxD zwei Leitungen habe müßten beide
DEE gleichzeitig senden und empfangen können, müssen Sie
auch, um bei einer 2-Draht Verbindung das Xon, Xoff
Software-Hanshake machen zu können
- bei 4-Draht Verbindung setzt lt. "Thieser, M.: PC-Schnitt-
stellen. Franzis Verlag" die sendewillige DEE RTS auf 1
was die andere DEE an ihrem CTS sieht und ihrerseits RTS
auf 1 setzt wenn sie empfangsbereit ist, was der Sender
an seinem CTS erkennt und loslegt -> Datenübertragung geht
nur in eine Richtung!

Sehe ich da irgendetwas falsch?

MfG
Michael


--
Michael Schlegel
Faculty of Electrical Engineering and Information Technology
Chemnitz University of Technology, Germany
http://www.tu-chemnitz.de/~micsch

 

[Wolfgang Gerber]

Michael Schlegel schrieb:

ich bin auf folgendes kleineres Problem der guten alten RS232
Schnittstelle gestoßen:

- Verbindung von 2 DEE mit Null-Modem Kabel,

- da ich mit TxD und RxD zwei Leitungen habe müßten beide
DEE gleichzeitig senden und empfangen können, müssen Sie
auch, um bei einer 2-Draht Verbindung das Xon, Xoff
Software-Hanshake machen zu können

ja - die Leitungen müssen gekreuzt angeschlossen sein

TX -> RX
RX <- TX

- bei 4-Draht Verbindung setzt lt. "Thieser, M.: PC-Schnitt-
stellen. Franzis Verlag" die sendewillige DEE RTS auf 1
was die andere DEE an ihrem CTS sieht und ihrerseits RTS
auf 1 setzt wenn sie empfangsbereit ist, was der Sender
an seinem CTS erkennt und loslegt -> Datenübertragung geht
nur in eine Richtung!

ja - die Leitungen müssen gekreut angeschlossen sein

RTS -> CTS
CTS <- RTS

Sehe ich da irgendetwas falsch?

Nö - aber das steht doch wirklich in jeder Grundlagenbeschreibung zur
RS232.

Wo sind also die Probleme auf die du gestossen bist?

BTW: GND <-> GND gehört natürlich auch noch dazu.

Gruss Wolfgang
--
No reply to "From"! - Keine Antworten an das "From"
Keine privaten Mails! Ich lese die NGs, in denen ich schreibe.
Und wenn es doch sein muss, dann muss das Subjekt mit NGANTWORT beginnen.

 

[Klaus P. Pieper]

Wolfgang Gerber wrote:

Michael Schlegel schrieb:

[...]

- bei 4-Draht Verbindung setzt lt. "Thieser, M.: PC-Schnitt-
stellen. Franzis Verlag" die sendewillige DEE RTS auf 1
was die andere DEE an ihrem CTS sieht und ihrerseits RTS
auf 1 setzt wenn sie empfangsbereit ist, was der Sender
an seinem CTS erkennt und loslegt -> Datenübertragung geht
nur in eine Richtung!

ja - die Leitungen müssen gekreut angeschlossen sein

RTS -> CTS
CTS <- RTS

Sehe ich da irgendetwas falsch?

Nö - aber das steht doch wirklich in jeder Grundlagenbeschreibung zur
RS232.

Wo sind also die Probleme auf die du gestossen bist?

Darin, dass im Gegensatz zu der Angabe in dem Buch die sendewillige Station
RTS nicht setzen muss. Allgemein wird hierüber nur gesteuert, dass Daten
empfangen werden können. Für das Handshake reicht das aus, da der Empänger
bestimmt, wann gesendet werden soll.

Wenn eine Station der Gegenstation signalisieren soll, dass sie bereit ist
zu senden, kann man das Paar DTR / DSR dafür nutzen.

Im übrigen: http://www.beyondlogic.org/serial/serial.htm#1

Gruß

Klaus

--
Die email Adresse (reply-to) im header ist ungueltig.
Fuer mail "pub . kp2 . pieper @ ibeq . com" benutzen.
(Leerzeichen loeschen).

Reply-to invalid.
Use "pub . kp2 . pieper @ ibeq . com" (remove spaces).

 

[Wolfgang Gerber]

Klaus P. Pieper schrieb:

Nö - aber das steht doch wirklich in jeder Grundlagenbeschreibung zur
RS232.

Wo sind also die Probleme auf die du gestossen bist?

Darin, dass im Gegensatz zu der Angabe in dem Buch die sendewillige Station
RTS nicht setzen muss.

Richtig. RTS heisst "Request zu send" also die Aufforderung vom
Empfänger an den Sender jetzt zu beginnen.

Allgemein wird hierüber nur gesteuert, dass Daten
empfangen werden können. Für das Handshake reicht das aus, da der Empänger
bestimmt, wann gesendet werden soll.

Es bestimmt daß gesendet werden "kann". Und natürlich dadurch auch
"soll". Üblicherweise ist aber der Sender der aktive Teil welcher
seine Sendebereitschaft bzw. seinen Sendewunsch "zuerst" signalisiert.

Wenn eine Station der Gegenstation signalisieren soll, dass sie bereit ist
zu senden, kann man das Paar DTR / DSR dafür nutzen.

Das musst du nicht "mir" erklären! Ich Arbeite schon 20 Jahre damit.
Ausserdem gibt es keine allgemeingültigen Regeln für das Handshake.
Leider! Das handelt jeder wie er will. Mit den abenteuerlichsten
Varianten der Verknüpfungen bzw. Verwendungen der Statusleitungen.

Und man muss immer unterscheiden wer eigentlich der aktive (z.B. PC)
und der passive Teil (z.B. Messgerät) ist. Wobei auch der Haupt-Sender
(Messgerät) der eigentlich passive Teil sein kann. D.h. er tut nichts
ohne Aufforderung des aktiven Teils (PC). Trotzdem die meiste Arbeit
hat. Nämlich nach einer Sendeaufforderung seinen ganzen Daten
abzuliefern.

Ist alles nur eine Frage der Betrachtungsweise.

Gruss Wolfgang
--
No reply to "From"! - Keine Antworten an das "From"
Keine privaten Mails! Ich lese die NGs, in denen ich schreibe.
Und wenn es doch sein muss, dann muss das Subjekt mit NGANTWORT beginnen.

 

Michael Schlegel <Michael.Schlegel@infotech.tu-chemnitz.de> schrieb:

ich bin auf folgendes kleineres Problem der guten alten RS232
Schnittstelle gestoßen:
- Verbindung von 2 DEE mit Null-Modem Kabel,
- da ich mit TxD und RxD zwei Leitungen habe müßten beide
DEE gleichzeitig senden und empfangen kĂśnnen, mĂźssen Sie
auch, um bei einer 2-Draht Verbindung das Xon, Xoff
Software-Hanshake machen zu kĂśnnen
- bei 4-Draht Verbindung setzt lt. "Thieser, M.: PC-Schnitt-
stellen. Franzis Verlag" die sendewillige DEE RTS auf 1
was die andere DEE an ihrem CTS sieht und ihrerseits RTS
auf 1 setzt wenn sie empfangsbereit ist, was der Sender
an seinem CTS erkennt und loslegt -> DatenĂźbertragung geht
nur in eine Richtung!

Sehe ich da irgendetwas falsch?

Du betrachtest 'CTS' als Antwort auf 'RTS', was der ursprĂźnglichen
Bedeutung der lokalen Senderfreigabe entspricht. Das fĂźhrt bei deinem
Beispiel einer 4-Draht Verbindung zu dem geschilderten Problem. Bei einer
solchen Verbindung ist 'RTS' aber als "Sendeerlaubnis" der
ÂťRemoteÂŤ-Station zu verwenden, dann funktioniert es auch bidirektional.
Das Protokoll ist also entsprechend anzupassen.
--
Das Recht auf Anonymität: http://www.realname-diskussion.info/anonheft.htm
Pseudonym? Aber sicher! http://www.realname-diskussion.info/pseudo.htm
Kein Bock auf blĂśde Anmache?
http://www.realname-diskussion.info/hinweis.htm
Kein Bock auf Spam? http://usenet.noemails.net/email-adressen.html

 

[Michael Schlegel]

Hallo,

erst mal vielen Dank an alle.

Im übrigen: http://www.beyondlogic.org/serial/serial.htm#1

Aber auch hier findet man genau mein Problem:

When the computer wishes to send data it takes active the Request to
Send line. If the modem has room for this data, then the modem will
reply by taking active the Clear to Send line and the computer starts
sending data.

Also genau so wie im OP angegebenen Buch.

.... da waren Sie wieder, meine drei Problem ...



MfG
Michael




--
Michael Schlegel
Faculty of Electrical Engineering and Information Technology
Chemnitz University of Technology, Germany
http://www.tu-chemnitz.de/~micsch

 

[Klaus P. Pieper]

Michael Schlegel wrote:

Hallo,

erst mal vielen Dank an alle.


Im übrigen: http://www.beyondlogic.org/serial/serial.htm#1

Aber auch hier findet man genau mein Problem:

When the computer wishes to send data it takes active the Request to
Send line. If the modem has room for this data, then the modem will
reply by taking active the Clear to Send line and the computer starts
sending data.

Also genau so wie im OP angegebenen Buch.

... da waren Sie wieder, meine drei Problem ...

Nein, das ist nicht ganz vergleichbar. Hier wird die klassische Kombination
von Endgerät mit Modem (DTE mit DCE). *Dabei* hat man dann wirklich ein
Handshake nur in eine Richtung, d.h. der Computer hat ohne weitere Leitungen
keine Möglichkeit, dem Modem mitzuteilen, dass sein Puffer voll ist. In
diesem Fall muss er ohne Handshake alle Daten annehmen und den Puffer eben
schnell genug leeren.

Da bei einem echten Modem die Übertragungsgeschwindigkeit über die Leitung
recht niedrig ist, kann man sich die Rückmeldung, ob der Computer die Daten
auch annehmen kann, allgemein sparen. Immerhin ist dieser Standard
entwickelt worden, als 300 Baud mit Akustik-Kopller noch eine standesgemäße
Geschwindigkeit waren.

Heute ist es aber *üblich*, auf den ersten Teil (also den Sendewunsch über
RTS) zu verzichten und diese Leitung als "Ready-To-Send" zu benutzen. Dabei
wird dann davon ausgegangen, dass immer ein Sendewunsch besteht, der also
nicht extra angekündigt werden muss. Bei der Kombination von Computer /
Moden wird RTS - RTS verbunden und CTS - CTS. Bei zwei Computern nimmt man
das Nullmodem und kreuzt die beiden Kabel.

Also, nimm als Nullmodem

TD --- RD
RD --- TD
SG --- SG
RTS --- CTS
CTS --- RTS
DTR-| |-DTR
DSR-| |-DSR
CD--| |-CD

und benutze RTS bei jeder Seite nur, um der Gegenstation mitzuteilen, dass
jetzt gesendet werden darf.

Wenn Du nun aus irgendweinem Grund den Sendewunsch doch signalisieren
willst, nimm eben zusätzlich das Paar DSR / DTR. Per Konvention wird dies
aber eigentlich dazu benutzt, zu signalisieren, dass das entsprechende Gerät
eingeschaltet und betriebsbereit ist, aber man kann es eben auch als zweites
Handshake-Paar benutzen. Das ist zwar nicht *üblich*, aber möglich.

Gruß

Klaus

--
Die email Adresse (reply-to) im header ist ungueltig.
Fuer mail "pub . kp2 . pieper @ ibeq . com" benutzen.
(Leerzeichen loeschen).

Reply-to invalid.
Use "pub . kp2 . pieper @ ibeq . com" (remove spaces).

 

[Wolfgang Gerber]

Michael Schlegel schrieb:

Aber auch hier findet man genau mein Problem:

When the computer wishes to send data it takes active the Request to
Send line. If the modem has room for this data, then the modem will
reply by taking active the Clear to Send line and the computer starts
sending data.

Also genau so wie im OP angegebenen Buch.

... da waren Sie wieder, meine drei Problem ...

Du machst dir Probleme wo keine sind. Für die RS232 gibt es abgesehen
von den Spannungspegeln keine Normen bezüglich der Hard- und
Softwareprotokolle. Das hält jeder wie er will.

Glaube es mir. Ich habe 20 Jahre Erfahrung damit. Habe u.a. jahrelang
Fremdanpassungen anderer Systeme an die Systeme meiner Firma gemacht.
Europaweit.

Du glaubst gar nicht wie viele Protokollvarianten es gibt. Genauso wie
viele Varianten der Hardwareverschaltung der Steuerleitungen. Die
Liste meiner gesammelten Hardwareadapterschaltungen + Nullmodems hatte
bestimmt über 100 Varianten drin.

Du kannst RTS aus 2 Seiten sehen. Aufforderung an den anderen zu
senden. Oder Mitteilung, daß man senden möchte.

Genauso kann man das DTR/DSR aus 2 Seiten betrachten.

Was genau ist denn dein Problem? Nur das Verstehen? Oder was willst du
verschalten und was geht nicht?

Gruss Wolfgang
--
No reply to "From"! - Keine Antworten an das "From"
Keine privaten Mails! Ich lese die NGs, in denen ich schreibe.
Und wenn es doch sein muss, dann muss das Subjekt mit NGANTWORT beginnen.

 

[Michael Schlegel]

Was genau ist denn dein Problem? Nur das Verstehen? Oder was willst du
verschalten und was geht nicht?

Einfach nur das Verstehen des Handshakes, da es in verschiedenen Quellen

unterschiedlich beschrieben ist.
Vielleicht habe ich auch nur Widersprüche gesehen wo keine sind. Aber
mit dem letzten Posting von Klaus Pieper
fügt sich mein Weltbild zusammen .
Im Prinzip geht es um eine UART für ein FPGA-Projekt. Der 16550 Uart von
Opencores ist zu wuchtig, die
MiniUart nicht wirklich praxistauglich, darum wollte ich es einfach
Richtig machen ...

Du glaubst gar nicht wie viele Protokollvarianten es gibt. Genauso wie
viele Varianten der Hardwareverschaltung der Steuerleitungen. Die
Liste meiner gesammelten Hardwareadapterschaltungen + Nullmodems hatte
bestimmt über 100 Varianten drin.

.... und keine 101 Variante hinzufügen.

Vielen Dank an Klaus, Wolfgang und me_private
Michael


--
Michael Schlegel
Faculty of Electrical Engineering and Information Technology
Chemnitz University of Technology, Germany
http://www.tu-chemnitz.de/~micsch