Skip to content
RFrftools.io
Protocol7. Mai 202612 Min. Lesezeit

UART-Baudraten erklärt: Von unbrauchbaren Zeichen zu zuverlässigen seriellen Verbindungen

Ein praktischer Leitfaden zu UART-Baudraten — warum es 9600 und 115200 gibt, wie Taktfehler Framing-Fehler verursachen, funktionierende Beispiele mit echten MCUs und die 2-%-Regel, die jeder Embedded-Ingenieur kennen muss.

Inhalt

Der Moment, den jeder hatte

Ihr verkabelt zwei Platinen. TX zu RX, RX zu TX, Erde zu Erde. Du flashst deine Firmware, öffnest den seriellen Monitor und... wirfst Müll.ÿÿÿÿoder⸮⸮⸮⸮oder vielleicht gar nichts. Du überprüfst die Verkabelung. Du tauschst TX und RX aus (jeder macht das mindestens einmal). Immer noch Müll.

Dann fragt jemand: „Auf welche Baudrate sind Sie eingestellt?“

Und da ist sie. Die eine Seite spricht bei9600, die andere hört bei115200zu. Die elektrischen Signale sind perfekt — Spannungspegel, Verkabelung, alles ist in Ordnung — aber die beiden Geräte sprechen mit völlig unterschiedlichen Geschwindigkeiten. Es ist, als würde man versuchen, ein Buch zu lesen, während jemand die Seiten mit dreifacher Geschwindigkeit blättert. Die Charaktere sind alle da; man kann sich einfach keinen Reim auf sie machen.

Dies ist der häufigste serielle Kommunikationsfehler in eingebetteten Systemen, und er ist vollständig vermeidbar, wenn Sie erst einmal verstanden haben, was Baudrate eigentlich bedeutet und warum sie für UART so wichtig ist.


Was ist eigentlich die Baudrate

Die Baudrate ist die Anzahl der Signalübergänge — Symbole — pro Sekunde auf der Leitung. Speziell bei UART besteht jedes Symbol aus einem Bit, sodass die Baudrate der Bitrate entspricht. Wenn Sie115200Baud einstellen, weisen Sie den Sender an, die Netzspannung alle 1/115200 Sekunden zu ändern, was etwa 8,68 Mikrosekunden pro Bit entspricht.

Hier ist der entscheidende Punkt: UART hat kein Uhrkabel. Im Gegensatz zu SPI oder I2C gibt es kein separates Signal, das dem Empfänger mitteilt, wann er abtasten muss. Beide Seiten generieren unabhängig voneinander ihr eigenes Timing aus ihren eigenen Uhren. Sie müssen sich nur vorher auf die Geschwindigkeit einigen.

Stellen Sie sich das wie zwei Personen vor, die ein gemeinsames Tickerband lesen. Es gibt keine Glocke, die bei jedem Buchstaben klingelt — beide haben sich nur darauf geeinigt, alle 8,68 Mikrosekunden auf das nächste Zeichen zu schauen. Wenn die Uhr einer Person 5% schnell läuft, fängt sie irgendwann an, die falschen Zeichen zu lesen. Genau das passiert mit UART, wenn die Uhren nicht übereinstimmen.

Der Empfänger erkennt den Anfang eines Bytes, indem er auf das Start-Bit achtet — einen Übergang von High (Idle) zu Low. Sobald er die fallende Flanke sieht, startet er seinen internen Timer und tastet die Datenbits in den erwarteten Intervallen ab. Wenn die Baudrate auch nur geringfügig abweicht, wird, wenn Bit 7 oder das Stoppbit erreicht ist, im falschen Moment abgetastet.


Die Standard-Baudraten (und warum diese komischen Zahlen)

Wenn Sie überhaupt mit Serien gearbeitet haben, haben Sie die üblichen Verdächtigen gesehen:

