Überabtastung bei asynchroner serieller Schnittstelle

[Frank Peters (Gast)]

Hallo

Ich habe ein kleines Verständnisproblem.
Wozu dient die Überabtastung bei einer asynchronen seriellen
Schnittstelle?

Meine Überlegungen waren: 1. zur Fehlererkennung und 2. zur
Flankenerkennung für die Synchronisierung

Zu 1. Ich habe irgendwo mal gelesen, daß ein Nutzbit ca. 3 mal
abgetastet wird um es von Störspitzen zu unterscheiden. Stimmt das ?
zu 2. Es wird Überabtastung benötigt um die Flanken einwandfrei zu
ermitteln um somit das Startbit zu erkennen. Stimmt das ?

Dann stellt sich mir noch einige Fragen:
Wie läuft das genau mit der Synchronisierung?
Wird das ankommende Byte in einem Latch gespeichert bis die
Synchronisation erfolgt ist?
Wenn ich nur Einsen ( also %11111111 )übertrage wie erkennt die
Schnittstelle dann das Stopbit?

Ich weiß Fragen über Fragen, aber über eine Antwort oder einen Link wo
ich die Antwort finde würde ich mich sehr freuen. ( Ich brauche es für
eine Klausur )
Alles was ich bis jetzt gefunden habe war das sich der Empfänger auf
das Startbit synchronisiert. Aber wie das verstehe ich nicht.

Vielen Dank im Voraus

[Karl heinz B. (kbucheg)]

Nehmen wir ein praktisches Beispiel:
Sagen wir mal du vereinbarst mit deinem Kumpel ein Nachrichtensystem.
Dieses System beruht auf binären Zuständen. Immer wenn dir dein
Kumpel eine 1 miteilen möchte legt er in einen Raum ein Taschentuch
hinein und wenn er dir eine 0 mitteilen möchte, legt er kein Taschen-
tuch hinein. Weiters vereinbart ihr: Egal ob er ein Taschentuch
hineinlegt oder nicht, den Zustand muss er genau 20 Minuten so
lassen. D.h. erst nach 20 Minuten darf er entscheiden ob das
taschentuch für eine weitere 1 drinnen liegen bleibt oder
ob er es für eine 0 herausnimmt.

Weiters: Weder du noch er haben die Zeit, ständig im Raum
anwesend zu bleiben. D.h. er geht rein, legt das Taschentuch
hin oder nimmt es weg und geht raus. Selbiges bei dir: Du kannst
zu jedem beliebigen Zeitpunkt in den Raum gehen und Nachsehen ob
es da ein Taschentuch gibt oder nicht. Aber: danach musst du kehrt
machen und rausgehen.

Weiters vereinbart ihr, dass eine Nachricht von ihm immer mit
einer 1 beginnen muss. Diese 1 ist nicht Bestandteil der Nachricht.

Weiters möchtet ihr einen gewissen Fehler erlauben. Dein Kumpel
steht ja nicht mit einer Stoppuhr rum und wartet auf die exakte
Sekunde wenn er wieder in den Raum darf. Es kann also schon
sein, dass er mal nach 19 Minuten wieder reinkommt und ein
anderes mal erst nach 21 Minuten.

Soweit klar?

