Hallo, muss bei einem normalen UART das Break-Signal am Anfang eigentlich immer einen Framing-Error auslösen? Geht es auch ohne? Gibt es Gründe für oder gegen eine der beiden Varianten? Was wäre aus Sicht der Software das bessere Verhalten? Ich baue zur Zeit einen full-featured UART in einem FPGA und möchte dafür natürlich auch eine saubere Break-Signal-Erkennung integrieren, dabei ist mir aufgefallen das ohne besondere Vorkehrungen die fallende Flanke am Beginn des Break-Signals immer auch einen Framing-Error auslöst. Ich überlege nun ob ich dagegen was unternehmen soll (kostet natürlich Arbeit und auch Ressourcen im FPGA) oder ob mir das einfach egal sein kann. Da bei mir auch jeder Fehler durch den Empfangs-FIFO gehen muss würde ich gerne den unnützen Framing-Error sparen wenn unmittelbar danach (also innerhalb einer Bit-Zeit) gleich ein Break-Signal erkannt wird. Meiner persönlichen Meinung nach wird der Framing-Error kurz vor der Break-Signal-Erkennung nicht benötigt und ich glaube auch nicht das die SW davon profitiert beides (nahezu zeitgleich, außer bei sehr niedrigen Baudraten) gemeldet zu bekommen. Wie macht das eigentlich übliche SW bei Protokollen die auch das Break-Signal benutzen? Grüße und Danke schon mal für hoffentlich zahlreiche Meinungen/Antworten Erik
@ Erik (Gast) >muss bei einem normalen UART das Break-Signal am Anfang eigentlich immer >einen Framing-Error auslösen? AFAIK ja. >Geht es auch ohne? AFAIK nein. >Gibt es Gründe für oder gegen eine der beiden Varianten? >Was wäre aus Sicht der Software das bessere Verhalten? Naja, man kann ja unterscheiden Daten == 0x00 + Stop Bit == 0 -> Break Daten != 0x00 + Stop Bit == 0 -> frame error >Meiner persönlichen Meinung nach wird der Framing-Error kurz vor der >Break-Signal-Erkennung nicht benötigt und ich glaube auch nicht das die >SW davon profitiert beides (nahezu zeitgleich, außer bei sehr niedrigen >Baudraten) gemeldet zu bekommen. Ja.
Erik schrieb: > muss bei einem normalen UART das Break-Signal am Anfang eigentlich immer > einen Framing-Error auslösen? Ja, das muß so sein. Wie willst Du sonst das Break vom Datenbyte 0x00 unterscheiden? Peter
Falk Brunner schrieb: > Daten == 0x00 + Stop Bit == 0 -> Break Das sollte eigentlich noch nicht als Break erkannt werden.
@ Konrad S. (maybee) >> Daten == 0x00 + Stop Bit == 0 -> Break >Das sollte eigentlich noch nicht als Break erkannt werden. Das ist die einfachste Art, es mit einem normalen UART in einem uC zu erkennen. Wenn man Break länger definiert ist das OK, muss man aber anders erkennen.
Ein Break zeichnet sich dadurch aus, dass die Leitung länger low ist als sie es in einem gültigen Frame sein dürfte. Also muss ein Framing Error ausgelöst werden. Es sei denn, es gibt eine Vorrichtung, welche den Dauerlow explizit als Break zurückmeldet. Die könnte dann den Error übersteuern.
Hallo, Danke schon mal für Eure Antworten, leider kann ich mich erst jetzt melden da µC.net bei mir auf Arbeit nicht funktioniert. Falk Brunner schrieb: >> Geht es auch ohne? > > AFAIK nein. Warum nicht? Warum muss bei einem Break-Signal, das auch expliziet als solches an die SW gemeldet wird, immer noch zusätzlich ein Frame-Error auslösen? Falk Brunner schrieb: >> Was wäre aus Sicht der Software das bessere Verhalten? > > Naja, man kann ja unterscheiden > > Daten == 0x00 + Stop Bit == 0 -> Break > Daten != 0x00 + Stop Bit == 0 -> frame error Damit erkennt man aber kein echtes Break-Signal bei dem der Low-Pegel länger ansteht als ein komplettes Frame (inklusive Start-Bit und Stop-Bit) dauert. Nebst dessen das die SW üblicherweise den Pegel des Stop-Bits gar nicht sehen kann (um das Stop-Bit an die SW zu reichen müsste man den RC-FIFO um ein weiteres Bit breiter machen und sowas habe ich noch nie gesehen). Peter Dannegger schrieb: > Wie willst Du sonst das Break vom Datenbyte 0x00 unterscheiden? Der UART erkennt ein echtes Break daran das die Leitung länger als eine komplette Frame-Dauer auf Low-Pegel gezogen wird. Meinem Verständnis nach: Ein gültiges Datenbyte 0x00 (bei 8N1) hat nur für einigermaßen genau 9 Bit-Zeiten einen Low-Pegel, alle Low-Pegel von >9 bis <=10 Bit-Zeiten sind ein Frame-Error und alles was länger als 10 Bit-Zeiten Low ist ist ein Break-Signal. Oder liege ich da falsch? Konrad S. schrieb: >> Daten == 0x00 + Stop Bit == 0 -> Break > > Das sollte eigentlich noch nicht als Break erkannt werden. Sehe ich ganz genau so. In meinem "full-featured" UART gibt es für das Break-Signal eine eigenständige Erkennungslogik die erkennt wenn der Low-Pegel länger als ein komplettes Frame dauert und das mit einem dediziertem Interrupt meldet. Das Problem ist einfach nur das in dem Moment wo die fallende Flanke genau 10 Bit-Zeiten (bei 8N1) her ist wird das ganze natürlich auch als Frame-Error erkannt weil die Frame-Error-Logig die fallende Flanke als gültiges Startbit erkennt. Meine Lösung wäre jetzt das bei einem Frame-Error mit Datenbyte == 0x00 immer noch genau eine Bit-Zeit gewartet wird um zu schauen was als nächstes aus der Empfängerlogik raus purzelt, wenn das ein Break ist wird der gemerkte Frame-Error verworfen und wenn was anderes kommt oder gar nichts (innerhalb der einen Bit-Zeit) dann geht der Frame-Error als solcher durch und wird auch an die SW gemeldet. Meine Frage danach ob es eine normale SW, die Break benutzt, übel nimmt wenn kein Frame-Error, zusätzlich zum Break, kommt bezieht sich natürlich auf Implementierungen die ein Break-Signal auch getrennt von anderen Ereignissen korrekt melden können (also PC-UART oder vergleichbares Zeugs von besseren µC). Da ich noch nie sowas als SW implementiert habe: nimmt diese Art von SW es übel wenn kein Frame-Error vor/parallel zum Break kommt? Bei extrem niedrigen Baudraten müsste man ja eigentlich beides getrennt gemeldet bekommen und bei höheren Baudraten (als wenn eine Bit-Zeit kleiner als die Interrupt-Latenz ist) wird man wohl immer beides auf einmal gemeldet bekommen, auf einen UART bezogen der zwar beides individuell melden kann aber keine extra Logik enthält die bei einem Break-Signal den Frame-Error unterdrückt. Gibt es für diese UART-Signale eigentlich irgendwo eine richtige Spezifikation? Also eine Spec die das alles auf der Bitübertragungsebene beschreibt. Grüße Erik
Erik schrieb: > Warum nicht? Warum muss bei einem Break-Signal, das auch expliziet als > solches an die SW gemeldet wird, immer noch zusätzlich ein Frame-Error > auslösen? Wie meldest du denn den Break an die Software? >> >> Daten == 0x00 + Stop Bit == 0 -> Break >> Daten != 0x00 + Stop Bit == 0 -> frame error > > Damit erkennt man aber kein echtes Break-Signal bei dem der Low-Pegel > länger ansteht als ein komplettes Frame (inklusive Start-Bit und > Stop-Bit) dauert. Deshalb ist es ja ein Framing Error. > Nebst dessen das die SW üblicherweise den Pegel des > Stop-Bits gar nicht sehen kann Eben. Aber die SW kann den Framing Error sehen, den deine Hardware generiert. > Peter Dannegger schrieb: >> Wie willst Du sonst das Break vom Datenbyte 0x00 unterscheiden? > > Der UART erkennt ein echtes Break Nicht die UART! Die Software, die mit deiner UART arbeitet: Wie kann die einen Break von einem 0x00 unterscheiden?
Erik schrieb: > Meine Frage danach ob es eine normale SW, die Break benutzt, übel nimmt Die Verwendung von Break ist mir eigentlich nur von den Rechnern bei Sun vertraut. Da musste das Break, meiner Erinnerung nach, deutlich länger als ein Zeichen sein (125ms???). Durch zu klein eingestellte Baudrate hat man seinen Server also nicht gleich auf den Firmware-Prompt zurückgeworfen. Wo wird denn Break heutzutage noch genutzt?
Erik schrieb: > Meine Frage danach ob es eine normale SW, die Break benutzt, übel nimmt > wenn kein Frame-Error, zusätzlich zum Break, kommt Das ist insofern ziemlich egal, weil ein Break üblicherweise verwendet wird, um eine Übertragungseinrichtung in den Ausgangszustand zurückzuversetzen. D.h. mit dem Ende des Breaks (das kann also nach mehr als einer Char-Länge sein oder nach den früher üblichen 0,2.. 1 sec oder nach Reparatur der unterbrochenen Leitung) fängt alles von vorne an und eine zuvor aufgetretener Framing Error interessiert kein Schwein mehr. Allerdings hat nicht jedes UART einen dedizierten Break Detector und nicht jede Software wertet einen Break Event aus - also bleibt oft nur noch der Framing Error. Lässt man den weg und die Software beachtet den Break nicht, wird eine Fehlerkondition übersehen. Fazit: FE UND Break ist korrekt. Gruss Reinhard
Das Break ist kein gültiger UART-Datenstrom. Es wurde erst viel später von jemandem hinzugefügt, der meinte, sowas als zusätzliches Protokollelement benötigen zu müssen. Daher hat eine UART üblicher Weise weder eine Break-Erkennung, noch einen Break-Generator. Ehe man die Krücke Break verwendet, sollte man besser das Protokoll sauber definieren, damit sowas nicht nötig ist. Leider gibt es einige Standardprotokolle, die es benutzen. Ob Du in Deine selbstgebastelte UART das Break einbaust, hängt davon ab, welche Protokolle Du darauf laufen lassen willst. Wenn Du aber eine Break-Erkennung einbauen willst, dann mach es richtig. Prüfe, ob 10 low-Bits hintereinander kommen, auch ohne Startflanke. In Multimaster kann es passieren, daß einer ein Datenbyte sendet und mittendrin ein anderer es mit Break überdeckt. Dann hast Du Daten <> 0 und FE. Das Break löst keine Startflanke aus, da es mitten im Datenbyte beginnt. Da das Break erst später erkannt werden kann, mußt Du auch das FE setzen. Ein laufendes Paket ist dann eh Schrott, d.h. die Software kriegt durch das FE gesagt, schmeiß es weg. Das FE ist daher sogar sinnvoll. Peter
Peter Dannegger schrieb: > Ehe man die Krücke Break verwendet, sollte man besser das Protokoll > sauber definieren, damit sowas nicht nötig ist. Der Vorteil eines Break ist es, dass man ein out-of-band signalling damit erreichen kann. Man muss also keins der regulär übertragbaren Zeichen (256 bei 8 bits) opfern, und kann eine zusätzliche Information damit unterbringen. Solange diese zusätzliche Information eher die Art "exception" ist, ist das so schlecht nicht. Aber zurück zum Ausgang: ja, ein Break ist einfach ein framing error, nicht mehr, aber auch nicht weniger. Ob man nun zusätzlich noch eine gewisse Mindestdauer dieses Zustands festlegt, ist dann eine Vereinbarungssache zwischen beiden Kommunikationsteilnehmern (d. h. man anerkennt dann nicht jeden framing error als Break, sondern erst einen solchen, der deutlich länger als eine normale Frame-Dauer anhält). Aber auch in einem solchen Falle ist der framing error zuvor bereits erkannt (nämlich nach dem fehlenden Stopbit).
Erik schrieb: > Da ich noch nie sowas als SW implementiert habe: nimmt diese Art von SW > es übel wenn kein Frame-Error vor/parallel zum Break kommt? Die Software braucht den Framing Error, um das Break überhaupt erkennen zu können. Ansonsten müsste man die RxD-Leitung per Portpin mitpollen. Falls die UART in der Lage ist, ein Break über ein spezielles Bit separat zu melden, gibt es natürlich keinen Grund, eine Auswertung über Fehlerbit, Datenwort und Parität zu machen. Das erledigt dann ja die Hardware. Ob dann bei einem Break noch ein Framing Error gemeldet wird oder nicht dürfte ziemlich egal sein, denn da guckt man dann eh nicht mehr hin. Konsequent wäre es aber, denn schliesslich hat das Datenprotokoll ein ungültiges Format. > Gibt es für diese UART-Signale eigentlich irgendwo eine richtige > Spezifikation? Also eine Spec die das alles auf der Bitübertragungsebene > beschreibt. Nein. Für LIN gibt es eine Spezifikation und da ist auch der SYNC BREAK behandelt. Für den generischen UART nicht, der ist bei jedem Controller anders.
Jörg Wunsch schrieb: > Der Vorteil eines Break ist es, dass man ein out-of-band signalling > damit erreichen kann. Der Nachteil ist allerdings, daß es nicht in Hardware implementiert ist. Das Break-Senden ist mit der normalen UART ein Albtraum. Man muß dazu vorher die Baudrate halbieren, ein 0x00 senden und dann schnell die Baudrate zurück setzen. Manche UARTs ignorieren aber das Setzen der Baudrate, wenn gerade ein Senden oder Empfang läuft. Und die Break-Erkennung (Daten = 0, FE) geht nur, wenn keine Kollision möglich ist. Bei einem MC kann man das Break auch über einen Timer und den TX-Pin zurückschalten als IO-Pin realisieren. Bzw. das Break empfangen über einen Pin-Change-Interrupt und Timer. Es ist daher immer eine Krücken-Lösung. Peter
Peter Dannegger schrieb: > Der Nachteil ist allerdings, daß es nicht in Hardware implementiert ist. Jein. Ich konnte mich noch dunkel dran erinnern, und habe eben nochmal nachgesehen: die Z80-SIO konnte sowas sehr wohl bereits vor mehr als 30 Jahren, die kann einen separaten Interrupt für "break detected" generieren. Ich glaube, die Idee dahinter war ursprünglich, dass man diesen Zustand gar nicht mit dem Sender erzeugt, sondern dass der Empfänger auf diese Weise eine hardwaremäßig getrennte Verbindung erkennen kann (weshalb es an einer klassischen Sun auch tödlich war, das Bedienterminal auszuschalten: dann fiel sie per Break in den Firmwaremonitor zurück).
Jörg Wunsch schrieb: > Ich glaube, die Idee dahinter war ursprünglich, dass man diesen > Zustand gar nicht mit dem Sender erzeugt Ich nehme das zurück. ;-) Habe eben gesehen, dass die Z80-SIO sogar ein "send break" hat. http://www.z80.info/zip/um0081.pdf
Jörg Wunsch schrieb: > Ich nehme das zurück. ;-) Habe eben gesehen, dass die Z80-SIO > sogar ein "send break" hat. Die Teletype von 1930 hatte auch schon eine "Line Break"-Taste. Die gehörte meines Wissens zur morgendlichen Checkliste, um die Funktion und die Leitung zu überprüfen. Gruss Reinhard
Hallo, Karl Heinz Buchegger schrieb: > Wie meldest du denn den Break an die Software? Na per Interrupt, es gibt dafür einen extra Wert im RC-Register. Karl Heinz Buchegger schrieb: >> Der UART erkennt ein echtes Break > > Nicht die UART! Doch, alle halbwegs vernünftigen UARTs können sowas, z.B. der 16450 von vor X Jahrzehnten. Nur bei ein paar kleinen Mikrocontrollern lässt man sowas manchmal weg weil das ja Transistoren kostet und die wiederum kosten Geld. Karl Heinz Buchegger schrieb: > Die Software, die mit deiner UART arbeitet: > Wie kann die einen Break von einem 0x00 unterscheiden? Die SW bekommt den Break als solchen explizit gemeldet, es gibt genau dafür einen extra Status-Code. Mit dem selben Mechnismus wie einen Frame-Error oder einen RC-FIFO-Overrun. Reinhard Kern schrieb: > und nicht jede Software wertet einen Break Event aus - also bleibt oft > nur noch der Framing Error. Lässt man den weg und die Software beachtet > den Break nicht, wird eine Fehlerkondition übersehen. Das ist aus meiner Sicht das Argument den Frame-Error drin zu lassen. Bei mir werden das dann in jedem Fall 2 unabhängige Events die auch immer in der korrekten Reihenfolge (erst Frame-Error dann Break) gemeldet werden. Sollte sich eine SW daran stören, was ich eigentlich nicht glaube da alle anderen UARTs (die beides getrennt voneinander melden) bei einem Break auch immer einen Frame-Error mitmelden, kann ich immer noch eine abschaltbare Logik einbauen die den Frame-Error am Anfang eines Break ausfiltern kann (ist per Default immer aus und müsste explizit aktiviert werden). Ob so ein Filter aber wirklich sinnvoll ist, z.B. in einer Multimaster-Umgebung, steht noch auf einem anderen Blatt. Peter Dannegger schrieb: > Ob Du in Deine selbstgebastelte UART das Break einbaust, hängt davon ab, > welche Protokolle Du darauf laufen lassen willst. Welche Protokolle später über diesen UART laufen weiß ich heute noch nicht, wo dieser UART überall eingesetzt werden soll wurde noch nicht abschließend überlegt, ich habe eher eine recht lange Liste an Features die mein UART haben soll und danach richte ich mich. Break steht auf dieser Liste mit drauf und deswegen kommt das auch mit rein, viele andere UARTs können das schließlich auch und es gibt sogar ein paar Protokolle die das wirklich benutzen. Mit meinem UART sollen möglichst alle üblichen (und auch ein paar weniger übliche) Verwendungsszenarien abgedeckt werden. Ich hab noch nicht so oft SW für die Serielle-Schnittstelle programmiert aber ich bin der Meinung das dieses "Out-of-Band" ein sehr gutes Argument für das Break-Feature ist, eben weil dafür keines der möglichen (gültigen) Frames verloren geht (man kann bei 8N1 also 257 unterschiedliche Werte übertragen). Peter Dannegger schrieb: > Es ist daher immer eine Krücken-Lösung. Deswegen will ich das ja ordentlich in HW realisieren damit es eben keiner Krücken-Lösung bedarf. Reinhard Kern schrieb: > Die Teletype von 1930 hatte auch schon eine "Line Break"-Taste. Die > gehörte meines Wissens zur morgendlichen Checkliste, um die Funktion und > die Leitung zu überprüfen. Na wenn das kein Grund ist. Ich kann doch in einem "_full_-featured" UART unmöglich ein Feature weg lassen das seit über 80 Jahren zum Standard gehört. Danke für die Diskussion und Eure Meinungen. Grüße Erik PS.: eine Frage hab ich noch: Nach einem Frame-Error, wann sollte frühestens wieder ein Frame-Error möglich sein? Bei meinem derzeitigen Konzept würde jede fallende Flanke (die den Kriterien eines Startbits entspricht) auch zu einem Frame-Error führen. Wenn man also ein Signal generieren würde bei dem genau alle 4 Bit-Zeiten ein Pegelwechsel stattfindet würde mein UART bei 8N1 alle 8 Bitzeiten einen Frame-Error melden obwohl eigentlich nur alle 10 Bitzeiten überhaupt ein Frame kommen könnte. Seht Ihr darin ein Problem? Nur gültige Frames werden aus dem Empfangs-Deserialisierer so entnommen das enthaltene fallende Flanken (z.B. zwischen den Datenbits) nicht noch als Anfang eines Startbits erkannt werden können.
Erik schrieb: > würde mein UART bei 8N1 alle 8 > Bitzeiten einen Frame-Error melden Dann hast Du was falsch gemacht. Bei einem FE und 8N1 kann frühestens nach 11 Bitzeiten der nächste FE kommen. Das Starbit ist definiert als der nächste 1-0 Wechsel nach dem letzten Stopbit. Nach dem FE, also Stopbit = 0 muß daher erst noch ein 1-Bit kommen, ehe das nächste Start erkannt werden kann. Peter
Peter Dannegger schrieb: > Das Break-Senden ist mit der normalen UART ein Albtraum. Man muß dazu > vorher die Baudrate halbieren, ein 0x00 senden und dann schnell die > Baudrate zurück setzen. Was verstehst du unter einer "normalen" UART? Die Standard-UART in PCs basiert auf dem INS8250 oder dessen Nachfahren wie 16450 und kann den Break-Zustand setzen und löschen, weshalb es nur noch eines passenden Delays bedarf. Ebenso ist eine Break-Erkennung integriert. Windows besitzt folgerichtig einen API dafür: SetCommBreak/ClearCommBreak.
A. K. schrieb: > Die Standard-UART in PCs > basiert auf dem INS8250 oder dessen Nachfahren wie 16450 und kann den > Break-Zustand setzen und löschen Ja ich bezog mich da mehr auf Mikrocontroller (8051, AVR). Ich hab das Break auch noch nie benötigt. Dafür kann die PC-UART wiederum keine 9Bit, wie es bei RS-485 gerne benutzt wird. Peter
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.