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
@ 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