Damit du den Anfang seiner nachricht nicht verpasst, wirst du
öfter als alle 20 Minuten nachschauen muessen. Länger wäre fatal,
denn dann könnte es ja passieren, dass dein Kumpel eine 1
hinterläßt und wieder rausnimmst und da du nur alle 30 Minuten
nachsiehst, verpasst du das ganz einfach.
Wenn du in den Raum hineinschaust und ein Taschentuch vorfindest
(das für die erste 1) weisst du ja nicht wie lange diese 1 schon
drinnen ist. Das solltest du aber wissen, denn wenn du nach
exakt 20 Minuten wieder in den Raum gehst und ein Taschentuch
siehst, weist du nicht, ob das jetzt noch die 1 von dem ersten
Bit war oder nicht.
Es könnte ja sein, dass du beim ersten mal genau nach deinem
Kumpel in den Raum geplatzt bist, das Taschentuch also erst
wenige Sekunden dalag als du reingekommen bist. Wenn sich
Dein Kumpel jetzt um die erlaubte 1 Minute verspätet, dann war er
bei deinem 2-ten Besuch noch gar nicht da und du siehst immer noch
das Taschentuch vom ersten Bit.
Es könnte aber auch sein, dass das Taschentuch schon länger, sagen
wir mal 15 Minuten da lag bevor du es zum ersten mal siehst und
das Tschentuch 20 Minuten später bereits die erste 1 vom Datenbit
anzeigt.
So wie es jetzt ist, hast du keine Chance die beiden Fälle zu
unterscheiden.
Dein Hauptproblem ist es also, möglichst exakt (natürlich
in Grenzen, denn wie gesagt ihr habt beide keine Zeit ständig
im Raum zu bleiben), den Zeitpunkt mitzukriegen, an dem das
taschentuch das erste mal auftaucht.
Also wechselst du deine Strategie: du schaust alle 5 Minuten
nach. Wenn du also bei einem Besuch ein Taschentuch entdeckst,
dass vorher noch nicht da war, dann hat das Startbit irgendwann
in den letzten 5 Minuten begonnen. Soweit so gut.  Bei deinen
nächsten 3 Besuchen müsste das Taschentuch noch immer da sein.
Wenn es nicht da ist, dann war das erste Taschentuch eine 'Störung'
(da fällt mir jetzt keine Entsprechung ein. Vielleicht hat der Wind
ein Tuch zum Fenster hereingeweht, oder so) und alles fängt
von vorne an. Aber angenommen das Taschentuch ist die ganze Zeit
über da: Eine Übertragung hat begonnen. Bei deinem 4. Besuch
(also nach 20 Minuten) siehst du immer noch ein Taschentuch.
Aus den gleichen Gründen wie oben, kannst du nicht sicher sein,
ob es sich immer noch um das Startbit handelt oder ob es schon
das erste Nutzbit ist. Also wartest du wieder 5 Minuten und
siehst noch mal nach. Ist das Taschentuch immer noch da, dann
ist das tatsächlich das erste Nutzbit. Ist es weg, dann war
es beim vorhergehenden Besuch noch vom Startbit übrig und Dein
Kumpel hatte sich nur etwas verspätet.

Tja. und so geht das dahin.Du benutzt also mehrere Messungen
um den Zustand des Bits festzustellen. Der allerersten kannst
du nicht vertrauen, da ihr beide den Zeitablauf nicht exakt
einhalten könnt. Die 2. Messung ist da schon aussagekräftiger
könnte aber immer noch eine Störung sein. Erst wenn die 2.
Messung mit der 3. übereinstimmt traust du der Sache
und merkst dir das Bit.

> Wie läuft das genau mit der Synchronisierung?
> Wird das ankommende Byte in einem Latch gespeichert bis die
> Synchronisation erfolgt ist?

Das ergibt keinen Sinn. Damit das byte zwischengespeichert
werden kann, muss es schon empfangen worden sein. Damit es
empfangen werden konnte, muss sich der Empfänger mit dem
Sender schon synchronisiert haben. Synchronisation bedeutet
ganz einfach, dass der Empfänger sich möglichst exakt auf
die startende Flanke des Senders einklinkt.

[Frank Peters (Gast)]

Hi

Vielen Dank soweit.
Zum ersten Teil habe ich keine Fragen mehr.
Aber zum zweiten Teil.

Sagen wird ich habe einen Systemtakt von 2 MHz ( 68HC11 ).
Wenn jetzt ein Startbit an der seriellen Schnittstelle erkannt wird,
also die negative Flanke erkannt wird. Der Systemtakt aber um ,ich sage
mal , 0,1 µs voreilt, d.h. die negative Flanke des Systemtakts 0,1 µs
vorher da war, wird dann bis zur nächsten negativen Flanke des
Systemtakts "gewartet"? Und ist dann erst die Synchronisation
abgeschlossen?
Oder wie läuft das?

