> For the complete documentation index, see [llms.txt](https://taiphoon-com.gitbook.io/taiphoon.com-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://taiphoon-com.gitbook.io/taiphoon.com-docs/de/support/knowledge-base/uart.md).

# Serielle Kommunikation (UART)

### Was ist UART? <a href="#uart" id="uart"></a>

UART (Universal Asynchronous Receiver/Transmitter) ist ein asynchrones serielles Kommunikationsverfahren, das in der Regel zwei Datenleitungen nutzt, um Daten zwischen zwei Geräten zu übertragen. Es ist eine der häufigsten Kommunikationsschnittstellen in Flugcontroller-Systemen.

Bei Drohnen und Flugcontrollern wird UART häufig zum Anschluss von Geräten wie GPS, Telemetriemodulen, Empfängern, Companion Computern, Entfernungsmessern sowie Debug-Konsolen des Systems verwendet.

### Eigenschaften von UART <a href="#uart" id="uart"></a>

UART ist eine **Punkt-zu-Punkt**-Kommunikation und im Gegensatz zu I2C oder CAN kein gemeinsam genutzter Bus. Eine UART-Verbindung verbindet in der Regel nur zwei Geräte und verwendet keinen Adressierungsmechanismus.

Der Vorteil dieses Verfahrens sind der einfache Aufbau, die hohe Kompatibilität und die breite Anwendbarkeit. Es bedeutet aber auch, dass jedes Peripheriegerät in der Regel eine eigene serielle Schnittstelle belegt.

### Grundlegende UART-Signale <a href="#uart" id="uart"></a>

Die einfachste UART-Verbindung benötigt drei Leitungen:

| Signal | Zweck                         |
| ------ | ----------------------------- |
| TX     | Ausgang für gesendete Daten.  |
| RX     | Eingang für empfangene Daten. |
| GND    | Gemeinsamer Massebezug.       |

Manche Flugcontroller oder Peripheriegeräte stellen am selben Anschluss zusätzlich 5V, 3.3V, CTS, RTS oder andere Steuersignale bereit. Für eine funktionierende UART-Kommunikation sind jedoch TX, RX und GND entscheidend.

### Gekreuzte Verbindung von TX / RX <a href="#tx--rx" id="tx--rx"></a>

Der häufigste Verkabelungsfehler bei UART ist die vertauschte Richtung von TX und RX.

Die korrekte Verbindung lautet:

* TX von Gerät A wird mit RX von Gerät B verbunden.
* RX von Gerät A wird mit TX von Gerät B verbunden.
* GND beider Seiten muss verbunden sein.

Das heißt: **Die Sendeseite muss mit der Empfangsseite des Gegenübers verbunden werden**. Wenn TX mit TX und RX mit RX verbunden wird, fließen in der Regel keinerlei Daten.

### Bedeutung der gemeinsamen Masse <a href="#undefined" id="undefined"></a>

Auch wenn TX und RX richtig angeschlossen sind, kann UART instabil arbeiten, wenn die beiden Geräte keine gemeinsame Masse haben.

Das liegt daran, dass UART-Signale ein gemeinsames Massepotenzial als Bezug benötigen. Fehlt die gemeinsame Masse, kann die Empfangsseite High- und Low-Pegel möglicherweise nicht korrekt erkennen, was zu Datenfehlern, Unterbrechungen oder einem vollständigen Kommunikationsausfall führt.

### Baudrate (Baudrate) <a href="#undefined" id="undefined"></a>

Beide Seiten einer UART-Kommunikation müssen dieselbe Baudrate (baud rate) verwenden, andernfalls erscheinen die Daten auf der Empfangsseite in der Regel als Zeichensalat oder sind nicht erkennbar.

Gängige Baudraten sind:

* 9600: Häufiger Standardwert bei manchen GPS-Modulen oder einfachen Sensoren.
* 57600: Häufig bei Debug-Konsolen oder manchen Telemetriekonfigurationen.
* 115200: Sehr verbreitet bei MAVLink-, GPS- und Companion-Computer-Verbindungen.
* 921600: Wird möglicherweise bei hochfrequenter Datenübertragung oder schnellen Verbindungen verwendet, stellt aber höhere Anforderungen an Kabel und Flusssteuerung.

### Hinweise zur Baudrate <a href="#undefined" id="undefined"></a>

Wenn die Baudrate auf 921600 oder höher erhöht wird, hängt die Stabilität der Kommunikation stärker von der Kabelqualität, der Verbindungslänge und der Unterstützung von Hardware-Flusssteuerung ab.

Die UART-Dokumentation von ARK weist ausdrücklich darauf hin, dass es bei Hochgeschwindigkeits-UART ohne Hardware-Flusssteuerung wie CTS/RTS auf längeren Kabeln leicht zu Paketverlusten kommt; ein stabiler Betrieb ist eher nur bei kurzen Board-zu-Board-Verbindungen zu erwarten.

### Datenformat <a href="#undefined" id="undefined"></a>

Das häufigste UART-Datenformat bei Flugcontrollern und Peripheriegeräten ist **8N1**, also:

* 8 Datenbits.
* Keine Parity.
* 1 Stop Bit.

Dies ist in der Regel der Standardwert der meisten GPS-, Telemetrie- und Flugcontroller-Peripheriegeräte, sodass er in der Praxis selten geändert werden muss.

### Verwendung von UART im Flugcontroller <a href="#uart" id="uart"></a>

In typischen Flugcontroller-Systemen wird UART häufig für folgende Zwecke verwendet:

* Dateneingang von GPS-Modulen.
* Kommunikation zwischen Telemetriemodul und Bodenkontrollstation.
* Serieller Empfängereingang, z. B. bestimmte SBUS-, CRSF- oder andere digitale Empfängerprotokolle.
* Datenaustausch zwischen Companion Computer und Flugcontroller, z. B. MAVLink oder andere Steuer-/Sensorkommunikation.
* Ausgabe einer Debug-Konsole des Systems, um Startmeldungen, Fehlerprotokolle oder eine interaktive Befehlszeile zu prüfen.

### Logische serielle Schnittstellen und physische UARTs <a href="#uart" id="uart"></a>

In einigen gängigen Flugcontroller-Firmwares sind Bezeichnungen wie `SERIAL0`, `SERIAL1` und `SERIAL2`, die Sie sehen, häufig **logische Nummern serieller Schnittstellen** und entsprechen nicht unbedingt direkt UART1, UART2 und UART3 auf dem Chip.

Die Zuordnung zwischen `SERIALx` und physischem UART/USART wird durch die Hardwaredefinitionsdatei festgelegt. Daher kann ein als `SERIAL3` bezeichneter Port auf verschiedenen Flugcontrollern unterschiedlichen physischen Anschlüssen entsprechen.

### Häufige Rollen serieller Schnittstellen <a href="#undefined" id="undefined"></a>

Häufige Rollen serieller Schnittstellen sind USB, Telemetrieport, GPS-Port und benutzerdefinierter Port; die tatsächliche Zuordnung hängt jedoch von der Hardware der Platine ab.

Bei ArduPilot entspricht beispielsweise `Serial 0` in der Regel USB, `Serial 1` und `Serial 2` werden häufig für Telemetrie, `Serial 3` und `Serial 4` häufig für GPS verwendet, während die weiteren seriellen Schnittstellen möglicherweise für andere Zwecke reserviert oder standardmäßig deaktiviert sind.

### Protokollkonfiguration <a href="#undefined" id="undefined"></a>

In Flugcontroller-Firmwares, die eine parametrisierte Verwaltung serieller Schnittstellen unterstützen, ist ein UART nicht nur eine Leitung, sondern es muss auch festgelegt werden, welches Protokoll er trägt.

Bei ArduPilot kann `SERIALx_PROTOCOL` beispielsweise auf verschiedene Verwendungen wie GPS, MAVLink, RC Input, ESC Telemetry, DisplayPort, Rangefinder, OpticalFlow oder DDS XRCE eingestellt werden. Das bedeutet, dass derselbe physische Port über Parameter unterschiedlichen Peripheriegeräten neu zugewiesen werden kann.

### Erweiterte serielle Optionen <a href="#undefined" id="undefined"></a>

Manche Flugcontroller bieten zusätzlich erweiterte UART-Einstellungen, z. B. RX/TX-Invertierung, Halbduplex, RX/TX-Tausch, Pull-up/Pull-down und Steuerung des DMA-Verhaltens.

ArduPilot fasst diese Funktionen in `SERIALx_OPTIONS` zusammen und weist darauf hin, dass manche Funktionen nur auf bestimmten MCU-Klassen oder bestimmten Platinen unterstützt werden. Daher müssen Sie vor der Einstellung die Fähigkeiten der Hardware prüfen.

### Empfänger und UART <a href="#uart" id="uart"></a>

Manche seriellen Empfängerprotokolle können direkt an einen gewöhnlichen UART angeschlossen werden, aber nicht in allen Fällen funktioniert dies nach dem Plug-and-Play-Prinzip.

Die ArduPilot-Dokumentation erwähnt beispielsweise, dass jeder unterstützte UART möglicherweise für den RC-Eingang verwendet werden kann, Protokolle wie SBUS oder FPort jedoch eine Invertierung erfordern können. Unterstützt der UART selbst keine Invertierung, ist möglicherweise ein zusätzlicher Hardware-Inverter erforderlich.

### Debug-Konsole <a href="#undefined" id="undefined"></a>

UART ist auch eine gängige Möglichkeit, auf die Low-Level-Debug-Konsole des Flugcontrollers zuzugreifen.

In diesem Modus kann UART verwendet werden, um Startmeldungen, Startfehler, Sensorstatus und Diagnoseinformationen anzuzeigen. Wenn der Flugcontroller nicht normal startet, USB nicht erkannt wird oder die Firmware fehlerhaft ist, ist der Debug-UART daher oft ein sehr wichtiger Ansatzpunkt für die Fehlersuche.

### Kabel und Störfestigkeit <a href="#undefined" id="undefined"></a>

UART ist im Grunde kein Bus für lange Strecken oder hohe Störfestigkeit; daher sind Kabelqualität und Leitungsführung wichtig.

Halten Sie bei höheren Baudraten die Kabel möglichst kurz und verringern Sie Störungen durch Verdrillen. Werden beispielsweise TX mit GND und RX mit GND paarweise verlegt, ist die Verbindung stabiler als bei lose parallel geführten Leitungen.

### Spannungskompatibilität <a href="#undefined" id="undefined"></a>

Der UART-Logikpegel der meisten modernen Flugcontroller-MCUs beträgt 3.3V. Ein direkter Anschluss an ein 5V-UART-Gerät kann daher zu Instabilität führen oder sogar die MCU beschädigen.

Wenn ein Peripheriegerät einen 5V-Logikpegel verwendet, sollten Sie zunächst prüfen, ob dessen Ausgang 3.3V-kompatibel ist; bei Bedarf sollte ein Pegelwandler eingesetzt werden, statt die Geräte direkt zu verbinden.

### Häufige Probleme <a href="#undefined" id="undefined"></a>

Die folgenden Ursachen sind die häufigsten UART-Probleme:

* **TX / RX vertauscht**: Am häufigsten und sollte zuerst geprüft werden.
* Baudrate **stimmt nicht überein**: Typisches Symptom ist Zeichensalat oder gar keine Daten.
* **Fehlende gemeinsame Masse**: Beide Seiten scheinen korrekt verbunden, aber das Signal kann nicht richtig erkannt werden.
* **Inkompatible Spannung**: Das Mischen von 3.3V- und 5V-Logik kann zu Ausfällen oder Schäden führen.
* **Zu lange Kabel oder schlechte Leitungsführung**: Probleme treten besonders bei hohen Baudraten, Motorstörungen oder Vibrationen auf.
* **Serielle Schnittstelle bereits durch eine andere Funktion belegt**: Der physische Port ist richtig angeschlossen, aber die Firmware-Parameter haben ihn einem anderen Protokoll zugewiesen.

### Empfohlene Reihenfolge der Fehlersuche <a href="#undefined" id="undefined"></a>

Wenn die UART-Kommunikation gestört ist, wird empfohlen, die folgenden Punkte der Reihe nach zu prüfen:

1. Stellen Sie sicher, dass TX mit RX, RX mit TX und GND mit GND verbunden ist.
2. Stellen Sie sicher, dass beide Seiten dieselbe Baudrate verwenden.
3. Stellen Sie sicher, dass das Datenformat dem erwarteten Wert entspricht, in der Regel 8N1.
4. Stellen Sie sicher, dass dem physischen Anschluss in der Firmware das richtige Protokoll zugewiesen ist.
5. Stellen Sie sicher, dass der Logikpegel des Peripheriegeräts mit dem Flugcontroller kompatibel ist.
6. Stellen Sie sicher, dass Kabellänge, Lötstellen und Stecker zuverlässig sind.
7. Beobachten Sie bei Bedarf die TX/RX-Signale direkt mit einem Oszilloskop oder einem USB-UART-Werkzeug.

### Hinweise <a href="#undefined" id="undefined"></a>

**Hinweis:** UART ist kein gemeinsam genutzter Mehrpunktbus. Ein TX/RX-Paar sollte in der Regel nur mit einem entsprechenden Gerät verbunden werden, es sei denn, Sie wissen genau, dass das Protokoll und die Hardwarearchitektur eine spezielle Verschaltung zulassen.

**Hinweis:** Verschiedene Flugcontroller ordnen Bezeichnungen wie „GPS“, „TELEM1“, „UART4“ und „SERIAL3“ möglicherweise unterschiedlich zu. Gleichen Sie vor der Verkabelung sowohl die Hardware-Pintabelle als auch die Parameterkonfiguration der Firmware ab.

**Hinweis:** Eine hohe Baudrate ist nicht unbedingt besser. Wenn das Datenaufkommen des Peripheriegeräts gering ist, ist eine konservative und stabile Baudrate in der Regel zuverlässiger als das Streben nach hoher Geschwindigkeit.
