www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik RS232: Handshake


Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

wie funktioniert das Handshake, wenn sowohl Hard- als auch
Software-Handshake aktiviert sind? Ist es dann egal, welche
Handshake-Art das Sperren/Freigeben der Kommunikation übernimmt, oder
müssen sie nacheinander ausgeführt werden? Und wenn ja, in welcher
Reihenfolge?

Thx

Ralf

Autor: Klaus F. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wohl schwierige Frage, welche genauerer Spezifikation des Systems,
Prozessors etc. erfordert. Sonst weiss man nicht recht, worum sich das
Problem dreht.

Autor: Christoph Kessler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zitat aus einer alten "mc": Zur Inbetriebnahme einer seriellen
Schnittstelle benötigt man einen Lötkolben und ein Oszilloskop"
 es geht NIE so wie man es erwartet, da jeder Hersteller die Norm
anders auslegt.
Handshake bei einer richtigen Schnittstelle, wie dem Druckerport, heißt
ja, für jedes Byte gibts ein Strobe/Acknowledge/Busy. Nicht so beim
seriellen Port. Handshake über eine der vielen Handshakeleitungen
RTS/CTS DSR/DTR , welche auch immer,  heißt nur "Halt warte mal, bin
noch beschäftigt", d.h. es kommt nur irgendwann während der
Übertragung mal so ein Signal oder auch nicht, genau wie der ACK/NACK
Softwarehandshake.

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Okay, mal sehen, hoffentlich bringe ich es verständlich rüber:

Ich will eine Sammlung an Funktionen für die serielle Schnittstelle
erstellen. Betrieben natürlich auf einem Microcontroller, sowohl 8052
inkl. Derivaten als auch AVR.

Der Umfang der Sammlung soll möglichst jeden denkbaren Bereich
abdecken, also z.B. Parität, Handshake, Multiprozessor-Kommunikation
usw.

Es geht hierbei aber nur um die Kommunikation auf unterster Ebene, also
nur die Übertragung an sich, keine Konvertierungen, Daten-Protokolle
oder ähnliches.

Für das Handshake ist, wie Cristoph Kessler bereits sagte, die Funktion
"warte mal, mein Buffer ist voll" meiner Meinung nach völlig
ausreichend, für was anderes kann man das aus meiner Sicht auch gar
nicht verwenden.

Mit der Sammlung will ich erreichen, dass man sich bei der
Programmierung späterer Programme nicht mit der Implementierung solcher
Sachen aufhalten muss.

Wenn man das ganze geschickt programmiert, lässt es sich in eine
Bibliothek packen, die man hier vielleicht sogar in die Code-Sammlung
stellen kann, natürlich Open-Source.

----

Und wenn ich schon dabei bin, hier mal ein Vorschlag:
Wer hat Interesse daran, in Zusammenarbeit solche Sammlungen zu
erstellen, auch für andere Anwendungen (I2C, Displays, usw.)?

Die Code-Sammlung dieses Forums strotzt zum Teil leider von
unausgegorenem Code, zu dem im Gegensatz zum eigentlichen Sinn einer
Code-Sammlung dann leider auch noch Fragen gestellt werden. Vielleicht
sollte man da auch mal aufräumen, aber das ist eine andere
Geschichte... Aber ich denke, es macht Sinn, mal wirklich eine
ordentliche Sammlung auf die Beine zu stellen, mit der auch jeder was
anfangen kann.

Ralf

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenige Bausteine implementieren den Hardware-Handshake wirklich in
Hardware, d.h. senden nicht wenn die Gegenseite blockiert. Aber wenn
dem so ist, dann wär's schon besser, wenn sich beide Seiten über die
Art des Handshakes einig sind, denn sonst wird ja auch die Übertragung
vom XOFF per Hardware blockiert und die andere Leitung säuft ab.

Anders gesagt: Wenn HW- und SW-Handshakes in beide Richtungen in jeder
Kombination funktionieren sollen, dann muss XOFF auch über eine
eigentlich blockierte Leitung übertragbar sein (und der Empfänger muss
auch bei vollem Puffer darauf reagieren).

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@A.K.

Mhm... Stimmt. Ich denke das läuft in der Reihenfolge so ab:

Buffer voll:

1. Xoff senden
2. CTS deaktivieren

Buffer wieder frei:

1. CTS aktivieren
2. Xon senden

Anders kann ich es mir nicht vorstellen... Was meint ihr?

Ralf

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.