So lesen Sie serielle Daten vom Oszilloskop

Als erstes bemerkte Olin auch: Die Pegel sind das Gegenteil dessen, was ein Mikrocontroller normalerweise ausgibt:

Keine Sorge, wir werden sehen, dass wir es auch so lesen können. Wir müssen uns nur daran erinnern, dass auf dem Oszilloskop ein Startbit a 1und das Stoppbit sein wird 0.

Als nächstes haben Sie die falsche Zeitbasis, um dies richtig zu lesen. 9600 Bit pro Sekunde (geeignetere Einheiten als Baud, obwohl letzteres per se nicht falsch ist) ist 104$\mu$s pro Bit, was in Ihrer aktuellen Einstellung 1/10 einer Division entspricht. Zoomen Sie hinein und setzen Sie einen vertikalen Cursor auf die erste Kante. Das ist der Beginn Ihres Startbits. Bewegen Sie den zweiten Cursor zu jeder der nächsten Kanten. Die Differenz zwischen den Cursorn sollte ein Vielfaches von 104 sein$\mu$s. Jeweils 104$\mu$s ist ein Bit, zuerst das Startbit ( 1), dann 8 Datenbits, Gesamtzeit 832$\mu$s und ein Stoppbit ( 0).

Es sieht nicht so aus, als ob die Bildschirmdaten mit den gesendeten übereinstimmen 0x00. Sie sollten ein schmales 1Bit (das Startbit) sehen, gefolgt von einem längeren niedrigen Pegel (936$\mu$s, 8 Null-Datenbits + ein Stoppbit).
Gleiches gilt für das 0xFF, was Sie senden. Sie sollten ein langes hohes Niveau sehen (wieder 936$\mu$s, diesmal das Startbit + 8 Datenbits). Das sollte also fast 1 Division mit Ihrer aktuellen Einstellung sein, aber das ist nicht das, was ich sehe.
Es sieht eher so aus, als würden Sie im ersten Screenshot zwei Bytes senden und im zweiten vier, wobei das 2. und 3. den gleichen Wert haben.

Schätzungen:

0b11001111 = 0xCF
0b11110010 = 0xF2

0b11001101 = 0xCD
0b11001010 = 0xCA
0b11001010 = 0xCA
0b11110010 = 0xF2

edit
Olin hat vollkommen recht, das ist sowas wie ASCII. Tatsächlich ist es das 1er-Komplement von ASCII.

0xCF ~ 0x30 = '0'
0xCE ~ 0x31 = '1'
0xCD ~ 0x32 = '2'
0xCC ~ 0x33 = '3'
0xCB ~ 0x34 = '4'
0xCA ~ 0x35 = '5'

0xF2 ~ 0x0D = [CR]

Dies bestätigt, dass meine Interpretation der Screenshots richtig ist.

Bearbeiten 2 (wie ich die Daten interpretiere, auf vielfachen Wunsch :-))
Warnung: Dies ist eine lange Geschichte, da es eine Niederschrift dessen ist, was in meinem Kopf passiert, wenn ich versuche, so etwas zu entschlüsseln. Lesen Sie es nur, wenn Sie einen Weg lernen möchten, es anzugehen.

Beispiel: das zweite Byte auf dem 1. Screenshot, beginnend mit den 2 schmalen Impulsen. Ich beginne absichtlich mit dem zweiten Byte, weil es mehr Kanten als im ersten Byte gibt, sodass es einfacher ist, es richtig zu machen. Jeder der schmalen Impulse ist etwa 1/10 einer Division, so dass jeder 1 Bit hoch sein könnte, mit einem niedrigen Bit dazwischen. Ich sehe auch nichts Engeres als das, also schätze ich, dass es ein einzelnes Bit ist. Das ist unsere Referenz.
Dann, nach 101längerer Zeit auf niedrigem Niveau. Sieht ungefähr doppelt so breit aus wie die vorherigen, das könnte also sein 00. Der hohe Anschluss ist nochmal doppelt so breit, das wird also 1111. Wir haben jetzt 9 Bits: ein Startbit ( 1) plus 8 Datenbits. Das nächste Bit wird also das Stoppbit sein, aber weil es so ist0es ist nicht sofort sichtbar. Wenn wir also alles zusammen haben, haben wir 1010011110, einschließlich Start- und Stoppbit. Wenn das Stoppbit nicht Null wäre, hätte ich irgendwo eine schlechte Annahme getroffen!
Denken Sie daran, dass ein UART zuerst das LSB (niederwertigstes Bit) sendet, also müssen wir die 8 Datenbits umkehren: 11110010= 0xF2.

