RS232: Handshake

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

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.

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

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

@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