So lesen Sie serielle Daten vom Oszilloskop

Ich habe einen Mikrocontroller (PICAXE 20X2) und einen Potenziometer. Ich habe das Mikro so programmiert, dass es jede Änderung des Potenziometers an die serielle Schnittstelle des PCs sendet. Offensichtlich handelt es sich um einen 8-Bit-ADC. Das Interessante für mich ist nun, diese seriellen Daten auf dem Oszilloskop dekodieren zu können.

Hier sind zwei Bilder, das erste ist, wenn das Mikro "0" an den PC sendet, und das nächste ist, wenn es "255" sendet. Die Daten werden mit 9600 buad übertragen und ich kann sie am PC-Terminal empfangen.

Erstes Bild

Zweites Bild

Meine Frage ist also, habe ich die richtigen Daten für mein Oszilloskop erfasst und zweitens, wie man diese Impulse lesen und in ein Hex- oder ASCII-Format decodieren kann. Ich meine, wie man diese ansteigenden und abfallenden Impulse (0/1) liest.

Vielen Dank.

Als erstes bemerkte auch Olin: Die Pegel sind die Umkehrung 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 ein Startbit ein 1Stoppbit ist 0.

$\mu$$\mu$$\mu$1$\mu$0

0x001$\mu$
0xFF$\mu$

Schätzungen:

0b11001111 = 0xCF
0b11110010 = 0xF2

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

edit
Olin hat absolut recht, das ist so etwas 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 korrekt ist.

edit 2 (wie ich die Daten interpretiere, auf vielfachen Wunsch :-))
Warnung: Dies ist eine lange Geschichte, da es sich um eine Abschrift dessen handelt, was in meinem Kopf passiert, wenn ich versuche, so etwas zu entschlüsseln. Lesen Sie es nur, wenn Sie lernen möchten, wie Sie es angehen können.

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

Wir kennen jetzt die Breite eines Einzelbits, eines Doppelbits und einer 4-Bit-Sequenz und schauen uns das erste Byte an. Die erste hohe Periode (der breite Impuls) ist etwas breiter als die 1111im zweiten Byte, so dass sie 5 Bits breit ist. Die darauf folgende niedrige und die hohe 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. Wenn unsere Einschätzung korrekt ist, können wir die Datenbits wieder umkehren: 11001111= 0xCF.

Dann haben wir einen Hinweis von Olin bekommen. Die erste Kommunikation ist 2 Byte lang und 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. Großartig, das wird die doppelte "5" sein. Uns geht es gut! (Sie müssen sich von Zeit zu Zeit selbst ermutigen.) Nach dem Entschlüsseln der "0", "2" und "5" stelle ich fest, dass zwischen den Codes für die ersten beiden ein Unterschied von 2 und zwischen dem letzten ein Unterschied von 3 besteht zwei. Und schließlich bemerke ich, dass dies 0xC_das Komplement von ist 0x3_, das das Muster für Ziffern in ASCII ist.

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

Um diese Daten schließlich in einen PC zu übertragen, müssen sie in RS-232-Pegel konvertiert werden. Dies ist, was ein PC-COM-Port erwartet. RS-232 ist im Leerlauf niedrig und aktiv hoch, aber niedrig ist unter -5V und hoch ist über + 5V. Glücklicherweise gibt es dafür Chips, die es einfach machen, zwischen typischen UART-Signalen mit Mikrocontroller-Logikpegel und RS-232 zu konvertieren. Diese Chips enthalten Ladungspumpen, um die RS-232-Spannungen von Ihrem 3,3-V-Netzteil 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 und nicht 5 V verwenden. Wir stellen ein Produkt her, das im Grunde genommen einer dieser Chips auf einer Platine mit Steckverbindern ist. Gehen Sie zu http://www.embedinc.com/products/rslink2Schauen Sie sich den Schaltplan an, um ein Beispiel für den Anschluss eines solchen Chips zu sehen.

Eine andere Sache, die sich nicht summiert, 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 mit den 8 Datenbits. dann ein Stoppbit. Das Startbit hat immer die entgegengesetzte Polarität zum Leitungsleerlaufpegel. In den meisten Beschreibungen wird der Leitungsleerlaufpegel als "Leerzeichen" und das Gegenteil als "Marke" bezeichnet. Das Startbit ist also immer an der Marke. Der Zweck des Startbits besteht darin, die verbleibenden Bits zeitlich zu synchronisieren. Da beide Seiten wissen, wie lang ein Bit ist, ist die einzige Frage, wann der Anfang eines Bytes ist. Das Startbit liefert diese Information. Der Empfänger startet im Wesentlichen einen Takt an der Vorderflanke des Startbits und verwendet diesen, um zu wissen, wann die Datenbits kommen werden.

Die Datenbits werden in der niedrigstwertigen Reihenfolge gesendet, wobei die Markierung 1 und das Leerzeichen 0 sind. Ein Stoppbit auf der Leerzeichenebene wird hinzugefügt, damit der Start des nächsten Startbits eine neue Flanke ist, und um etwas Zeit zu lassen zwischen Bytes. Dies ermöglicht einen kleinen Fehler zwischen Sender und Empfänger. Wäre der Empfänger auch nur ein bisschen langsamer als der Sender, würde er sonst den Start des nächsten Startbits verpassen. Der Empfänger setzt jedes neue Startbit zurück und startet seine Uhr neu, damit sich keine Zeitfehler ansammeln.

An all dem sollte man also erkennen können, dass der erste Trace mindestens zwei Bytes sendet und der letzte wie vielleicht 5 aussieht.

Es wäre hilfreich, wenn Sie die Zeitskala der Spuren erweitern würden. Auf diese Weise können Sie 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 eines Captures dekodieren. Derzeit gibt es nicht genügend Auflösung, um festzustellen, wo sich die Bits befinden, und decodieren daher tatsächlich, was gesendet wird.

Hinzugefügt:

Mir ist gerade eingefallen, dass Ihr System die Daten möglicherweise in ASCII anstelle von Binär sendet. Dies ist im Allgemeinen nicht der Fall, da die Konvertierung in ASCII in dem kleinen System weniger Ressourcen beansprucht, die Bandbreite nicht ausreicht und die Konvertierung auf dem PC einfach ist, wenn Sie die Daten einem Benutzer anzeigen möchten. Wenn Ihre Übertragungen jedoch ASCII-Zeichen sind, erklärt dies, warum die Sequenzen mehr als ein Byte umfassen, warum die zweite länger ist ("255" enthält mehr Zeichen als "0") und warum beide offenbar im selben Byte enden. 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 dekodieren, was gesendet wird.

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

Wenn das Rigol-Oszilloskop keine serielle Dekodierungsoption hat (bei vielen DSOs ist dies der Fall), können Sie zur Unterstützung der Dekodierung X-Cursor verwenden. Platzieren Sie den ersten Cursor an der Vorderkante der Daten und bewegen Sie den zweiten Cursor durch den Bitstrom. Das Delta zwischen den Cursorn kann verwendet werden, um durch einfache Arithmetik zu bestimmen, über welches 'Bit' Sie gerade schweben. Offensichtlich Start / Stopp / Paritätsbits ignorieren.