Synchronisation bedeutet doch das Systemtakt und äußerer Datentakt
identisch sein müssen ( bis auf ein paar Prozent ).
Was passiert also wenn sie nicht gleich sind?
Wartet das System mit dem einlesen ins Datenregister bis zur nächsten
negativen Flanke?

Grüße

[Juergen Schuhmacher (Gast)]

"Synchronisation bedeutet, dass der Empfänger sich möglichst exakt auf
die startende Flanke des Senders einklinkt."

Ja, aber da das oft nicht geht, braucht es die Übertastung:

Ein Beispiel aus meiner Praxis: 16 galvanisch getrennte Minisysteme mit
je einem AVR-Tiny11 senden auf ungefähr 1kHz. Dies tun sie auf jeweils 2
Kanälen synchron. Da sie aber vollkommen autark sind, haben sie eigene
Quarze und sind optisch angekoppelt. Sie aquirieren ihre Daten
vollkommen selbständig, senden aber nicht hunderprozentig zyklisch und
obendrein sind es instabile Takte infolge billiger Quarze. die
Freuquenz ist also statisch und dynamisch verstimmt.

Der empfangende Prozessor kann sich aber nicht mit 32 Empfangsschleifen
auf die Empfangsfrequenz abstimmen. Er läuft fest mit einer Frequenz.
Ich mache nun folgendes:

Eine einzige ISR wird von einem Timer getriggert, der etwas schneller
läuft, als die höchste auftretende Freuqenz x Oversampling. Als
oversampling nutze ich hier den Faktor 5. Ich taste den Port stur ab
und übertrage die bits bitweise in ein Array. Dabei werden jedoch nur
die Bits eingelagert, bei denen die ISR in einem Maskenregister eine 1
sieht. Dort stehen Einsen genau dann, wenn der betreffenede Kanal als
"sendend" eingetuft wird. Dies wird er, wenn er zweimal
hintereinander eine Null = Startbit gesehen hat. Je Kanal zählt ein
Zähler die zu erwartenen Samples mit und schaltet dann ab. Die Zahl der
Samples ist die niedirgste Jitterfrequenz x Bitlänge + Zugabe.

Faktisch führt dies dazu, das in diesem Puffer (der recht klein ist,
gegen andere Verfahren) immer komplette Bitströme liegen, beginnend mit
der ersten Null einer Sendeoperation. Sobald die ISR ein Zählerende
gefunden hat, wird ein Signal gesendet, daß einen Ausleseprozess für
diesen einen Kanal in der main startet. Zudem wird dieser Kanal wieder
auf Warten geschaltet. Die main verfügt über einen Ausleseprozess der
bei Erhalt dieses Signals den Puffer für dieses Bit ausliest und
prozessoert. Durch die Pausen im Senden ist sichergestellt, daß der
Prozess in der main Zeit genug hat, alles zu prozessieren, bevor neue
Daten kommen.

Beim Prozessieren wird der Bitstrom niederfreuqent gemittelt und
analysiert. Dabei finden sich je Bit mal 4, mal 5 und auch 6 samples,
je nachdem wie der Sende-Tiny gerade gejittert hat, wann der
Abtastprozess kam und wie hoch die Grundsendefrequenz lag. Dieser
Samplebitstrom wird dann interpretiert, wobei sich der Ausleseprozess
immer wieder neu nach Massgabe entdeckter Flanken auf den Strom
synchronisert - jeweils aber immer nur um 1 Bit verlängernd (daher die
Bedingung "etwas schneller als Freq+ Jitterhub" v.o). (Die
Flankendetekttion ist immer nur uim Umfeld von +/1 Sample der
erwarteten Flanke aktiv, wobei Bitwechsel durch zwei folgebits
bestätigt sein muss)

Ein Beispiel für eine Folge wäre also
0000.11111.11110.00000.00001.1111.0000

