Woher kennt UART den Unterschied zwischen Datenbits und Start-/Stoppbits? [Duplikat]

Das klingt wie eine Frage von jemandem, der versucht, einen UART-Empfänger in Software oder einem FPGA zu emulieren. Für RS-232 verwenden sie den Begriff mark and space . Aber diese entsprechen normalerweise, sobald sie digitalisiert sind, jeweils einer '1' und '0'.

UART-Empfänger teilen oft jede Bitzeit (muss a priori bekannt sein) in mindestens 4, aber oft 16 oder mehr Unterperioden auf. Es beginnt (beim Einschalten/Rücksetzen) in einem Zustand, in dem die serielle Empfängerleitung in einem Markierungszustand erwartet wird . Befindet sich die Leitung in diesem Moment NICHT in einer Markierung , dann weiß sie, dass sie sich mitten in einem Übertragungsrahmen befindet und warten muss, bis sie sich synchronisieren kann. Wenn sich die Linie in einem Markierungszustand befindet , kann sie das sein oder nichtmitten in etwas sein und abwarten müssen. Dies ist ein Problem mit RS-232, wenn es nur an ein anderes Gerät angeschlossen wird, während serielle Kommunikation stattfindet, oder wenn ein Teil eines Taps zur Überwachung der asynchronen seriellen Kommunikation zwischen zwei anderen Playern und gerade zurückgesetzt wurde. Um absolut sicher zu sein, müsste der UART beim Verlassen des Resets sowieso mindestens N Bitzeiten (wobei N die Anzahl der Bits pro Wort und häufig 7 oder 8 ist und hier keine Paritätsoption annimmt) im Wert von Mark beobachten gefolgt von einer Bitzeit Platz zum erneuten Synchronisieren (oder sonst N+1 Bitzeiten Platz.) Viele tragen nicht so viel Status mit sich herum, sodass sie sich falsch synchronisieren können, wenn sie mitten in einem Stream gestartet werden. Sie erhalten oft Framing-Fehler und gelegentliche Datenbytes, bis es versehentlich wieder richtig synchronisiert wird. Das war oft auch ein akzeptabler Preis. Normalerweise werden Kabel angeschlossen und Geräte in einer bestimmten Betriebsreihenfolge eingeschaltet, sodass es selten zu Problemen kommt.

Einmal synchronisiert, weiß der UART jedoch, was zu erwarten ist. Es beginnt immer damit, dass die Empfängerleitung von einer Markierung zu einem Leerzeichen geht, dem erforderlichen Startbit, das eine volle Bitzeit lang ist, gefolgt von Datenbits und dann gefolgt von mindestens einer Bitzeit im Wert von Markierung (oder länger) als Stopp Bit. Wenn es synchronisiert bleibt, wird es dieses Muster immer und immer wieder wiederholen.

Ein Teil des Grundes für das Würfeln der Bitzeiten auf etwa 4X oder 16X ist, dass die vom Sender und Empfänger verwendeten Uhren nicht unbedingt perfekt genau sind und ansonsten einfach asynchron zueinander sind. Ein Teil der Synchronisation, die im Empfänger abläuft, besteht also darin, seine gewürfelten Perioden mit dem Timing des Senders in Einklang zu bringen. Je feiner das geschieht, desto besser kann der Empfänger ausgerichtet werden.

Es erkennt das Startbit. Genau das ist der Zweck. Die Leerlaufzeile sieht so aus:

...1111111111111111111111111111111...

Sobald der Empfänger 0nach einer langen Zeit Einsen sieht (oder nach einem Stoppbit, wie wir gleich sehen werden), weiß er, dass die Übertragung gestartet wurde und beginnt, Bits zu zählen . Es weiß, dass 8Bits (oder wie durch Konfiguration definiert) nach dem Startbit Daten sind. Das neunte ist das Stoppbit und sollte sein 1. Wenn dies nicht der Fall ist, tritt ein Framing-Fehler auf und eine Neusynchronisierung ist erforderlich.

Nachdem das Stoppbit empfangen wurde, beginnt es erneut auf das Startbit zu warten. Usw.

Theoretisch kann es ein Problem bei der Synchronisation geben, wenn die Zeile so aussieht:

..1010101010101010101.... 

oder ähnliches, so dass der Empfänger in diesem Fall nicht sieht, wo er anfangen soll, aber in diesem Fall spielt es keine Rolle, da die Startposition keinen Unterschied macht. Aber um solche Probleme zu vermeiden, definieren einige Protokolle eine Länge von 1,5 (eineinhalb) Bits für das Stoppbit, um es eindeutig zu machen. Oder in der Praxis gibt es immer einige Zeitverzögerungen zwischen zwei Datenpaketen, sodass die Leitung lange genug im Leerlauf ist, damit sich der Empfänger synchronisieren kann.

UART braucht am Anfang Stille, um das erste Startbit zu fangen. Dann zählt es nur noch entsprechend der vordefinierten Anzahl von Bits, erreicht das Stoppbit und wartet wieder auf das Startbit. Wenn UART mitten in einer langen Nachricht mit dem Empfang beginnt, kann es leicht zu Müll kommen.

Es kann den Unterschied erkennen, weil es weiß, wo sie im Bitstrom sein sollten (weil Sie es ihm gesagt haben).

Denken Sie einfach daran, dass jedes Symbol bedeutungslos ist, bis es eine vereinbarte Bedeutung gibt.

Wenn der Leerlauf bereits vorhanden ist, treten keine Fehler auf, kein Problem, aber jeder Fehler, wie z.

Handshaking ist notwendig, um die Erkennung eines vollen Puffers, eines Überlaufs, eines Paritätsfehlers oder eines Stoppbitfehlers zu kommunizieren.

Ungerade Parität ist hier nützlich, um einen Datenfehler und/oder einen Rahmenfehler zu erkennen, um die korrekte Startbitsynchronisierung und fehlerfreie Kommunikation wieder aufzunehmen.