Wir kennen jetzt die Breite eines Einzelbits, eines Doppelbits und einer 4-Bit-Folge und schauen uns das erste Byte an. Die erste High-Periode (der breite Impuls) ist etwas breiter als die 1111im zweiten Byte, so dass sie 5 Bit breit ist. Die darauf folgende Low- und High-Periode sind jeweils so breit wie das Doppelbit im anderen Byte, also erhalten wir 111110011. Wieder 9 Bits, also sollte das nächste ein niedriges Bit sein, das Stoppbit. Das ist in Ordnung, also wenn unsere Schätzung richtig ist, können wir die Datenbits wieder umkehren: 11001111= 0xCF.

Dann bekamen wir einen Hinweis von Olin. Die erste Kommunikation ist 2 Byte lang, 2 Byte kürzer als die zweite. Und "0" ist auch 2 Bytes kürzer als "255". Es ist also wahrscheinlich so etwas wie ASCII, wenn auch nicht genau. Ich stelle auch fest, dass das zweite und dritte Byte der "255" gleich sind. Toll, das wird die doppelte "5". Uns geht es gut! (Sie müssen sich von Zeit zu Zeit Mut machen.) Nachdem ich die "0", "2" und "5" entschlüsselt habe, bemerke ich, dass zwischen den Codes für die ersten beiden ein Unterschied von 2 und zwischen den letzten ein Unterschied von 3 besteht zwei. Und schließlich bemerke ich, dass dies 0xC_das Komplement von 0x3_ist, das das Muster für Ziffern in ASCII ist.

Irgendetwas passt nicht zusammen. Ihre Signale scheinen 3,3 V von Spitze zu Spitze zu sein, was bedeutet, dass sie direkt aus dem Mikro kommen. Die UART-Pegel des Mikrocontrollers sind jedoch (fast) immer im Leerlauf hoch und aktiv niedrig. Ihre Signale sind davon invertiert, was keinen Sinn ergibt.

Um diese Daten letztendlich in einen PC zu bekommen, müssen sie auf RS-232-Pegel konvertiert werden. Das erwartet ein PC-COM-Port. RS-232 ist im Leerlauf niedrig und aktiv hoch, aber niedrig liegt unter -5 V und hoch über +5 V. Glücklicherweise gibt es dafür Chips, die es einfach machen, zwischen UART-Signalen mit typischem Mikrocontroller-Logikpegel und RS-232 umzuwandeln. Diese Chips enthalten Ladungspumpen, um die RS-232-Spannungen aus Ihrer 3,3-V-Stromversorgung zu erzeugen. Manchmal werden diese Chips allgemein als "MAX232" bezeichnet, da dies eine Teilenummer für einen frühen und beliebten Chip dieses Typs war. Sie benötigen eine andere Variante, da Sie anscheinend 3,3 V-Strom verwenden, nicht 5 V. Wir stellen ein Produkt her, das im Grunde einer dieser Chips auf einer Platine mit Anschlüssen ist. Gehen Sie zu http://www.embedinc.com/products/rslink2und schauen Sie sich den Schaltplan an, um ein Beispiel zu sehen, wie man einen solchen Chip anschließt.

