Serielle Kommunikation über RS-232/RS-485 (Teil 1) (Seite 2)

Da das Senden des Startbits jederzeit erfolgen kann, mit beliebigen Pausen zwischen dem letzten Stoppbit und dem neuen Startbit, nennt man diese Art der Kommunikation asynchron.

Erweiterte Grundlagen

Für die serielle Kommunikation über den UART müssen folgende Parameter sowohl beim Empfänger als auch beim Sender identisch eingestellt werden: Übertragungsgeschwindigkeit, Zahl der Datenbits, Zahl der Stoppbits, Parity und Flow Control. Anwendungen wie PuTTY erlauben, die entsprechenden Einstellungen vor Aufbau der Verbindung zu setzen (Abbildung 2).

Abbildung 2: Das Windows-Programm PuTTY unterstützt als Terminalprogramm die serielle Kommunikation. Die üblichen Parameter lassen sich in den Einstellungen eintragen.

Mit der Baudrate definieren Sie die Geschwindigkeit der Verbindung. Die Baudrate entspricht per Definition der Angabe, wie oft ein Signal in einem Kommunikationskanal den Zustand ändert. In der Regel entspricht die Baudrate der Bitrate in Bit/s, beispielsweise 115 200 Bit/s – jedes Bit “dauert” in diesem Fall 8,68 Mikrosekunden.

Die Anzahl der Datenbits regelt die Zahl der Bits in einem Frame, also im Abschnitt zwischen dem Start- und Stoppbit. Üblicherweise entspricht dieser Wert einem Byte, also 8 Bits Nutzdaten. Es gibt jedoch auch andere Möglichkeiten. Am häufigsten trifft man auf 5 Bits, zum Beispiel als Baudot-Code, sowie 7 Bits für “echtes” ASCII mit nur den ersten 127 Zeichen. Daneben existieren selten genutzte Varianten mit 6 und 9 Bits.

Die Stoppbits übermittelt der Sender am Ende jedes Zeichens beziehungsweise als Abschluss des Frames. So kann der Empfänger das Ende des Frames feststellen und sich synchronisieren. Üblicherweise wird ein Stoppbit verwendet, es gibt aber auch 1 1/2 oder 2 Stoppbits. Das war zum Beispiel für die langsamen elektromechanischen Teleprinter notwendig.

Das Paritätsbit oder Parity Bit bietet eine einfache Möglichkeit, Fehler in der Übertragung zu erkennen – allerdings ohne die Möglichkeit, sie zu beheben. Solche Fehler treten beispielsweise durch äußere Einflüsse auf, wie etwa elektromagnetische Störungen auf schlecht geschirmten Leitungen. Dabei liest der Empfänger zum Beispiel fälschlicherweise eine Eins, wo eine Null sein sollte, oder umgekehrt.

Bei der Parity wird die Zahl der logischen Einsen im übertragenen Byte gezählt, inklusive des Paritätsbits. Der Wert des Parity Bits wird so gesetzt, dass die Zahl der logischen Einsen im Frame immer entweder gerade oder ungerade ausfällt (Even- beziehungsweise Odd-Parity). Auf diese Weise bemerkt der Empfänger ein bei der Übermittlung “umgefallenes” Bit, einen sogenannte Bitflip. Kippen allerdings zwei oder eine andere gerade Anzahl an Bits fällt der Fehler nicht auf.

Bei einer mit aktiviertem Paritätsbit initiierten Verbindung wird das Prüfbit zusätzlich nach dem letzten Datenbit und vor dem Stoppbit im Frame übertragen (Abbildung 3). Die Tabelle “Parity” zeigt die unterschiedlichen Varianten bei der Verwendung eines Paritätsbits. Mark und Space kommen nur selten zum Einsatz, da sie nicht zur Fehlererkennung beitragen. Unabhängig vom Parity Bit lassen sich auf einer höheren Schicht der Kommunikation weitere Fehlererkennungsmechanismen beziehungsweise Mechanismen zum Wiederanfordern fehlerhafter Daten vereinbaren.

Abbildung 3: Das vor dem Stoppbit eingesetzte Parity Bit ermöglicht es, Fehler in der Datenübertragung zu erkennen. (Bild: Wikipedia: CC-BY-SA)

Eher aus historischer Sicht zu verstehen ist die Datenflusssteuerung oder englisch Flow Control. Hier informiert der Empfänger den Sender, wann er für weitere Daten bereitsteht. Beispielsweise könnte der Empfänger eine gewisse Zeit benötigen, um die zuvor empfangenen Daten zu verarbeiten, oder der Empfangspuffer läuft voll, und das System kann momentan keine weiteren Daten mehr annehmen, ohne andere zu verlieren. Ein Beispiel wäre ein Drucker, der Zeile für Zeile langsam druckt und nicht nachkommt, falls die Daten zu schnell eintreffen.

Für die Datenflusssteuerung gibt es hard- und softwarebasierte Verfahren (siehe Tabelle “Flow Control”). Eine Hardware-Flow-Control braucht mit RTS (Ready to Send) und CTS (Clear to Send) zwei zusätzliche Steuerleitungen. Am RasPi sind diese zwei zusätzlichen Pins für beide UARTs (PL011 und Mini-UART) auf dem P5-Header [2] verfügbar. Die Idee dahinter: Der Sender zieht RTS auf GND, sobald er senden möchte. Der Empfänger zieht im Gegenzug CTS auf GND und signalisiert damit, dass er bereit ist, Daten vom Sender zu akzeptieren.

Möglich ist auch, den RTS-Pin als RTR (Ready to Receive) zu verwenden. In diesem Fall wird RTS immer als gesetzt angenommen, was bedeutet, dass sich der Empfänger immer empfangsbereit halten sollte. RTR dient dann für die Kommunikation in die Gegenrichtung als Indikation für die Empfangsbereitschaft des Senders. Im einfachsten Kommunikationsfall kann man auf Flow Control ganz verzichten.

@:KT:Hinweis @:KL:Wir verwenden hier das Wort Sender für den Computer (im Netzwerkjargon: DTE, Data Terminal Equipment), da die Terminologie dem Computer das RTR– beziehungsweise RTS-Signal zuweist, während der Empfänger (DCE, Data Communication Equipment) das CTS-Signal zugewiesen bekommt. @:KE:

Bei Software Flow Control werden zwei besondere Zeichen vereinbart, in der Regel die ASCII-Kontrollzeichen XON und XOFF (Abbildung 4). Standardmäßig startet der Empfänger im Bereitschaftsmodus und empfängt Daten. Sobald seine Puffer überzulaufen drohen, übermittelt er dem Sender auf einer anderen Leitung, bei der der Empfänger selbst der Sender ist, ein XOFF-Zeichen. Sobald er wieder empfangen kann, sendet er ein XON.