Ich arbeite an einem Embedded-System, und ich habe Dramen bekommen, um einen bestimmten Datenblock über den seriellen Port zu senden. Ich habe es eingegrenzt und festgestellt, dass, wenn ein 0x9B in der Nachricht vorhanden ist, es die Nachricht beschädigt.
Also dann schaue ich 0x9b (155) auf Ссылка nach, und es fehlt! Ist das nicht ein bizarrer Zufall?
Irgendwelche Ideen, ist das ein besonderer Charakter oder etwas?
-edit- Okay, sorry Leute, es war nicht die 0x9b, die das verursacht hat, es war ein 0x11 Zeichen. Was ... Trommelwirbel ... ist ein XON / XOFF-Zeichen. Ich hatte fälschlicherweise Flusskontrolle als xon / xoff auf dem Computer und keine Flusskontrolle auf dem Gerät! Danke für die Hilfe trotzdem.
In ANSI-Escape-Sequenzen ist 0x9B das Control Sequence Introducer (die Multi-Character-Version, die ist vertrauter ist ESC-[ .
0x9B ist der CSI oder "Control Sequence Introducer" sein Teil des C1-Kontrollcodes, siehe hier: Ссылка
Angenommen, die Daten durchlaufen eine Schicht, die C1-Steuercodes verarbeitet, ist es nicht verwunderlich, dass nach diesem Zeichen einige Bytes fehlen, da sie den Beginn einer ANSI-Escape-Sequenz anzeigen. Die Bytes verschwinden, weil sie von einer Schicht als Teil einer Anweisung gelöscht werden. Mehr Infos dazu hier: Ссылка
Offensichtlich kann ich nicht garantieren, dass dies Ihr Problem ist, aber es ist das, wo ich anfangen würde, in der api-Dokumentation zu graben, basierend auf den Symptomen, die Sie beschrieben haben.
Wenn das Zeichen vor 0x9B 0x10 ist (DLE - Data Link Escape-Zeichen), das die verlorenen Zeichen erklären kann, die Sie sehen. Einige Geräte verwenden DLE als Steuerbefehlsanzeige und das nachfolgende Zeichen ist der Befehl. Wenn DLE-Zeichen nicht maskiert sind, ist das übliche Zeichen ein Verlust von 2 Zeichen im Stream oder ein seltsames Verhalten des Geräts. Entkomme DLE-Zeichen mit DLE. Also, in Ihrem Fall, wenn Ihr Datenstrom enthält:
... 0x10 0x9b ...
Sie müssten schreiben
... 0x10 0x10 0x9b ...
Ich vermute, das ist ein 0x1B, d. h. das ASCII-Escape-Zeichen, mit einem Paritätsbit in der 8. Bitposition (es kommt von der seriellen Kommunikation und allen).
Technisch gesehen sind die Zeichen im ASCII-Satz alle kleiner oder gleich 0x7F , Zeichen zwischen 0x80 bis 0xFF sind Teil des erweiterten ASCII . Die Bedeutung der Codes über 0x7F variiert typischerweise, so dass einer von mehreren Zeichensätzen mit Codes verarbeitet werden kann, die genau ein Byte groß sind. Diese Fähigkeit führt leider zu einer Mehrdeutigkeit, denn man muss den speziellen zusätzlichen Zeichensatz kennen, der verwendet wird (wenn man so will, die "Codepage").
Zum Beispiel scheint die "ASCII" -Tabelle, auf die in der Frage verwiesen wird, kein mit 0x9B verknüpftes Zeichen zu haben, während viele andere erweiterte ASCII-Sätze dies für ein "normales" / anzeigbares Zeichen verwenden (z. B. ein > aussehendes Zeichen in ISO) -8859-1, das Cent-Zeichen (ein C-ähnliches Zeichen) mit einem anderen Satz usw.
Die mögliche Bedeutung des 0x9B-Zeichens könnte daher von dem [implizierten] Zeichensatz abhängen, der mit der zugrunde liegenden Anwendung verwendet wird. Aber wie bereits gesagt, sieht es eher so aus, als wären die Zeichen auf 7 Bits (daher wahrscheinlich "reine" ASCII-Zeichen) mit einem Paritätsbit codiert.
Für jeden, der nur wegen des Titels zu dieser Frage kommt: 0x9B / 155 fehlt in ASCII-Tabellen, weil es kein ASCII-Zeichen ist. ASCII-Zeichen sind nur 7 Bits breit, was bedeutet, dass es nur 128 von ihnen gibt, dort ist einfach ist kein Zeichen 155.
[Community Wiki, weil es nicht wirklich die Frage beantwortet, nur der Titel.]
Tags und Links c embedded communication serial-port control-characters