Nun kann man des erste und letzte Sample eines Bits verwerfen und die
mittleren 3 zu einem Mehrheitsentscheid heranziehen, wobei sogar Peeks
durch EMV eliminiert werden.

Das ganze wird in einer Schleife realisiert und läuft genau solange,
wie es samples sind. Hier 32 bit, mit 11 Bit pro Byte = 44x5 > 220
samples.

Dieses Verfahren habe ich auch früher schonmal erfolgreich angewendet.
Damals waren es 7 samples. Trotz hohem Jitter hatte man immer 4,
meistens jedoch 5 Samples, um ein Bit zu rekonstruieren. Da man auch
noch ein Paritybit hat, kann man immer entscheiden, ob das so gewonnene
Byte ok war. Trotz hoher Störungen auf den Leitungen (EMV-Beschuss) und
durchschnittlich 2-3 Bitfehlern je Sendezyklus hatte man nur alle
2000-3000 Zyklen den Fall, daß ein Byte falsch war und rausgeworfen
wurde.

[Chief Brady (Gast)]

Also ich kenne das (von den PIC's) so:

Der RX-Pin wird mit der 16fachen Baudrate abgetastet. Wird ein Startbit
 (=0) bei der ersten fallenden Flanke der Abtastung erkannt, wird ab
dann immer bei der 7. 8. und 9. fallenden Flanke das Signal geprüft.
Das ist ca. die Mitte des Bits. Sind alle drei Abtastergebnisse
identisch, ist das Bit erkannt. Sind sie unterschiedlich liegt ein
Übertragungsfehler vor.

Zum Stopbit:
Bei z. B. 8N1 (1 Startbit, 8 Datenbits, 1 Stoppbit) muss das 10 Bit
eben eine "1" sein (Stop-Bit), wenn nicht -> Framing-Error.

[Juergen Schuhmacher (Gast)]

Klar: Je mehr Abstandwerte, deste präziser ist das. Problem: Wenn man
das in Software macht, muss ein Prozess ständig nachsehen, wo die
Flanken liegen, ob sich was tut und verwalten. Das muss immer
timergesteuert über interrupts laufen. Dann braucht man bei mehreren
Kanälen sehr viele INTs oder lange ISRs und das kostet ordentlich
Rechenzeit und CPU-Leitung und bremst andere ISRs aus. Die Prozzis in
prof. Anwendungen sollen ja möglichst noch was anders tun, als nur den
ganzen Tag UART spielen :-)

Im Übrigen: Wenn die Empfangsfreuqenz genügend genau der Sendefrequenz
entspricht (max ein halbes Bit vErsatz über den Empfangszeirauum von n
Bit), kann man es auch mit nur 2 samples je Bit(simples
Einsynchronsieren) schaffen, allerdings braucht man dann einen
auswändigeren Postprozessor. (Nur in langsamen-Applikationen sinnvoll,
bzw in VHDL bei sehr schnellen Signalen).

[Thomas O. (Gast)]

ein AVR bei 16MHZ hat eine Taktzeit von 62,5 nSek bei einem seriellen
Verbindung die im kHz Bereich arbeitet ist da überhaupt keine Erhöhung
der Abtastung erforderlich, so ungleichmäßig kann ein µC garnicht
laufen um nicht nach der Synchronisation in der vorgeschriebenene Zeit
den Pegel eines Bits abzufragen. Schau dir das mal an dann wird dir
bestimmt einiges klar.

http://de.wikipedia.org/wiki/Bild:RS-232_timing.png

Bei einer Baudrate von 115.200 hat man also 8,68 µs Zeit um den Pegel
des Bits festzustellen. Das wird dann aber meist in der Mitte dieser
Zeit durch den UART gemacht so das es nach vorne und hinten ausrechend
Reserve gibt um nicht das falche Bit abzutasten.

[Frank Peters (Gast)]

Alles klar ich denke ich habe es verstanden.

Vielen Dank!