Wenn ein Mikrocontroller, Router oder Sensor plötzlich nur noch unlesbare Zeichen sendet, liegt die Ursache oft nicht im Netzwerkprotokoll, sondern schon am UART-Signal. Ich zeige, wie die serielle Übertragung funktioniert, welche Rolle Baudrate und Signalpegel spielen, worin sich TTL-UART, RS-232 und RS-485 unterscheiden und wie sich typische Fehler systematisch finden lassen.
Die wichtigsten Punkte zum UART-Signal auf einen Blick
- UART arbeitet asynchron und benötigt keine gemeinsame Taktleitung.
- Eine Übertragung besteht meist aus Startbit, 8 Datenbits, optionaler Parität und Stopbit.
- UART ist nicht automatisch RS-232. Die elektrischen Pegel und die Verkabelung können deutlich abweichen.
- Sender und Empfänger müssen bei Baudrate, Datenbits, Parität und Stopbits übereinstimmen.
- Für kurze Verbindungen genügen TTL-Pegel, für längere oder störanfällige Leitungen ist RS-485 meist die robustere Lösung.
Was bei einer UART-Übertragung tatsächlich auf der Leitung passiert
UART steht für Universal Asynchronous Receiver Transmitter. Gemeint ist meist eine Hardwareeinheit, die Bytes in eine serielle Bitfolge umwandelt und beim Empfänger wieder zusammensetzt. Ich betrachte UART deshalb eher als Übertragungsmechanismus als als vollständiges Netzwerkprotokoll.
Im Ruhezustand liegt die Leitung bei einer typischen Logik-UART auf High. Sobald ein Byte gesendet wird, zieht der Sender die Leitung für ein Startbit auf Low. Danach folgen die Datenbits, optional ein Paritätsbit und mindestens ein Stopbit auf High. Der Empfänger erkennt den Start, misst die folgenden Bitzeiten und rekonstruiert daraus das Zeichen.
Eine häufige Einstellung ist 8N1. Sie bedeutet acht Datenbits, keine Parität und ein Stopbit. Für ein einzelnes Byte werden dadurch nicht nur acht, sondern normalerweise zehn Bitzeiten benötigt. Bei 9600 Baud entspricht das theoretisch etwa 960 übertragenen Bytes pro Sekunde, sofern keine zusätzlichen Pausen oder Protokoll-Overheads entstehen.
Warum keine Taktleitung nötig ist
UART überträgt den Takt nicht separat. Beide Seiten verwenden eigene Taktgeneratoren und müssen sich deshalb auf dieselbe Baudrate einigen. Der Empfänger tastet die Leitung typischerweise mehrfach pro Bit ab, wodurch kleine Taktabweichungen toleriert werden können. Zu große Abweichungen führen jedoch zu Framing-Fehlern oder scheinbar zufälligen Zeichen.
Genau hier liegt ein häufiger Denkfehler. Eine Anzeige wie 115200 Baud sagt allein noch nicht, ob die Verbindung funktioniert. Auch Datenbits, Parität, Stopbits und Signalpolarität müssen passen. Schon eine Einstellung von 8E1 auf der einen und 8N1 auf der anderen Seite kann den Datenstrom unbrauchbar machen.
UART, TTL, RS-232 und RS-485 richtig auseinanderhalten
In der Praxis werden UART und serielle Schnittstelle oft gleichgesetzt. Das ist technisch zu ungenau. UART beschreibt vor allem die Verarbeitung der Bits, während TTL, RS-232 und RS-485 die elektrische Übertragung beziehungsweise die Schnittstellenebene festlegen.
| Schnittstelle | Typische Signalisierung | Geeignete Anwendung | Wichtige Grenze |
|---|---|---|---|
| TTL-UART | 0 und 3,3 V oder 5 V | Controller, Sensoren, Debug-Anschluss | Kurze Leitungen, gemeinsame Masse erforderlich |
| RS-232 | Negative und positive Spannungen, invertierte Logik | Ältere Rechner, Messgeräte, lokale Geräteverbindungen | Keine Mehrpunktverbindung, störanfälliger als differenzielle Systeme |
| RS-485 | Differenzsignal über A und B | Industrie, Gebäudetechnik, lange Leitungen | Terminierung und Busregeln müssen stimmen |
Ein 3,3-Volt-UART-Pin darf nicht direkt mit einem 5-Volt-Eingang verbunden werden, wenn dieser nicht dafür ausgelegt ist. Noch kritischer ist die Verbindung zu einem echten RS-232-Port. Dort können deutlich höhere, bipolare Spannungen auftreten. Ich verwende in solchen Fällen einen geeigneten Pegelwandler, statt mich auf vermeintlich ähnliche Steckverbinder zu verlassen.
Für kurze Verbindungen innerhalb eines Geräts reicht TTL-UART oft völlig aus. Sobald die Leitung länger wird, elektromagnetische Störungen auftreten oder mehrere Teilnehmer kommunizieren sollen, bietet RS-485 mit differenzieller Signalübertragung klare Vorteile. In Telekommunikations- und Infrastrukturprojekten, etwa bei verteilten Sensoren oder Energieanlagen in abgelegenen Regionen, ist dieser Unterschied entscheidend.
Wie eine stabile UART-Verbindung geplant wird
Eine einfache UART-Verbindung benötigt mindestens TX, RX und eine gemeinsame Masse. TX des Senders wird mit RX des Empfängers verbunden, RX mit TX. Werden TX und RX gleichnamig verbunden, bleibt die Leitung oft vollkommen still, obwohl beide Geräte korrekt eingeschaltet sind.
Die wichtigsten Einstellungen
- Baudrate, zum Beispiel 9600, 38400 oder 115200
- Datenbits, meist 7 oder 8
- Parität, keine, gerade oder ungerade
- Stopbits, meist 1 oder 2
- Flusskontrolle, keine, Hardware oder Software
Hardware-Flusskontrolle verwendet zusätzliche Leitungen wie RTS und CTS. Sie kann helfen, wenn ein Empfänger Daten nicht schnell genug verarbeiten kann. Bei einfachen Sensoren oder Debug-Verbindungen ist sie meistens deaktiviert. Ich würde sie nicht vorsorglich einschalten, denn fehlende Leitungen wirken dann wie ein permanentes Freigabesignal und blockieren die Übertragung.
Bei längeren Leitungen zählt nicht nur der Pegel, sondern auch die Umgebung. Kabel sollten möglichst kurz, sauber geführt und bei differenziellen Bussen passend terminiert sein. Ein gemeinsames Massekonzept ist bei TTL-Verbindungen unverzichtbar. Große Potentialunterschiede zwischen Geräten können sonst zu Datenfehlern oder sogar zu beschädigten Eingängen führen.
Lesen Sie auch: Campusnetz planen - So geht robustes Netzwerk-Design
UART im Netzwerkumfeld
UART selbst ist normalerweise eine Punkt-zu-Punkt-Verbindung. Es gibt keine Geräteadressen, keine automatische Fehlerkorrektur und keine eingebaute Paketverwaltung. Diese Aufgaben übernimmt ein darüberliegendes Protokoll, beispielsweise Modbus RTU, ein eigenes Binärformat oder eine einfache zeilenbasierte Konsolenschnittstelle.
Ein UART-zu-Ethernet-Gateway verbindet die serielle Welt mit einem IP-Netzwerk. Dabei wandelt das Gateway nicht automatisch jedes Datenformat um. Es transportiert oft nur die Bytefolge über TCP oder UDP. Für eine stabile Lösung müssen deshalb zusätzlich Paketgrenzen, Zeitüberschreitungen, Adressen und Wiederholungen definiert werden.
Typische Fehlerbilder und eine sinnvolle Diagnose
Wenn nur Fragezeichen, Sonderzeichen oder scheinbar zufällige Bytes erscheinen, prüfe ich zuerst die Konfiguration und erst danach die Hardware. Ein falscher Takt oder ein falsch gesetztes Paritätsbit ist deutlich häufiger als ein defekter UART-Baustein.
| Fehlerbild | Wahrscheinliche Ursache | Erster Prüfschritt |
|---|---|---|
| Keine Daten | TX und RX falsch verbunden, fehlende Masse oder deaktivierte Schnittstelle | Verdrahtung und Pinbelegung prüfen |
| Unlesbare Zeichen | Baudrate oder Datenformat stimmt nicht | Beide Geräte auf dieselbe Konfiguration setzen |
| Einzelne Aussetzer | Störungen, schlechte Masse oder zu hohe Datenrate | Leitung verkürzen und Signal messen |
| Verbindung bricht unter Last ab | Pufferüberlauf oder fehlende Flusskontrolle | Empfangspuffer und RTS/CTS prüfen |
| Nur bei langen Kabeln problematisch | Elektrische Pegel ungeeignet oder Abschluss fehlt | Auf RS-485 oder einen passenden Treiber wechseln |
Ein USB-UART-Adapter und ein Terminalprogramm reichen für die ersten Tests. Für eine belastbare Diagnose nutze ich zusätzlich einen Logikanalysator. Er zeigt Startbit, Bitdauer und Dateninhalt direkt. Ein Oszilloskop ist sinnvoll, wenn die Flanken verzerrt sind, Überschwinger auftreten oder die Versorgungsspannung unter Last einbricht.
Bei einer Messung sollte die Abtastrate deutlich über der Baudrate liegen. Für 115200 Baud sind mehrere Megasamples pro Sekunde eine praktische Größenordnung. Entscheidend ist nicht nur, ob Pegel zwischen Low und High wechseln, sondern ob die Bitzeiten gleichmäßig sind und der Ruhezustand tatsächlich dem erwarteten Pegel entspricht.
Wann UART die richtige Wahl ist und wann nicht
UART ist stark, wenn zwei Geräte mit wenig Aufwand Daten austauschen sollen. Debug-Konsolen, GNSS-Empfänger, Modems, Mikrocontroller und einfache Sensoren profitieren von der geringen Komplexität. Für viele eingebettete Systeme ist UART deshalb der schnellste Weg zu einer funktionierenden Diagnose- oder Steuerverbindung.
Für ein echtes Mehrteilnehmernetz ist eine nackte UART-Leitung dagegen ungeeignet. Es fehlen Adressierung, Buszugriff und eine definierte Kollisionsbehandlung. Hier kann ein RS-485-Bus mit einem Protokoll wie Modbus RTU sinnvoll sein. Für größere Entfernungen oder die Anbindung an bestehende IP-Infrastrukturen kommen Ethernet, Glasfaser oder ein serielles Gateway infrage.
Auch die Datenrate sollte realistisch gewählt werden. Eine hohe Baudrate verkürzt die Übertragungszeit, erhöht aber die Anforderungen an Taktgenauigkeit, Leitungsqualität und Verarbeitungsgeschwindigkeit. In einer störungsreichen Umgebung ist 9600 oder 19200 Baud oft zuverlässiger als die maximal mögliche Geschwindigkeit, sofern die Anwendung nicht auf kurze Antwortzeiten angewiesen ist.
Die praktische Faustregel für robuste serielle Verbindungen
Ich beginne bei jeder UART-Fehlersuche mit vier Fragen: Stimmen TX und RX, haben beide Seiten dieselbe Konfiguration, passen die elektrischen Pegel zusammen und reicht die gewählte Schnittstelle für Entfernung und Umgebung aus?
Wer diese Reihenfolge einhält, spart meist viel Zeit. Ein UART-Signal ist nicht automatisch ein Netzwerk, nicht automatisch RS-232 und auch nicht automatisch für lange Kabel geeignet. Für kurze interne Verbindungen genügt die einfache Logikleitung. Für verteilte Telekommunikations- oder Infrastruktursysteme braucht es dagegen einen passenden Treiber, ein klares Protokoll und eine saubere elektrische Planung.