BaudrateBitperiodeHerkunft
7513,3 msTelegraph (Baudot-Code)
1109,1 msTeletyp ASR-33
3003,33 msFrühe akustische Modems
1200833 µs1200-Baud-Modem-Ära
2400417 µsV.22-Standard
9600104 µsDe facto „sicherer Standard“
1920052,1 µs2 × 9600
3840026,0 µs4× 9600
5760017,4 µsOddball (nicht 6× 9600)
1152008,68 µsStandardmäßiger „schneller“ UART
2304004,34 µs2 × 115200
4608002,17 µsFür viele MCUs optimiert
9216001,09 µsIn der Nähe des Grenzwerts
Warum diese spezifischen Zahlen? Es sind historische Unfälle, die hängen geblieben sind. 75 Baud stammt aus der Zeit der Telegraphen — der Baudot-Code verwendete 5-Bit-Zeichen, und 75 Baud gaben dem Bediener Zeit, den Ausdruck zu lesen. 110 Baud war die Geschwindigkeit des Teletype Model 33, die durch die mechanischen Einschränkungen des Druckkopfs bestimmt wurde. 300 Baud war die erste weit verbreitete Modemgeschwindigkeit (die akustischen Kupplungen, in die man einen Telefonhörer stecken würde). Von da an verdoppelte sich jede Generation ungefähr: 1200, 2400, 4800, 9600. Dies sind jedoch keine Zweierpotenzen — sie sind Vielfache von 300.

Warum ist also57600im Standardsatz und nicht56400(was ein saubereres Vielfaches wäre)? Es ist115200 / 2, und115200selbst stammt aus dem 8250-UART-Chip, der in IBM-PCs verwendet wird. Der 8250 hatte einen 1,8432-MHz-Oszillator, und mit einem Divisor von 1 erhielt man 115200 Baud (1843200/16 = 115200). Das Oversampling mit dem Teiler von 16 ist in die Hardware eingebaut.

Das Ergebnis: Wir verwenden alle immer noch Baudraten, die von einer 1981 gewählten Kristallfrequenz diktiert werden.

Warum 9600 die universelle Standardeinstellung ist9600Baud ist langsam genug, um mit fast jeder Taktquelle, jeder Kabellänge unter ein paar Metern und jedem UART-Peripheriegerät zu funktionieren — auch mit den einfachsten. Es ist die Geschwindigkeit, die „einfach funktioniert“. GPS-Module sind standardmäßig darauf eingestellt. Bootloader benutzen es. Wenn Sie nicht wissen, mit welcher Geschwindigkeit ein Gerät spricht, versuchen Sie es zuerst mit9600.

Aber9600ist auch schmerzhaft langsam für alles, was über kurze Textnachrichten hinausgeht. Bei 10 Bit pro Frame (8N1-Format) erhalten Sie 960 Byte pro Sekunde. Das Drucken eines 1-KB-Debug-Logs dauert über eine Sekunde. Deshalb wird bei den meisten Entwicklungsarbeiten115200verwendet — er ist 12-mal schneller und trotzdem zuverlässig mit jedem modernen MCU-Kristall.


Funktioniertes Beispiel: GPS-Modul stimmt nicht überein

Nehmen wir an, Sie haben ein u-blox NEO-6M GPS-Modul. Es gibt standardmäßig NMEA-Sätze mit9600Baud aus. Ihre STM32-Firmware konfiguriert USART2 versehentlich gemäß115200. Was passiert?

Das GPS sendet ein$-Zeichen (ASCII 0x24, binär00100100). Auf der Leitung mit9600Baud ist jedes Bit 104,17 µs breit. Der gesamte 10-Bit-Frame (Start + 8 Daten + Stopp) dauert 1,042 ms.

Aber Ihr STM32 tastet bei115200ab — es werden Bits mit einer Breite von 8,68 µs erwartet. Wenn es die fallende Flanke des Startbits sieht, beginnt es alle 8,68 µs mit dem Sampling. In der Zeit, die das GPS benötigt, um EIN Bit zu senden (104,17 µs), tastet der STM32 12 mal ab. Es liest 12 „Bits“ aus dem, was eigentlich ein einzelnes Bit ist.

Das Ergebnis: Sie sehen zufällig aussehende Zeichen in Ihrem Terminal. Nicht nur falsche Zeichen — völlig unvorhersehbarer Müll, weil der Empfänger die Wellenform in 12-mal mehr Teile zerlegt als beabsichtigt.