Eine andere Sache, die nicht zusammenpasst, ist, dass beide Sequenzen mehr als ein Byte zu sein scheinen, obwohl Sie sagen, dass Sie nur 0 und 255 senden. Diese Art von seriellen Daten wird mit einem Startbit gesendet, dann die 8 Datenbits, dann ein Stoppbit. Das Startbit hat immer die entgegengesetzte Polarität zum Leitungsruhepegel. In den meisten Beschreibungen wird der Leitungsruhepegel als "Leerzeichen" und das Gegenteil als "Markierung" bezeichnet. Das Startbit ist also immer auf Marke. Der Zweck des Startbits besteht darin, die verbleibenden Bits zeitlich zu synchronisieren. Da beide Seiten wissen, wie lang ein Bit ist, stellt sich nur die Frage, wann ein Byte beginnt. Das Startbit liefert diese Information. Der Empfänger startet im Wesentlichen eine Uhr an der Vorderflanke des Startbits und verwendet diese, um zu wissen, wann die Datenbits kommen werden.

Die Datenbits werden von der kleinsten zur höchstwertigen Reihenfolge gesendet, wobei Markierung 1 und Leerzeichen 0 ist. Ein Stoppbit auf der Leerzeichenebene wird hinzugefügt, damit der Beginn des nächsten Startbits eine neue Flanke ist, und um etwas Zeit zu lassen zwischen Byte. Dies ermöglicht einen kleinen Fehler zwischen Sender und Empfänger. Wenn der Empfänger auch nur geringfügig langsamer als der Sender wäre, würde er sonst den Beginn des nächsten Startbits verpassen. Der Empfänger setzt seine Uhr bei jedem neuen Startbit zurück und startet sie neu, um Zeitfehler nicht zu akkumulieren.

Aus all dem sollten Sie also erkennen können, dass die erste Spur mindestens zwei Bytes zu senden scheint und die letzte wie vielleicht 5 aussieht.

Es wäre hilfreich, wenn Sie die Zeitskala der Spuren erweitern würden. So konnte man messen, was ein bisschen Zeit wirklich ist. Auf diese Weise können Sie überprüfen, ob Sie wirklich 9600 Baud (104 µs / Bit) haben, und einzelne Bits einer Aufnahme decodieren. So wie es jetzt ist, gibt es nicht genug Auflösung, um zu sehen, wo sich die Bits befinden, und daher tatsächlich zu decodieren, was gesendet wird.

Hinzugefügt:

Mir ist gerade aufgefallen, dass Ihr System die Daten möglicherweise in ASCII statt in binär sendet. So wird es im Allgemeinen nicht gemacht, da die Konvertierung in ASCII in dem kleinen System mehr der begrenzten Ressourcen beansprucht, die Bandbreite schlecht nutzt und es einfach ist, die Konvertierung auf dem PC durchzuführen, wenn Sie die Daten einem Benutzer anzeigen möchten. Wenn Ihre Übertragungen jedoch ASCII-Zeichen sind, würde dies erklären, warum die Sequenzen mehr als ein Byte umfassen, warum die zweite länger ist ("255" sind mehr Zeichen als "0") und warum beide im selben Byte zu enden scheinen. Das letzte Byte ist wahrscheinlich eine Art Zeilenendezeichen, das normalerweise ein Wagenrücklauf oder ein Zeilenvorschub ist.

Wie auch immer, erweitern Sie die Zeitskala und wir können genau entschlüsseln, was gesendet wird.

Sie müssen alle Details kennen: die Geschwindigkeit, ob ein Startbit vorhanden ist, die Anzahl der Datenbits, ob ein Stoppbit vorhanden ist und ob ein Paritätsbit vorhanden ist. Dies sollte davon abhängen, wie der UART im Mikrocontroller konfiguriert ist.

Wenn das Rigol-Oszilloskop keine serielle Dekodierungsoption hat (viele DSOs haben sie), können Sie X-Cursor verwenden, um die Dekodierung zu unterstützen. Platzieren Sie den ersten Cursor an der Vorderkante der Daten und bewegen Sie den zweiten Cursor durch den Bitstrom. Das Delta zwischen den Cursors kann verwendet werden, um durch einfache Arithmetik zu bestimmen, über welchem ​​'Bit' Sie gerade schweben. Ignorieren Sie natürlich Start-/Stopp-/Paritätsbits.