Grundlagen UART: TX & RX Fehler

Icke schrieb:

> Warum in einigen Datenblättern auch ein
> TX-Fehler angegeben ist verstehe ich jedoch nicht.

Wenn bei einer Takterzeugung für eine UART beispielsweise 1,3% Fehler 
drinstehen, dann heisst das nicht, dass 1,3% aller Bits oder Bytes 
fehlerhaft sind, sondern dass der Takt um 1,3% neben dem Sollwert liegt.

Diesen Wert muss man auf beiden Seiten berücksichtigen, ggf. mit 
Vorzeichen. Wenn der Sender in der Frequenz um 1,3% zu hoch und der 
Empfänger um 1,7% zu tief liegt, dann beträgt der Gesamtfehler 3% und es 
wird schon arg knapp. Sind beide Vorzeichen gleich, dann sind es nur 
0,4% und das reicht locker.

Siehe Baudratenquarz

@  Ralf (Gast)

>Toleranzen der Quarze etc. fallen auch noch n bisschen mit ins
>Gewicht...

Kaum. Selbst ein Gurkenquarz mit +/-100ppm =0,01% hat keinerlei 
praktischen Einfluß.

MfG
Falk

Icke schrieb:

> Und wie sieht es jetzt mit der Fehlerwahrscheinlichkeit aus?

Damit haben diese Zahlen und Formeln rein garnichts zu tun. Die 
Fehlerwahrscheinlichkeit lässt sich auch nicht allein aus der Baudrate 
errechnen, den das Zeitverhalten der Pegelwandler/Transceiver spielt 
dabei auch eine Rolle.

> Ich schaffe es noch immer nicht mit den angegeben Gleichungen auf die in
> der Tabelle angegeben Fehlerraten zu kommen.

Ich habe zwar dieses Manual nicht gelesen, bin aber einigermassen 
sicher, dass du so etwas wie Fehlerraten darin nicht finden wirst. Nicht 
jede Prozentangabe ist eine Wahrscheinlichkeit.

Ok, ich habe mal ins Manual reingesehen. Ist etwas komplizierter als bei 
anderen UARTs.

UARTs sind traditionell meist recht simpel gestrickt. Der Baudratentakt 
wird durch 16 geteilt - manchmal ist auch 8 möglich. Daraus ergibt sich 
die verwendete Baudrate. Mit dem Startbit wird dieser 16-er Zähler 
gestartet und auf Halbzeit wird das Bit ausgewertet, oft als 
Mehrheitsentscheid bei 3 Abtastungen um diese Halbzeit herum.

Nachteil dieser Methode ist, dass sich aus "geraden" Taktfrequenzen wie 
1MHz selten die üblichen Baudraten genau genug ergeben, weshalb der 
taditionelle Ansatz in der Verwendung von Baudratenquarzen für die 
Taktgenerierung besteht. Das passt nicht jedem: Wer mal versucht hat, 
38400bd asynchron und 500Kbps CAN unter einen Hut zu bringen weiss was 
ich meine - eine der beiden Rate kann nicht exakt sein.

Neuere Controller grösserer Ordnung verwenden deshalb nicht selten eine 
Baudratengenerierung mit fraktionalem Vorteiler. Wie das exakt 
funktioniert ist dort selten angegeben, auch eine exakte Fehlerrechung 
findet sich selten. Was den Vorteil hat, dass man sich da nicht 
durchwühlen muss. Und den Nachteil hat, dass man den Faktor 16 immer 
noch im Boot hat, also bei niedrigen Taktfrequenzen trotzdem nur 
niedrige Baudraten hinbekommt. 4800bd bei 32KHz Takt sind da nicht drin.

TI ist mit dem USCI des MSP430 einen deutlich anderen Weg gegangen. 
Sowohl in der Technik, als auch in der Dokumentation. Die dabei 
verwendete Technik spart aufgrund niedriger Taktfrequenzen Strom, ist 
aber nicht wirklich leicht verständlich und leider auch strunzdumm 
erklärt. Aber man kann 4800bd bei 32KHz Takt verwenden.

Vollständig verstanden habe ich die Sache in der Kürze auch nicht, aber 
mir scheint, dass sich anders als bei der traditionellen Methode, deren 
Abweichung sich leicht als prozentualer Taktfehler rechnen lässt, bei 
der TI Methode ein Jitter ergibt. Die gesendete Signalflanke wie auch 
der Abtastpunkt beim Empfang landen je nach Quelltakt, Parameter und 
Bitposition mal vor mal nach dem eigentlich korrekten Zeitpunkt.

Beim Empfang gibt es dann zusätzlich noch einen Zeitfehler, der durch 
die Abtastung des Signals entsteht. Das Startbit wird nicht sofort mit 
der negativen Flanke verwendet, sondern das Signal wird zunächst mit dem 
Takt synchronisiert und dann erst wird die Änderung zur Synchronisation 
der Zeitbasis verwendet. Dadurch entsteht ein zusätzlicher Fehler von 
maximal einem Taktzyklus.

Das ist zwar traditionell auch nicht anders, aber wenn der Sample-Takt 
das 16fache der Baudrate beträgt, dann ist dieser Fehler wenig relevant 
und wird pratisch nie betrachtet. Bei einem 4-er Takt (9600bd bei 32KHz) 
ist dieser Abtastfehler jedoch nicht mehr zu vernachlässigen. Darin 
liegt der Grund für höhere Fehlerwerte bei Rx als bei Tx, und weshalb 
dies abhängig vom Taktverhältnis ist.

Icke schrieb:

> Ziel ist es, dass ich nicht nur die Grundlagen verstehe, sondern ich
> möchte/soll die Paketfehlerrate (PER) dieser Kommunikation berechnen.
> Und da tappe ich gerade völlig im Dunkeln,

Ich fürchte, das wirst du auch dann noch, wenn du die TI'sche Rechnung 
vollständig verstanden hast. Weil dafür mehr als nur der UART-Fehler 
massgeblich sein dürfte, denn üblicherweise fragt man nur dann nach 
einem PER, wenn sich zwischen Tx und Rx mehr befindet als nur ein Stück 
Draht. Und dann ist die TI'sche Rechnung nur ein Teil der 
Gesamtrechnung.

Ohne zusätzliche Komponenten zwischen Tx und Rx wird die Kommunikation 
entweder fehlerfrei funktionieren, oder abhängig von den übertragenen 
Daten weitgehend Schrott ergeben. Für eine PER sorgt der Kram 
dazwischen, bereichert um den TI'schen Taktfehler. Der TI'schen Anteil 
ist deterministisch.

Aber um deinen grauen Zellen weiteres Futter zu geben: Der sich aus dem 
UART-Verhalten ergebende Fehler ist abhängig von den übertragenen Daten. 
0x40 ist deutlich kritischer als 0xFB.