Die Lösung: Passen Sie die Baudrate an. Stellen Sie Ihren STM32 auf9600ein oder konfigurieren Sie das GPS (über UBX-Protokollbefehle) auf115200um. Es gibt keine Verhandlungen, keine automatische Erkennung (in den meisten Fällen) — beide Seiten müssen explizit auf dieselbe Geschwindigkeit konfiguriert werden.

Funktioniertes Beispiel: Sensordatenprotokollierung mit hoher Geschwindigkeit

Sie bauen einen Datenlogger, der einen Beschleunigungsmesser mit 1 kHz (1000 Samples pro Sekunde) liest. Jedes Sample hat X-, Y- und Z-Achsen als 16-Bit-Ganzzahlen sowie einen Zeitstempel. Sie möchten dies über UART auf einen seriellen FTDI-Adapter für die PC-Erfassung streamen.

Lassen Sie uns herausfinden, welche Baudrate Sie benötigen:

Schritt 1: Berechnen Sie die Datennutzlast.
  • 3 Achsen × jeweils 2 Byte = 6 Byte pro Abtastung
  • 4 Byte für Zeitstempel = 4 Byte
  • 2 Byte Overhead (Header + Prüfsumme) = 2 Byte
  • Insgesamt: 12 Byte pro Stichprobe
Schritt 2: Berechnen Sie Byte pro Sekunde.

12 Byte × 1000 Samples/s = 12.000 Byte/Sekunde

Schritt 3: In Bit pro Sekunde umrechnen (unter Berücksichtigung des UART-Overheads) .

Beim Standard-8N1-Framing kostet jedes Byte 10 Bit auf der Leitung (1 Start + 8 Daten + 1 Stopp):

12.000 Byte × 10 Bit/Byte = 120.000 Bit/Sekunde

Schritt 4: Wählen Sie eine Baudrate mit Marge.

Sie benötigen mindestens 120.000 bps. Der nächste Standardtarif ist230400. Aber warte — kannst du115200verwenden? Das ergibt 115.200 Bit/s auf der Leitung, was weniger ist als Ihre Anforderung von 120.000. Sie werden Daten verlieren.

Es ist also230400— Sie erhalten 230.400/120.000 = 92% Kopffreiheit. Das ist ausreichend Spielraum für Interrupt-Latenz, Puffermanagement und gelegentlichen Burst-Traffic.

Alternativ könnten Sie115200verwenden, wenn Sie Ihre Samplerate auf 960 Hz reduzieren (115.200/12/10 = 960). In der Praxis würde ich230400mit der vollen 1-kHz-Rate empfehlen — der Headroom lässt deine Firmware atmen.

Verwenden Sie den UART-Baudratenrechner, um die tatsächlich erreichbare Rate und den Fehler für Ihren spezifischen MCU-Takt zu überprüfen.


Die 2% -Regel — Takttoleranz

Hier wird UART knifflig. Da es keinen gemeinsamen Takt gibt, erzeugen Sender und Empfänger ihre Baudrate von ihren eigenen Oszillatoren. Wenn diese Oszillatoren auseinanderdriften, werden Bits falsch gelesen.

Die Standardtoleranz für eine zuverlässige UART-Kommunikation beträgt ± 2% kumulativer Fehler zwischen beiden Enden. In der Praxis wird in den meisten Referenzen empfohlen, jede Seite unter ± 1% zu halten, sodass die Gesamtabweichung im schlimmsten Fall unter 2% bleibt.

Warum 2%?

UART-Empfänger verwenden 16-faches Oversampling — sie tasten die Leitung 16 Mal pro Bitperiode ab und verwenden die mittleren Abtastwerte (normalerweise 7, 8, 9 von 16 Samples), um den Bitwert zu bestimmen. Dadurch entsteht eine gewisse Toleranz gegenüber Zeitabweichungen.

Bei einem 8N1-Frame (insgesamt 10 Bit) ist das letzte abgetastete Bit Bit #10 (das Stoppbit). Der bis dahin aufgelaufene Fehler ist:

§0 §

Wenn der gesamte Timing-Fehler dazu führt, dass der Abtastpunkt am Ende des Frames um mehr als eine halbe Bitperiode driftet, wird das falsche Bit abgetastet. Rückwärts arbeiten:

