Archiv verlassen und diese Seite im Standarddesign anzeigen : Steruerzeichen und Daten seriell versenden
Hi, hab nen kleines Problem:
Ich möchte Daten über die serielle Schnittstelle versenden, das funktioniert auch prinzipiell. Jedoch Folgendes:
Ich möchte Daten senden, in denen aber auch die ersten 32 Ascii-Befehle, die Steuerzeichen, vorkommen.
Ich wollte also Daten senden, und mit EOT (04) signalisieren, dass die Übertragung zuende ist. Sobald aber Daten gesendet wurden, in denen 04 vorkommt wird die Übertragung logischerweise unterbrochen.
Ich habe es vorübergehend dann so gelöst, dass ich jede Übertragung auf 40 Bytes länge aufgeblasen hab. Mit der fixen Länge kann der Empfänger dann leicht die Bytes zählen und weiss wann die Übertragung zuende ist.
Das funktioniert zwar, aber ist verschwenderisch und umständlich, wenn ich z.B. manche Daten habe, die nur aus 2 Bytes bestehen.
Hmm, jetzt hab ich ziemlich viel geschrieben zu einem relativ einfachen Problem - da hat sicher einer eine Lösung wie man sowas aufbau, im Forum hab ich mich natürlich schon umgesehen.
linux_80
13.08.2006, 17:30
Hallo,
da gibts die Möglichkeiten,
entweder vermeiden, das Steuerzeichen anderswo vorkommen,
oder die Befehle anders aufbauen, sodass ein enthaltenes Steuerzeichen hier nicht als solches erkannt wird, (etwa wie bei ESC-Codes)
oder eine Befehlesfolge die angibt, das jetzt x Byte an Binärdaten kommen, die nicht anderweitig ausgewertet werden dürfen.
Da gibts bestimmt schon einige Protokolle dafür.
Sehr einfach ist es, grundsätzlich zu Beginn immer erst die Datenlänge zu senden.
Andere Variante ist "Byte-Stuffing":
https://www.roboternetz.de/wissen/index.php/Bascom_UART_Input#Byte-Stuffing
Möglichkeit 1 scheidet aus, weil ich das nicht vermeiden kann.
Möglichkeit 2; Versteh ich das richtig so: Ein Byte senden, das als "escape-zeichen" dient. Also müsste ich von den 255 möglichen aber wieder eins einsparen (als dieses Escape-Zeichen) - oder wars anders gemeint?
Möglichkeit 3 gefällt mir am besten wenn ich möglichkeit 2 so richtig verstanden hab - eigentlich so simpel, das ich da gar nicht draufkam...
kalledom
13.08.2006, 17:41
Bei mir wird bei der Kommunikation zwischen µC und PC zum Setzten von Parametern oder Auslesen von Werten ein Kommando-Buchstabe mit nachfolgenden Ziffern nur als ASCII-Zeichen übertragen. Jeder Befehl / Befehlszeile endet mit Return und LineFeed. Das LineFeed wird komplett ignoriert, nach Return wird das Kommando ausgewertet, überprüft und entsprechend reagiert.
Damit kann ich über einfache Terminal-Programme mit dem jeweiligen µC kommunizieren oder ihn steuern.
Beispiele (MOBS-Kommandos): http://www.domnick-elektronik.de/projekte.htm#MOBS
Kommando-Auswertung in Assembler: http://www.domnick-elektronik.de/picasm.htm#CmdRout
Aha - Möglichkeit 2 von vorhin ist also vergleichbar mit PicNick's "Byte Stuffing"...
bei kalledom wird demnach LF (10) verwendet, kann ich aber nicht nehmen, weil wie schon gesagt nicht vermeiden kann, dass mal irgendwo in den Daten die 10 vorkommt.
linux_80
13.08.2006, 18:27
Man darf natürlich nicht jedes Byte das ankommt grundsätzlich als Befehl auswerten,
der Empfänger muss wissen, ist gerade der Befehlsmodus, oder der Datenmodus.
Dann kann auch durchaus ein Zeichen, das zum Befehlscode ausgewählt wurde in den Daten vorkommen.
Siehe zB. ESC-Codes für Drucker.
Hallo BlooD!
Für Dich würde am besten die Lösung vom PickNick: immer als erstes Byte die Anzahl der nachkommenden Databytes zu senden. Der Empfänger kann sich die Anzahl der Datenbytes abspeichern und bis soviel zählen. Dann sind alle 256 Werte für Daten zulässig. Nachteil ist, dass über 255 Databytes in mehreren Blöcken und bei einem Databyte 2 Bytes geschickt werden müssen. Einzelnes Byte 00 kann dafür aber als Befehl angewendet werden.
MfG
@PICture:
Soweit waren meine Gedanken auch schon, glaube das ist die beste Lösung.
Kommen aber wieder zwei neue Fragen auf:
Kann ich nicht mehr als 255 Bytes auf einmal übertragen?
Was verstehst du unter "Databyte"?
Du kannst mehr als 255 Bytes übertragen, aber in mehreren Blöcken. Das wird z.B. für 300 Bytes so aussehen:
255 Anzahl
1.Databyte (Zeichen)
2.Databyte
................
254.Databyte
255.Databyte
45 Anzahl
256.Databyte
257.Databyte
..................
299.Databyte
300.Databyte
Als Databyte verstehe ich biliebiger Wert 0...255.
Du kannst auch mehr Bytes, aber immer gleiche Menge, fürs Definieren der Anzahl der nachfolgender Databytes anwenden. Z.B. bei 3 Bytes kannst Du 1...16 KB auf einmal übertragen.
MfG :)
aso, nicht weil es irgendwie begrenzt ist auf 255 Bytes, sondern weil ich die Anzahl ja auch senden muss und dabei halt 255 das maximale ist...
richtig?
könnte demnach auch 2 Bytes für die Anzahl senden. (In der Regel hab ich weniger als 255 Bytes)
genau, das habe ich noch während Du Deinen Beitrag geschrieben hast in meinem Beitrag ergänzt.
MfG
Okay alles klar, merci für eure antworten. Werde das die nächsten Tage mal probieren.
Danke und Gut-n8 :)
kalledom
13.08.2006, 23:10
Wenn blockweise übertragen wird, muß der Fehlerfall berücksichtigt sein.
Wird während der Übertragung eines Datenblocks ein Byte oder ein Startbit wegen Störung nicht erkannt, kommt die gesamte nachfolgende Übertragung 'aus dem Tritt'.
Normalerweise wird am Ende eines Blocks eine Checksumme übertragen. Bei Übereinstimmung wird ein positives Acknoledge als Bestätigung gesendet und der nächste Datenblock folgt.
Ergibt die Checksumme keine Übereinstimmung, wird ein negatives Acknoledge gesendet und der letzte Datenblock erneut übertragen.
Was im wiederholten Fehlerfall geschieht .... ???
Zusätzlich kann noch das Parity-Bit eingesetzt werden, um ein falsch übertragenes Byte zu erkennen.
Bei reiner ASCII-Übertragung wird ein Fehler in der Regel bei der Auswertung des Kommandos oder der Zahl erkannt.
Übrigens können Daten auch als hexadezimale Ziffern in ASCII übertragen werden.
Bei der binären Übertragung machen in der Tat einige nicht-druckbare Steuerzeichen beim PC Ärger. Sie können auch nicht ohne weiteres überprüft oder angezeigt werden.
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.