Hallo an alle, Solch ein Thema gab es schon mal hier, doch da waren ein paar Saachen undeutlich. Liege ich richtig wenn ich folgendes sage: Das Startbit kommt nach einem Wechsel von High(Ruhephase) auf Low. ABER, wieso ist es denn noch zusätzlich nötig 1 oder mehrere Stopbits zu senden? Um sicherzustellen dass genug Zeit ist um das Byte ins Schieberegister zu schieben? Vielen dank Gruss
hi, um sicher den ruhepegel zu erreichen nach der Übertragung. Sonst könntest du ja: start|d|d|d|d|d|d|d|d|start|..... senden. MfG ich
New D. schrieb: > Das Startbit kommt nach einem Wechsel von High(Ruhephase) auf Low. Genau. > ABER, wieso ist es denn noch zusätzlich nötig 1 oder mehrere Stopbits zu > senden? Versuch mal, die Flanke von low auf low zu erkennen. Vielleicht klingelts dann.
A. K. schrieb: > Versuch mal, die Flanke von low auf low zu erkennen. Vielleicht > klingelts dann. Ja aber nach der übertragung kommt doch eh mindestens ein Stopbit, von daher wird so oder so das Potential auf High gehoben. Das heisst es ist besser, nach einem Stopbit, eine gewisse Zeit abzuwarten, damit die gesendeten Bits alle verarbeitet werden, bevor ein neues Byte kommt? Denn wenn man nur ein Stopbit hat, und keine Zeit abwartet, dann kommt die ganze übertragung doch ins stocken ? Danke an alle:)
New D. schrieb: > Ja aber nach der übertragung kommt doch eh mindestens ein Stopbit, von > daher wird so oder so das Potential auf High gehoben. Eben. Wobei du oben soeben noch nach dem Sinn ebendiesen Stoppbits gefragt hattest. ;-) > Das heisst es ist besser, nach einem Stopbit, eine gewisse Zeit > abzuwarten, damit die gesendeten Bits alle verarbeitet werden, Der Sinn von 1,5 Stoppbits findet sich in https://de.wikipedia.org/wiki/Stoppbit
A. K. schrieb: > New D. schrieb: >> Ja aber nach der übertragung kommt doch eh mindestens ein Stopbit, von >> daher wird so oder so das Potential auf High gehoben. > > Eben. Wobei du oben soeben noch nach dem Sinn ebendiesen Stoppbits > gefragt hattest. ;-) Da habe ich mich schlecht ausgedrückt, ich wollte nachfragen, was die Anzahl der Stoppbits bewirken soll. Also ist es nicht notwendig nach einem Stopbit noch eine delay Zeit laufen zu lassen um wirklich sicherzugehen dass der Schiebenregister alles richtig schluckt ? Gruss
New D. schrieb: > Ja aber nach der übertragung kommt doch eh mindestens ein Stopbit, von > daher wird so oder so das Potential auf High gehoben. In deiner ersten Post hast du doch nach dem Sinn gefragt ? Stoppbit == Idle, also praktisch nur eine Pause zwischen gesendeten Bytes. Was A.K. versucht hat dir zu erklaren ist folgendes: Wenn du dauernd 0x00 sendest, hast du ohne Stoppbit keine einzige Flanke auf der Linie. EDIT: Gerade gesehen: New D. schrieb: > Da habe ich mich schlecht ausgedrückt, ich wollte nachfragen, was die > Anzahl der Stoppbits bewirken soll. Damit auch langsamere Teilnehmer genugend Zeit haben. > Also ist es nicht notwendig nach einem Stopbit noch eine delay Zeit > laufen zu lassen um wirklich sicherzugehen dass der Schiebenregister > alles richtig schluckt ? Nein, bei Hardware UART nicht.
> Also ist es nicht notwendig nach einem Stopbit noch eine delay Zeit > laufen zu lassen um wirklich sicherzugehen dass der Schiebenregister > alles richtig schluckt ? Eine generische Antwort gibt es nicht. Ein Stopbit ist zwingend erforderlich. Alles was drüber hinaus geht ist allein von der Empfängerhard- und -software abhängig. Moderne Hardware braucht üblicherweise keine zusätzlichen Delays/Stopbits (die Hardware hat Empfangsfifos, die CPU ist schnell genug). Wenn du allerdings Daten zu einem Fernschreiber schickst, braucht der mind. 1.5 Stopbits und nach bestimmten Zeichen (z.B. Wagenrücklauf/CR) sogar 8 oder mehr (wurde üblicherweise dadurch umgesetzt, dass das CR zweimal gesendet wurde). Aber auch auf moderner Hardware ist evtl nach bestimmten Zeichen ein interner Verarbeitungsschritt nötig, der lang genug ist, dass die Empfangspuffer überlaufen können (z.B. ein Bootloader, der bei einem Firmware-Upload nach einer Zeile eines HEX-Files die Daten in den Flash schreibt und währenddessen die UART nicht bedienen kann). Dafür behilft man sich mit der Flusskontrolle. Da gibt es zum einen das "XOFF/XON" Protokoll, bei dem werden spezielle Zeichen an die Gegenseite geschickt, die ihr mitteilen, bitte die Übertragen zu pausieren (XOFF/CTRL-S) oder wieder aufzunehmen (XON/CTRL-Q) [1]. Hat das "Problem", dass die Leitung nicht mehr 8-Bit-Clean ist, 2 Zeichen haben eine Sonderbedeutung und dürfen nicht mehr im normalen Datenstrom vorkommen. Eine andere Variante der Flußkontrolle ist das RTS/CTS Handshake - hier werden 2 zusätzliche Leitungen benutzt um der Gegenseite mitzuteilen, ob Daten geschickt werden dürfen oder nicht. Hier bleibt der Datenkanal 8-Bit-Clean. [Btw, beide o.g. Varianten sind asynchron und führen nicht zum sofortigen Stop der Übertragung - es können immer noch ein paar Bytes eintrudeln bevor der Sender aufhört.] Und letztendlich gibt es noch die Anwendungsspezifischen Flusskontrollen - z.B. immer erst auf Quittierung des letzten Kommandos warten bevor ein neues geschickt wird oder die 2 CRs beim Fernschreiber. [1] Wer Linux benutzt und sich gefragt hat, warum man die Ausgabe von Programmen mit CTRL-S anhalten und mit CTRL-Q wieder starten kann, hat hier die Antwort ;-)
Sinnvollerweise limitiert man die Beanspruchung des Controller per Baurate. Die muss ja nur so hoch sein wie noetig, nicht so hoch wie moeglich. Lieber nur 4800 als 115200, wenn's reicht.
New D. schrieb: > noch eine delay Zeit > laufen zu lassen um wirklich sicherzugehen dass der Schiebenregister > alles richtig schluckt ? Alle integrierten UARTs haben ein Schieberegister und ein getrenntes Register für die empfangenen Daten. Vom Schieberegister in das Empfangsregister werden die Daten übernommen, wenn das Stopbit erkannt ist, also etwa in der Mitte des Stopbits - danach kann das Schieberegister das nächste Byte empfangen. Die CPU hat Zeit, das Empfangsregister zu lesen, bis das nächste Byte vom Schieberegister kommt - also eine ganze Zeichen-Zeit. Schiebregister ohne Empfangsregister, die die CPU direkt während des Stopbits auslesen muss, gab es nur zu Zeiten, als man das noch aus TTL-Gattern zusammengebaut hat. Da waren Register noch knapp und kostenträchtig, heute hat daher die Anzahl der Stopbits keine Bedeutung mehr, bzw. muss mindestens = 1 sein. Zusätzlich zum beschriebenen Verhalten ist meistens noch ein FIFO enthalten, so dass die CPU erst nach z.B. 8 oder 16 Zeichen reagieren muss. Georg
1,5 oder mehr Stoppbits können auch aus einem ganz anderen Grunde sinnvoll sein: Wenn man einen Empfänger während des Betriebs an einen Bus koppelt, auf dem permanent ohne Pause gesendet wird, sind die 1,5 (oder mehr) Bits ein ideales Kriterium, das Stoppbit verlässlich zu erkennen und damit dann die nachfolgenden Bits korrekt als Bytes zusammenzufassen. Beispiel der Zeichenfolge 0xAA 0xAA mit 1 Stoppbit:
1 | _-_-_-_-_-_-_-_-_-_- |
2 | S sS s |
Beispiel der Zeichenfolge 0xAA 0xAA mit 2 Stoppbits:
1 | _-_-_-_-_--_-_-_-_-_-- |
2 | S ssS ss |
Beim ersten Beispiel kann der Empfänger nicht erkennen, wo ein Byte beginnt und wann es endet. Beim zweiten Beispiel sehr wohl.
:
Bearbeitet durch Moderator
Frank M. schrieb: > Beim ersten Beispiel kann der Empfänger nicht erkennen, wo ein Byte > beginnt und wann es endet. Beim zweiten Beispiel sehr wohl. Nicht unbedingt. Aber er wird einfacher einen Übertragungsfehler erkennen und anmäkeln können. Hier mit 2 Stopbits:
1 | _-_-_-_-_--_-_-_-_-_-- |
2 | Sender S ssS ss |
3 | Empf. ^S10110101F |
4 | '-- Terminal wird gestartet und erkennt gleich danach ein Startbit S |
5 | Aber bereits am Ende des falsch empfangenen Bytes kommt |
6 | statt des erwarteten Stopbits eine 0 --> Fehler F |
Mit 1,5 Stopbits wird dann sogar das Bittimng verletzt und der UART kann sofort einen Fehler ausspucken. Aber prinzipiell ist es schwierig, mit einem Terminal in eine dauerhaft laufende Kommunikation "einzufädeln"...
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Mit 1,5 Stopbits wird dann sogar das Bittimng verletzt und der UART kann > sofort einen Fehler ausspucken. Dann müssten aber die Clocks des Senders und Empfängers sehr genau synchron sein, was in der Praxis eher nicht der Fall ist. Zum Beispiel treffen USB2UARTs die höheren Baudraten oft nur mit Abweichungen.
Hi > Mit 1,5 Stopbits wird dann sogar das Bittimng verletzt und der UART kann > sofort einen Fehler ausspucken. Kommt darauf an, ob der Receiver das registriert. AVRs ignorieren beim Empfang Stopbits > 1. MfG Spess
spess53 schrieb: > AVRs ignorieren beim > Empfang Stopbits > 1. Das tun alle UARTs, schliesslich ist das das Ruhepotential. Die Einstellung von Stopbits ist nur beim Senden relevant. Georg
Georg schrieb: > Alle integrierten UARTs haben ein Schieberegister und ein getrenntes > Register für die empfangenen Daten. Vom Schieberegister in das > Empfangsregister werden die Daten übernommen, wenn das Stopbit erkannt > ist Das ist falsch. Sie werden nicht dann übernommen, wenn das Stopbit "erkannt" wurde, sondern einfach dann, wenn nach eingestelltem Frameformat Zeit für das Stopbit ist. Das geschieht völlig unabhängig davon, ob das Stopbit tatsächlich als High gelesen wurde. Das entscheidet nur darüber, ob die Fehlerbits sauber bleiben oder ein FramingError gemeldet wird. > Zusätzlich zum beschriebenen Verhalten ist meistens noch ein FIFO > enthalten, so dass die CPU erst nach z.B. 8 oder 16 Zeichen reagieren > muss. Das trifft im hier relevanten Bereich der µC nicht oder nur eingeschränkt zu.
Ein wesentlicher Punkt ist, dass mit der fallenden Flanke des (vermuteten) Startbits das Timing für den Empfang eines (oder besser: jedes) Zeichens gestartet wird. Wird das Startbit nicht korrekt erkannt, so wird wieder auf eine fallende Flanke zur Synchronisation auf ein Startbit gewartet. Nachdem die Zeit für die Bestimmung des Stoppbits vergangen ist, darf der UART - noch vor Ablauf der vollständigen Bitzeit des Stoppbits - wieder auf die Jagd nach der nächsten fallenden Flanke eines Startbits gehen. Muss er aber nicht, sondern er könnte stur die Bitzeit des Stoppbits vollständig abwarten. Wenn bei einem derart tumben UART-Empfänger dann der Sender auch nur minimal schneller läuft und ohne Lücke Daten sendet, dann gehen Zeichen verloren. Überzeugte Sicherheitsgurtanleger sollten deshalb über den Einsatz des zweiten Stoppbits nachdenken.
Konrad S. schrieb: > Überzeugte Sicherheitsgurtanleger sollten deshalb über den Einsatz des > zweiten Stoppbits nachdenken. Auch mit einem 2. Stopbit kann das prinzipielle Problem Bein "Einfädeln" in eine dauerhafte Übertragung nicht sicher gelöst werden. Erst wenn zwischendurch mindestens 7 "Ruhebits" kommen, kann sicher wieder von vorn begonnen werden...
c-hater schrieb: > Das trifft im hier relevanten Bereich der µC nicht oder nur > eingeschränkt zu. Immerhin hatten Zilog UARTs schon 1985 FIFOs. Also schon vor mehr als 30 Jahren. Datenblatt auf Wunsch. c-hater schrieb: > Das ist falsch. Sie werden nicht dann übernommen, wenn das Stopbit > "erkannt" wurde, sondern einfach dann, wenn nach eingestelltem > Frameformat Zeit für das Stopbit ist. Was ändert das an der Tatsache, dass zur Übernahme eine ganze Zeichen-Zeit zur Verfügung steht? Kannst du irgendein UART benennen, bei dem man das empfangene Zeichen noch während des Stopbits übernehmen muss? Das wäre ja schon eine wichtige Information für den Programmierer. Georg
Georg schrieb: > Immerhin hatten Zilog UARTs schon 1985 FIFOs. Und die waren was nicht? Richtig: das waren KEINE µC. Sondern externe Peripherie für eine Familie von 8Bit-CPUs. > Also schon vor mehr als 30 > Jahren. Datenblatt auf Wunsch. Habe ich selber. Du glaubst doch wohl nicht ernsthaft, daß du der einzige Arsch bist, der was vom Z80 und seiner Peripherie versteht? Mein Gott, ich komme aus der Zone, da gab's ja fast nix anderes als den U880 und die zugehörige, genauso raubkopierte Peripherie. Wenn es sie gab... > Was ändert das an der Tatsache, dass zur Übernahme eine ganze > Zeichen-Zeit zur Verfügung steht? Garnichts. Wer hat behauptet, dass es daran etwas ändern würde? Ich jedenfalls nicht... Aber es ändert natürlich sehr wohl etwas daran, was man mit einem empfangenen Datum eventuell anfangen kann, wenn FE gemeldet wird...
Lothar M. schrieb: > Auch mit einem 2. Stopbit kann das prinzipielle Problem Bein "Einfädeln" > in eine dauerhafte Übertragung nicht sicher gelöst werden. Nein, es kann nur den beschriebenen Fall - etwas zu schneller Sender überfährt doofen Empfänger - verhindern.
Georg schrieb: > Alle integrierten UARTs haben ein Schieberegister und ein getrenntes > Register für die empfangenen Daten. Falsch. > Schiebregister ohne Empfangsregister, die die CPU direkt während des > Stopbits auslesen muss, gab es nur zu Zeiten, als man das noch aus > TTL-Gattern zusammengebaut hat. Diese Technik wird auch heutzutage noch bei vielen Atmel ATtiny verwendet, nämlich in Form des sog. USI-Blocks. Hier die entsprechende Applikationsschrift AVR307: http://www.atmel.com/Images/doc4300.pdf
@ Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite >> Alle integrierten UARTs haben ein Schieberegister und ein getrenntes >> Register für die empfangenen Daten. >Falsch. Alle zurechnungsfähigen. >> Schiebregister ohne Empfangsregister, die die CPU direkt während des >> Stopbits auslesen muss, gab es nur zu Zeiten, als man das noch aus >> TTL-Gattern zusammengebaut hat. >Diese Technik wird auch heutzutage noch bei vielen Atmel ATtiny >verwendet, nämlich in Form des sog. USI-Blocks. Hier die entsprechende >Applikationsschrift AVR307: Das ist ja auch ein Würg-Around schlechthin! Mein Gott, in Zeiten, wo einzele Transistorn auf einem IC im Bereich von Nanocent kosten, sind soche Tricks ala USI Schnee von vor-vor-vor-vor-gestern. Jeder zurechnungsfähige Chipdesigner würde einfach einen USART incl. SPI Mode dort draufpappen und gut. Die paar Dutzend Gatter interessieren heute kostentechnisch schon lange nicht mehr! Schau dir an wieviele komplexe Funktionsblöcke selbst in den einfachsten 32-Bit uCs drin stecken und was der kostet!
A. K. schrieb: > Versuch mal, die Flanke von low auf low zu erkennen. Vielleicht > klingelts dann. Dafür gibt es doch extra das Signal "RI" (Ring Indikator) ;-) MfG Paul
Paul B. schrieb: > Dafür gibt es doch extra das Signal "RI" (Ring Indikator) Das ist doch Signal from Modem, oder ?
Falk B. schrieb: > Das ist ja auch ein Würg-Around schlechthin! Diese Bausteine werden auch heutzutage noch in gigantischen Stückzahlen hergestellt. Ebenso werden damit auch zahlreiche neue Projekte begonnen, und zwar sowohl kommerziellen als auch Bastlerkreisen. Das bedeutet zwar keineswegs, dass es sich um eine schöne technische Lösung handelt, sondern vielfach nur um "Tradition", aber die Existenz zu leugnen bzw. derart zu relativieren ist auf Grund der Marktbedeutung der ATtiny nicht angemessen. UARTs sind in der Tat simpel und wenig fehlerträchtig in Hardware zu gießen, auch wenn ich selbst schon einen Prozessor mit seh fehlerhaftem UART erlebt habe. Erschreckend ist vielmehr, wie viele fehlerhafte I2C-Blöcke in der Realität anzutreffen sind. Auch wenn das USI sehr minimalistisch ist, gibt es mittlerweile(!) immerhin funktionsfähige Implementierungen für die gebräuchlichen seriellen Protokolle.
Georg schrieb: > spess53 schrieb: >> AVRs ignorieren beim >> Empfang Stopbits > 1. > > Das tun alle UARTs, schliesslich ist das das Ruhepotential. Die > Einstellung von Stopbits ist nur beim Senden relevant. Ist das ganz sicher? Ganz ganz sicher? Also wenn ich IRGENDEINE UART auf 2 Stopbits einstelle, kann die dann GANZ sicher auch nur 1 Stopbit empfangen? > Georg Gruss Chregu
Christian M. schrieb: > Ist das ganz sicher? Ganz ganz sicher? Also wenn ich IRGENDEINE UART auf > 2 Stopbits einstelle, kann die dann GANZ sicher auch nur 1 Stopbit > empfangen? Solange die Pause zwischen 2 gesendeten Bytes > 1 bit, ja.
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.