Max error per bit=0.510=5%\text{Max error per bit} = \frac{0.5}{10} = 5\%
Aber das ist das theoretische Maximum bei perfekter Startbit-Erkennung. In der Praxis weist die Startbit-Erkennung selbst eine Messunsicherheit von ±0,5 (von 16 Samples) auf, was sich negativ auf Ihren Spielraum auswirkt. In der Praxis liegt der Sicherheitsgrenzwert bei insgesamt etwa 3,75% , und Ingenieure verwenden 2% als konservative Konstruktionsregel.

Wie 2% in der Praxis aussehen

Bei115200Baud bedeutet ein Fehler von 2%, dass die tatsächliche Baudrate irgendwo zwischen 112.896 und 117.504 liegt. Die Bitperiode ist um ±0,17 µs falsch. Bei einem 10-Bit-Frame summiert sich das zu einer Drift von ±1,7 µs — etwa 20% einer Bitperiode. Immer noch sicher, aber Sie verbrauchen Ihren Spielraum.

Bei9600Baud ist ein Fehler von 2% absolut gesehen viel weniger kritisch (±2,08 µs pro Bit, ±20,8 µs pro Frame), weil die Bitperioden so breit sind. Dies ist ein weiterer Grund, warum9600die „sichere“ Standardeinstellung ist — selbst schreckliche Oszillatoren können ihn treffen.


MCU-Taktquellen und Baudratenfehler

Nicht alle Uhren sind für UART gleich:

Kristalloszillator (HSE)

Genauigkeit: typischerweise ±20 ppm (0,002%). Im Wesentlichen perfekt für UART. Jede Standard-Baudrate funktioniert mit vernachlässigbaren Fehlern. Dies verwenden der ESP32, die meisten STM32-Entwicklungsboards und der Arduino Uno (16-MHz-Kristall).

Interner RC-Oszillator (HSI)

Genauigkeit: ± 1% bis ± 5% je nach Temperatur und Spannung. Das interne 8-MHz-HSI des STM32 ist werkseitig auf ± 1% bei 25 °C eingestellt, kann aber über den gesamten Temperaturbereich auf ± 2% abweichen. Der interne 8-MHz-RC-Oszillator des ATmega328P ist zu ± 10% unkalibriert (!) aber ± 2% nach der Werkskalibrierung.

Hier wird es gefährlich. Wenn sowohl Ihr Sender ALS auch Ihr Empfänger RC-Oszillatoren verwenden, kann es zu einer Gesamtanpassung von bis zu 4% kommen. UART fällt zeitweise aus. Es funktioniert auf der Bank bei Raumtemperatur einwandfrei und lässt dann Zeichen im Feld fallen, wenn es heiß oder kalt ist.

Faustregel: Wenn Sie UART über9600Baud ohne Kristall ausführen, berechnen Sie mit dem UART-Rechner Ihren Worst-Case-Baudratenfehler und stellen Sie sicher, dass er unter 2% bleibt.

Das BRR-Divisor-Problem

Selbst mit einem perfekten Kristall erhalten Sie möglicherweise keine exakte Baudrate. Das UART-Peripheriegerät teilt den Takt durch eine Ganzzahl (das BRR-Register), um die Baudrate zu ermitteln:

Actual Baud=fclk16×BRR\text{Actual Baud} = \frac{f_{clk}}{16 \times \text{BRR}}
Wenn die Division nicht gerade ist, erhalten Sie einen Quantisierungsfehler. Zum Beispiel ein 16-MHz-Takt, der versucht,115200Baud zu erzeugen:
BRR=16,000,00016×115200=8.68\text{BRR} = \frac{16{,}000{,}000}{16 \times 115200} = 8.68
Du kannst 8,68 nicht in ein Register laden — es wird auf 9 gerundet. Die tatsächliche Baudrate wird zu:

§4 §

Fehler:(115200111111)/115200=3.55%(115200 - 111111) / 115200 = 3.55\%. Das sind mehr als 2% . Diese spezielle Kombination aus Takt und Baudrate funktioniert ohne Unterstützung für fraktionale Teiler nicht zuverlässig.

