Hallo zusammen, nehmen wir an, ich schicke über RS232 (mit 8 Bit, 1 Stop-Bit, kein Parity) seeeeeehr viele 'U' (entspricht binär 01010101) ein, dann hat man also eine seeeeeehr lange Abfolge von immer gleich langen Phasen mit High-Pegel und mit Low-Pegel. Kann es dann nicht irgendwann sein, dass der Empfänger nicht mehr weiß, an welchem Bit er gerade dran ist? Woher weiß der Empfänger nach vielen tausend Pegelwechseln noch, was Datenbit und was Stopbit ist? Oder ist es so, dass der Empfänger nach 8 Bits immer damit rechnet, dass als nächstes das Stop Bit kommen MUSS und die darauffolgende steigende Flanke muss dann das Startbit sein, so dass quasi bei jeder steigenden Flanke des Startbits neu synchronisiert wird? Danke und viele Grüße Karl
:
Bearbeitet durch User
Das UART ist ein Stueck Hardware ohne Rechner, ein Schieberegister mit etwas Logik. Erkennt aber solche Fehler zuverlaessig. Start- & Stopbit muessen da sein.
Danke für deine Antwort. Ich weiß, dass es zuverlässig funktioniert, aber meiner Intuition ist es noch nicht so richtig klar, warum das so gut funktioniert und wie die Synchronisation über viele tausend oder Millionen Bytes funktioniert. Aber ich denke meine mir selbst gegebene Erklärung wird schon stimmen. Sie muss nur noch vom Verstand ins Unterbewusstsein.
:
Bearbeitet durch User
Das Stopbit ist als Pause zu betrachten und hat den Ruhe-Pegel (-3V bis -15V) was der Logischen 1 entspricht. Es kann beliebig lang sein, aber mindestes 1 Bit. Das Stopbit gibt dem Empfänger Zeit die Daten zu verarbeiten. Es muss auch nicht abgefragt werden. Mit dem Startbit (+3V bis +15V -> Logisch 0) beginnt die Übertragung und das Timing erneut bis zum 8. Bit.
Uwe K. schrieb: > Das Stopbit gibt dem Empfänger Zeit die Daten zu > verarbeiten. Es muss auch nicht abgefragt werden. Ein vernünftiger Empfänger wird aber immer einen Framing Error auslösen, wenn es nicht die richtige Polarität hat. Bei der Frage hier ging es doch um einen Datenstrom, bei dem sich Start- und Stopbit wegen des Dateninhaltes nicht von Datenbits unterscheiden, m.a.W. ein Empfänger, der auf den laufenden Datenstrom raufgeschaltet wird, hat keine Chance, Start- und Stop-Bit zu erkennen.
Karl-alfred Römer schrieb: > dann hat > man also eine seeeeeehr lange Abfolge von immer gleich langen Phasen mit > High-Pegel und mit Low-Pegel. Kann es dann nicht irgendwann sein, dass > der Empfänger nicht mehr weiß, an welchem Bit er gerade dran ist? Solange keine Störung auftritt, wird der Empfänger die Synchronisation nicht verlieren, aber wenn er sich in eine laufende Übertragung einschaltet, hat er tatsächlich keine Chance zu erkennen, wo ein Zeichen endet und wo es beginnt. Andererseits wäre das ja auch nicht besonders wichtig, denn er würde trotzdem lauter "U"s ausspucken. Abhilfe könnte Einfügung eines Paritybits bringen, durch welches diese 10101... Sequenz unterbrochen wird, oder die Wahl einer länger dauernden Stop-Polarität. Bei den gebräuchlichen UARTs sind in Senderichtung regelmäßig 1 1,5 oder 2 Stopbits programmierbar. Dem Empfänger ists egal, er wartet so oder so nur auf 1 Stopbit. Die früher verwendeten Fernschreibverbindungen wurden mit 1 Startbit, 5 Informationsbits (Baudot Code), und 1,5 Stopbits betrieben, und erfahrungsgemäß dauerte es ungefähr eine halbe Zeile, bis sie sich mit einer laufenden Übertragung synchronisiert hatten und Kauderwelsch durch lesbaren Text ersetzten.
Hallo Karl-alfred, bei asynchroner Übertragung (mit Start- und Stopbit) synchronisiert der Empfänger auf das Startbit. Dazu wartet er, ausgehend von der ersten Flanke nach dem Ruhepegel, eine halbe Bitzeit ab, um zeitlich die Mitte des Startbit zu treffen. Anschließend wartet er jeweils eine ganze Bitzeit, um die Mitte der folgenden Bit zu treffen. Mit dem/den Stopbit/s ist die Übertragung des Zeichens abgeschlossen, das Stopbit legt die Datenleitung auf Ruhepegel und kann, wie schon erwähnt, als Pause angesehen werden. Ein neues Zeichen wird wieder neu auf die Mitte des neuen Startbit synchronisiert. Auf diese Weise müssen die beiden Baudratengeneratoren nicht völlig gleich laufen, es muß nur sichergestellt sein, dass auch das letzte Bit des Zeichen noch innerhalb seiner Bitzeit auf der Leitung gelesen wird. Bei 10Bit Zeichen (8Bit, Start-, Stopbit) sind +/-5% Takttoleranz möglich, da von der Bitmitte bis zu den Grenzen der Bitzeit jeweils 5% der Übertragungszeit des Zeichen liegen. Bei synchroner Übertragung wird der Takt, auf einer eigenen Leitung, mitgeführt. Hier wird kein Start- und Stopbit benötigt, da Sender und Empfänger mit dem selben Takt arbeiten. Bei phasensynchroner Übertragung werden Takt und Daten auf der gleichen Leitung übertragen. Frohe Ostern. Tom
Karl-alfred Römer schrieb: > nehmen wir an, ich schicke über RS232 (mit 8 Bit, 1 Stop-Bit, kein > Parity) seeeeeehr viele 'U' In dem Fall ist es tatsächlich unmöglich, Start und Stop zu bestimmen (solange nichts anderes kommt, ist das allerdings auch egal, sind eben lauter Us). Es ist deshalb generell nicht günstig, asynchron ohne Pausen zu senden, besser ist es, Records mit Pausen dazwischen zu verwenden, was sich aber in den meisten Fällen sowieso ergibt, weil auf die Antwort gewartet wird. Eine Pause von mehr als einer Bytelänge führt zu einer sicheren Neusynchronisation auf das nächste Startbit. Ein Problem ist das nur bei Geräten, die ohne Handshake pausenlos Daten senden, z.B. GPS-Empfänger. Da sollte man nach jeder Position eine Pause vorsehen. Georg
Karl-alfred Römer schrieb: > nehmen wir an, ich schicke über RS232 (mit 8 Bit, 1 Stop-Bit, kein > Parity) seeeeeehr viele 'U' (entspricht binär 01010101) ein, dann hat > man also eine seeeeeehr lange Abfolge von immer gleich langen Phasen mit > High-Pegel und mit Low-Pegel. Ja, ein sehr schönes Muster, um Clients bei 8N1 bitratenmäßig zu synchronisieren. > Kann es dann nicht irgendwann sein, dass > der Empfänger nicht mehr weiß, an welchem Bit er gerade dran ist? Jain. Das Problem besteht im allgemeinen eher darin, daß der Client in einem zufälligen Moment nur bitmäßig auf das uniforme Sync-Muster "einrastet". Die Scheiße passiert bereits hier. Solange das Sync-Pattern gesendet wird, wird der Client es auch korrekt empfangen. Erst bei Abbruch des Sync-Musters offenbart sich, ob der Cient auch an der korrekten Stelle des Datenworts eingerastet war. Das wird nur mit einer Wahrscheinlichkeit von 1:5 der Fall sein. Macht aber keinen Schlimmen, denn die Muster für den Abbruch sind vorhersagbar. Wenn der Sender des Sync-Musters dafür sorgt, daß nach Ende der Sync-Sequenz eine Weile (10 Bitzeiten=eine Bytezeit) lang Ruhe auf dem Bus ist und der Client die gültigen Abbruchmuster kennt, kann sich der Client sich dann auch bezüglich der Datenworte problemlos synchronisieren...
Danke füre Eure Antworten. So wie ich euch verstanden habe, ist alles kein Problem, solange der Empfänger nicht mit Daten zugeworfen wird oder der Datenfluss nicht unterbrochen oder zu stark gestört wird. In diesen Fällen müssten längere Pausen eingefügt werden. Es gibt aber auch die Möglichkeit von 1,5 Stop-Bits. Man erkennt an der graphischen Darstellung schon sehr schnell, wo die Stop-Bits sind. Damit könnte man auch mitten drin leicht neu synchronisieren, sofern die Signale nicht sehr unglücklich gewählt sind. Also z.B. unmittelbar vor oder nach den 1,5 Stop-Bits ein paar Datenbits mit 0 -Pegel. Bei der Auseinandersetzung mit diesem Thema und dank der Antworten in diesem Thread in Verbindung mit weiterem Googeln ist mir jetzt auch klar, was das Handshaking bringen soll. Vorher war mir gar nicht so richtig klar, wo der Unterschied zwischen Handshaking und der Synchronisation mit den Start und Stop-Bits ist. Jetzt habe ich es so verstanden, dass der Empfänger entweder per Hardware-Leitung, die auf High gesetzt wird, signalisiert, dass Daten empfangen werden können. Ist der Empfänger nicht bereit zum Datenempfang, weil z.B. der Puffer voll ist, wird die Leitung einfach auf Low gesetzt. Bei Software wird über die normale Serielle Leitung ein bestimmtes Byte gesendet, das der Sender dann als 'Pause' interpretiert. Mehr softwareaufwand und langsamer, aber dafür braucht man keine Extraleitung. Kann man das so sehen?
Karl-alfred Römer schrieb: > Mehr softwareaufwand und > langsamer, aber dafür braucht man keine Extraleitung. > Kann man das so sehen? Synchronisation kostet Bandbreite. Entweder du zweigst die von deinem Datenstrom ab, oder du verschenkst die Bandbreite, die dir die extra Leitungen bieten würden. Das ist aber grundsätzlich bei jeder Datenübertragung so. MfG Klaus
Karl-alfred Römer schrieb: > Kann man das so sehen? Ja, was das Handshaking angeht. So wurde ein Serielles Modem oft mit 115.200 Baud angesprochen obwohl es nur maximal 57.600 Baud beherrscht. Die Steuerleitungen (DTR RTS) haben den PC dann gesagt, wann es eine Pause machen muss. So funktioniert die Übertragung auch mit 2400 Baud obwohl man die Serielle mit 115.200 Baud anspricht. Ein Stoppbit vom 1,5 hilft bei der Synchronisation nicht, wenn man sich mitten in der Übertragung einklinkt. Man muss schon mindestens ein komplettes Byte Pause machen. In der Praxis kommt es nie vor, dass man pausenlos Daten sendet. Auch ein GPS tut das nicht. Man sendet immer ein Packet und macht dann eine Pause von ein paar Sekunden. Hier kann man das sehr gut sehen: https://www.youtube.com/watch?v=Hb9VNauBOAI Also auf keinen Fall eine Dauersendung machen.
Uwe K. schrieb: > Also auf keinen Fall eine Dauersendung machen. Eben - es gibt immer Muster, die eine falsche Synchronisation verursachen können, wenn sich der Empfänger irgendwann zuschaltet. Aber das sind eben nur bestimmte Muster, bei anderen entstehen Fehler (Framing Error), und deshalb synchronisiert sich das UART bei realen Daten nach einer Reihe von fehlerhaften Daten mal richtig und von da an läuft es bis zu einer Störung auf der Leitung. Erzwingen kann man die korrekte Synchronisation nur mit einer Pause länger als ein Byte. Karl-alfred Römer schrieb: > Bei Software wird über > die normale Serielle Leitung ein bestimmtes Byte gesendet, das der > Sender dann als 'Pause' interpretiert NEIN - es wird NICHTS gesendet. Normgerecht heisst das Break. c-hater schrieb: > Solange das Sync-Pattern gesendet wird vergiss das schnell wieder, da hat er was verwechselt - wohl mal unverstanden etwas über synchrone Übertragung gelesen. Für asynchron ist das irrelevant, es gibt keine Sync-Bytes, ein UART kann das garnicht (sonst wäre es ein USART). Georg
Danke nochmals für eure weiteren Antworten. Beim längeren nachdenken kam in mir eine Frage auf: Wenn man 1,5 Stop-Bits hätte, könnte man dann nicht jederzeit in die Synchronisation einsteigen? Man müsste ja nur waren bis zur ersten Lowlevel-Phase, die eine nicht ganzzahlige Dauer hätte (also z.B. 1,5 oder 2,5 oder 3,5 oder ....) Die steigende Flanke danach MUSS dann auf jeden Fall die Steigende Flanke des Startbits sein. Natürlich nur, falls ich keinen Denkfehler habe. Kann man das so sehen?
Karl-alfred Römer schrieb: > Die steigende Flanke danach MUSS dann auf jeden Fall die > Steigende Flanke des Startbits sein. > Natürlich nur, falls ich keinen Denkfehler habe. Kann man das so sehen? Zwischen zwei Zeichen gibt es keine Zeitbeziehung. Wenn z.B. mit einem Stopbit gesendet wird, kann das nächste Zeichen auch in einem Abstand von 1,8 Bitzeiten kommen. Asynchron ist nun mal asynchron. MfG Klaus
Naja, ein Stopbit bedeutet, dass mindestens ein Stop-Bit gesendet wird. Wenn der Sender nicht hinterherkommt kann die Pausezeit auch mal länger dauern. 1 1/2 Stop-Bits bedeutet eine Pausezeit von mindestens 1 1/2 Bit die wiederum eine Neusynchronisation nach einem gesendete Byte ermöglichen
Ach schade. Ich dachte, die Stopzeit wäre ziemlich exakt genau 1,5 Bit, wenn man 1,5 Stop-Bits einstellen würde. Wenn das ein Mindestwert ist, könnte es ja auch 2 Stop-Bits sein, was dann wiederum auch zwei Datenbits sein könnten. :-( Aber trotzdem Danke!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.