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
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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.