Einige MCUs (STM32, SAM, nRF) haben fraktionierte BRR-Teiler, die dieses Problem lösen. Andere (ATmega) nicht — du musst deine Kristallfrequenz sorgfältig wählen. Die klassischen Kristalle mit 7,3728 MHz und 11,0592 MHz gibt es speziell deshalb, weil sie sich gleichmäßig in Standard-Baudraten aufteilen.

KristallBRR für 115200Tatsächlicher BaudFehler
7,3728 MHz41152000,00%
8 MHz4,34 → 41250008,51%
11,0592 MHz61152000,00%
16 MHz8,68 → 91111113,55%
18,432 MHz101152000,00%
48 MHz26,04 → 261153850,16%
72 MHz39,06 → 391153850,16%
Beachten Sie das Muster: 7,3728, 11,0592 und 18,432 MHz ergeben allesamt Nullfehler, weil sie Vielfache von 115200 × 16 × (eine ganze Zahl) sind. Die „runden“ Frequenzen wie 8 und 16 MHz sind für UART tatsächlich schlechter.

Moderne STM32- und ESP32-Chips verwenden Bruchteiler mit 4—8 Bruchbits, wodurch dieses Problem effektiv beseitigt wird. Wenn Sie jedoch mit einem ATmega328P (Arduino Uno) bei 16 MHz arbeiten, ist dieser 3,55-prozentige Fehler bei115200real. Der Arduino-Bootloader verwendet tatsächlich115200und kommt damit durch, weil der FTDI-Chip am anderen Ende kristallgenau und tolerant ist — aber er ist direkt am Rand.


Häufige Fehler

1. Falsche Baudrate im Code

Die Hauptursache für Serienmüll. Überprüfe dreimal, ob beide Seiten übereinstimmen. Häufige Fallen:

  • GPS-Module entsprechen standardmäßig9600, nicht115200- ESP32-Boot-ROM-Ausgänge mit74880Baud (ein seltsamer Wert)
  • Einige Bluetooth-Module (HC-05) verwenden38400für AT-Befehle, aber9600für den Datenmodus
  • Viele Sensoren entsprechen standardmäßig9600, unabhängig davon, was in der Werbung über „High-Speed“ steht

2. Einschränkungen bei Software-UART (Bit-Banging)

Software-UART (zum Beispiel ArduinosSoftwareSerial) generiert Timing in der Software mithilfe von Verzögerungsschleifen. Das bedeutet:

  • Interrupts können das Bit-Timing unvorhersehbar verlängern
  • Die maximale zuverlässige Geschwindigkeit beträgt in der Regel1920038400Baud
  • Die CPU-Last skaliert linear mit der Baudrate
  • Empfangen während des Sendens ist oft unmöglich
Wenn Sie115200oder höher benötigen, verwenden Sie ein Hardware-UART-Peripheriegerät. Immer.

3. Nicht übereinstimmende Spannungspegel (sieht aus wie ein Problem mit der Baudrate)

Ein 3,3-V-UART, der mit einem 5-V-UART kommuniziert (oder umgekehrt), kann zu einer verfälschten Ausgabe führen, die genau wie eine Baudratenfehlanpassung aussieht. Die Schwellenspannung des Empfängers wird nicht sauber überschritten, was zu falschen Startbits und fehlerhaften Daten führt. Überprüfen Sie immer die Spannungskompatibilität, bevor Sie der Baudrate die Schuld geben.

4. UART Overhead vergessen

Neue Techniker berechnen häufig die erforderliche Bandbreite gemäßdata_rate / 8und legen diese als Baudrate fest. Aber jedes Byte kostet 10 Bit (8N1) oder 11 Bit (8E1) auf der Leitung. Der tatsächlich nutzbare Durchsatz von115200Baud mit 8N1 ist:

Throughput=11520010=11,520 bytes/sec=11.25 KB/s\text{Throughput} = \frac{115200}{10} = 11{,}520 \text{ bytes/sec} = 11.25 \text{ KB/s}
Nicht 14,4 KB/s (was 115200/8 wäre). Dieser Overhead von 20% aus Start-/Stopp-Bits ist wichtig.

5. Ohne Berücksichtigung der Temperaturdrift

