nur wo Klemmt es. Ich mein.
Terminalprogramm Problem ist sehr wahrscheinlich.
Aber eventuell hängt es daran das wir für den Software Handshake Was im Protokoll vergessen haben was dieses erst überhabt aktiviert oder sowas.
Oder Werden die Steuerzeichen immer noch irgendwie falsch gesendet das sie nicht Interpretiert werden.
Mit anderen Betriebssystemen zu testen finde ich jetzt gar nicht so schlecht. Gibt zumindest hinweise ob es ein OS-BUG ist oder eher an Programm und oder Terminalprogramm Liegt.
----------------------- Nachtrag ------------------------
hab noch ein weiteres Teminalprogramm gefunden. moserial macht auch nen ganz guten eindruck.
Serialport ist eingestellt auf:
Gerät: /dev/ttyUSB0
Bautrate: 9600
DatenBits: 8
Stopbits: 1
Parität: None
Handshake: Software
Zugifsmudus: Read and Write
Lokales Echo: AUS
Erstmal bis hier her richtig???
Oben kann ich verfolgen das ich nach dem Verbindungsaufbau kontinuierlich 0x11 XON empfange.
nach dem Senden eines Befehls z.B.: "G0 X10000" erhalte ich 0x13 XOFF. und das delay lauft. nach ablauf erhalte ich dann nach der Ausgabe wieder 0X11. Soweit scheint es zu laufen.
Sende ich zwei Befehle schnell Hintereinander über die Eingabezeile werden diese sofort gesendet und nicht auf 0x13 reagiert. OK. kann an dem manuellen Senden liegen.
Nun will ich eine Datei Senden. Nach dem ich die Datei ausgewählt habe erhalte ich die meldung: "Warte auf Gegenstelle".
Oben kann ich sehen das weiterhin 0x11 XON entgangen wird.
das Heist doch das wir im Übertragungsprotokoll irgendwas vergessen haben oder???
-------------------------- Nachtrag die 2. ---------------------------------
nach Wikipedia Datenflusssteuerung – Wikipedia gibt es DC1 bis DC4.
XON ist DC1 ist 0x11
XOFF ist DC3 ist 0x13
aber was ist DC2 und DC4. und welche Zeichen entsprechen denen? 0x12 und 0x14?
Kopie aus Wiki:
Software-Flusssteuerung, Software-Handshake, Software-Protokoll oder X-ON/X-OFF[Bearbeiten]
Eine Software-Flusssteuerung wird durch in die Datenübertragung eingefügte Zeichen gesteuert.
Im ASCII-Zeichensatz (ITU-T-Empfehlung T.50) sind die ersten 32 Zeichen für Steuerungsaufgaben reserviert. Vier davon, DC1 bis DC4 (Device Control), sind Gerätesteuerzeichen.
Die Software-Flusssteuerung sollte davon die folgenden Zeichen benutzen:
DC1 (oft als X-ON bezeichnet, engl. für Transmission ON, Zeichencodierung 11hex bzw. 17dez, PC-Tastatur: Strg-Q) und
DC3 (oft als X-OFF bezeichnet, engl. für Transmission OFF, Zeichencodierung 13hex bzw. 19dez,PC-Tastatur: Strg-S).
Diese Zeichen sind sowohl in Richtung Endeinrichtung zum Übertragungsgerät als auch umgedreht nutzbar.
In der Datenübertragung mit Modems gibt es oft die Möglichkeit, diese Zeichen durch Konfiguration umzustellen.
Anwendung[Bearbeiten]
Ist der Sendespeicher des lokalen Modems fast gefüllt, wird das X-OFF-Steuerzeichen in die Empfangsdaten zur eigenen Endeinrichtung eingefügt. Sobald dieser Speicher zur Gegenstelle gesendet wurde und damit wieder leer ist, wird das X-ON-Steuerzeichen eingefügt und damit die Blockierung der Endeinrichtung aufgehoben. Die Übertragungsleitung ist hierdurch vor Datenverlusten gesichert.
Probleme[Bearbeiten]
Beim Versand von Binärdaten dürfen die beiden Steuerzeichen nicht in den Daten auftauchen, da sonst die Datenübertragung unterbrochen wird. Die Zeichen müssen maskiert werden, z. B. dadurch, dass die ganze Datenübertragung so umkodiert wird, dass die Daten als ASCII-Werte der hexadezimalen Zahlen gesendet werden. Ein vor Jahren oft genutztes Format war der Hex-Record von Intel. Dadurch wurde das zu übertragene Datenvolumen aber verdoppelt. Obwohl durch die Umkodierung innerhalb der zu übertragenen Dateien die X-ON/X-OFF-Steuerzeichen nicht mehr vorkommen, war eine Übertragung oft nicht möglich. Das Protokoll X-Modem beinhaltet zum Beispiel einen fortlaufenden Blockzähler von 00hex bis FFhex, so dass unabhängig von den zu übertragenen Daten jedes Datenbyte auftritt.
Die Software-Flusssteuerung sollte nur genutzt werden, wenn es keine Alternative gibt.
--------------------------------------- Nachtrag die 3. ----------------------------------------------------------
Mikrocontrollernet hat eine sehr gute allgemeine Erklärung. aber wirklich weitergebracht hats mich auch nicht...
http://www.mikrocontroller.net/articles/RS-232