Ihre UART-Verbindung funktioniert perfekt auf der Bank bei 22 °C. Dann geht sie in ein Produkt über, das bei -20 °C bis +85 °C arbeitet. Der interne RC-Oszillator driftet um 3%, und plötzlich verlieren Sie an kalten Morgen Bytes. Prüfen Sie immer die Spezifikationen des Oszillators für den gesamten Betriebstemperaturbereich.


Wann sollte welche Baudrate verwendet werden

Einige praktische Richtlinien:

  • 9600 — Standard für unbekannte Geräte, GPS-Module, Sensormodule mit seltenen Daten, Bootloader-Fallback. Funktioniert mit jeder Taktquelle.
  • 115200 — Standard für Entwicklung/Debugging, moderate Datenströme, weitestgehend MCU-zu-PC-Kommunikation. Erfordert Kristall oder kalibriertes HSI.
  • 230400460800 — Sensorprotokollierung mit hohem Durchsatz, Firmware-Update über UART, FTDI-basierte Tools. Erfordert Kristall und kurze Kabel (<30 cm).
  • 9216003000000 — Spezialisierte Hochgeschwindigkeitsanwendungen (ESP32-Protokollierung, FTDI bei maximaler Geschwindigkeit). Erfordert aufeinander abgestimmte Kristalle, kurze Leiterbahnen, gutes PCB-Layout. Die Signalintegrität beginnt wichtig zu werden.
Oberhalb von1 Mbaudtreiben Sie UART über das hinaus, wo es bequem ist. An diesem Punkt sollten Sie erwägen, auf SPI (synchron, viel schneller) oder USB (differentiell, störsicher) umzusteigen.

Den Taschenrechner verwenden

Der UART Baud Rate & Frame Timing Calculator auf rftools.io berechnet alles, was wir besprochen haben:

  1. Geben Sie Ihre Ziel-Baudrate ein9600,115200oder was auch immer Ihre Peripheriegeräte benötigen.
  2. Stellen Sie Ihr Rahmenformat ein — Datenbits (normalerweise 8), Stoppbits (normalerweise 1), Parität (normalerweise keine).
  3. Geben Sie Ihre MCU-Taktfrequenz ein — den APB-/Peripherie-Takt, nicht unbedingt den Kerntakt. Prüfen Sie Ihr Datenblatt.
Der Taschenrechner gibt Folgendes zurück:
  • Bit-Periode — wie lang jedes Bit auf dem Kabel ist (nützlich für Scope-Messungen)
  • Bilddauer — Gesamtzeit für ein Zeichen
  • Effektiver Durchsatz — tatsächliche Datenrate nach Abzug des UART-Overheads
  • BRR-Divisor — der genaue Registerwert, den Sie benötigen (für 16-faches Oversampling)
  • Tatsächliche Baudrate — was Sie nach dem Runden einer Ganzzahl wirklich erhalten
< 0.5%), yellow (0.5— 2%), red (>- Baudratenfehler — grün (2%)

Die Fehleranzeige ist die wichtigste Ausgabe. Wenn sie rot ist, wird Ihr Link Probleme haben. Ändern Sie entweder Ihre Taktfrequenz, verwenden Sie einen Bruchteiler (falls Ihre MCU dies unterstützt), oder wählen Sie eine andere Baudrate.


Kurzreferenz: Formeln für die UART-Baudrate

Für alle, die Mathe an einem Ort haben wollen:

Tbit=1Baud Rate(seconds per bit)T_{bit} = \frac{1}{\text{Baud Rate}} \quad \text{(seconds per bit)}
Frame bits=1+Data+Parity+Stop\text{Frame bits} = 1 + \text{Data} + \text{Parity} + \text{Stop}
Throughput=Baud Rate×Data bitsFrame bits(useful bps)\text{Throughput} = \frac{\text{Baud Rate} \times \text{Data bits}}{\text{Frame bits}} \quad \text{(useful bps)}
§9 §
Error=BactualBtargetBtarget×100%\text{Error} = \frac{|B_{actual} - B_{target}|}{B_{target}} \times 100\%
Halten Sie den Fehler unter 2%. Benutze einen Kristall, wenn es auf Geschwindigkeit ankommt. Passen Sie Ihre Baudraten an. Ihre seriellen Links werden es Ihnen danken.

Verwandte Artikel