Forum: Mikrocontroller und Digitale Elektronik Maskentest (Eye) auf UART, Werte?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Johnny S. (sgt_johnny)


Angehängte Dateien:

Lesenswert?

Hallo Zusammen,

Um einen sporadischen Fehler auf einer UART-Schnitstelle zu finden, 
möchte ich ein Oszilloskop anschliessen mit einem Maskentest (Eye Mask 
Test) um so herauszufinden ob ab und zu unförmige Signale oder Signale 
ausserhalb der Toleranz ankommen.

Die maximal zulässige Spannung an den Pins ist -0.5 bis 5.5V, somit habe 
ich zwei Masken auf diese Bereiche gesetzt.

Die Signale sind wie folgt einzuhalten:

V Input High (min) = 1.9V
V Input Low (max) = 0.9V

Also habe ich mal ein Sechseck mit den Werten 1.9 und 0.9 für max und 
min, und die Mitte (1.4) als mittelpunkt.

Was mir nun noch fehlt ist die korrekte Berechnung der Zeit.
Ich habe bereits herausgefunden das ein UART Signal bei 9600baud ca. 
105uS lang ist, ich frage mich aber aktuell wie denn die Toleranz liegt, 
bzw auf was ich die Werte setzen soll.

Ich suche nach den Zeitwerten für die Punkte 1,2,3,4 (2 und 6 sowie 3 
und 5 sind ja gleich).

Kann mir jemand weiterhelfen?

von bitsi (Gast)


Lesenswert?

schau ins Datenblatt des UART, da sollten die Anforderungen an das 
Timing drin sein

von Dieter R. (drei)


Lesenswert?

Johnny S. schrieb:

> Die maximal zulässige Spannung an den Pins ist -0.5 bis 5.5V, somit habe
> ich zwei Masken auf diese Bereiche gesetzt.

Wenn Überschwinger auf der Leitung zu FEHLfunktionen führen, dann ist 
schon mal was grundsätzlich bedenklich in der Schaltung.

von Abdul K. (ehydra) Benutzerseite


Lesenswert?

Gesampelt wird in der Mitte des Bits. Die erste Flanke des Startbits 
startet einen internen Timer mit einer Voreinstellung auf den halben 
Maximalwert, danach läuft der Timer frei durch bis das Byte inkl. 
Stopbits durch ist. Danach fängt das Spiel von vorne an.

Es gibt halt unterschiedliche UARTs. Beim 8051 wird z.b. dreimal in der 
Mitte gesampelt und daraus der dominante Level bestimmt.

von Wolfgang (Gast)


Lesenswert?

Johnny S. schrieb:
> Ich habe bereits herausgefunden das ein UART Signal bei 9600baud ca.
> 105uS lang ist, ich frage mich aber aktuell wie denn die Toleranz liegt,
> bzw auf was ich die Werte setzen soll.

Das kommt drauf an, wie der Empfänger das Startbit erkennt und wie er 
das nachfolgende serielle Signal abtastet.

von Johnny S. (sgt_johnny)


Lesenswert?

Der Verbaute MCU ist ein AT89C51

von A. S. (achs)


Lesenswert?

Johnny S. schrieb:
> Um einen sporadischen Fehler auf einer UART-Schnitstelle zu finden,
> möchte ich ein Oszilloskop anschliessen mit einem Maskentest (Eye Mask
> Test) um so herauszufinden ob ab und zu unförmige Signale oder Signale
> ausserhalb der Toleranz ankommen.

Wenn die Signale an sich OK sind (Weit genug weg vom Schwellwert, keine 
Störungen drauf) gibt es 3 häufige Fehler:

a) Die erste Flanke ist anders (weil aus der Sättigung)
b) Toleranz der Baudrate (letzte Flanke zu früh oder zu spät)
c) ungleiche High/Low-Pegel

Um diese 3 Fehler per Oszi zu untersuchen, Sende verschiedene Zeichen 
mit je z.B. 10ms (oder 100) Pause dazwischen. Annahme: Ohne Parity. 
Startbit =0, Stoppbit=Ruhepegel=#111, Low-Bit first

a) 0x55 (#1110101010101 auf der Leitung, triggern auf fallende Flanke) 
Ausmessen und Vergleichen des ersten und des letzten lows bei Sender und 
Empfänger
b) 0x7e (#111011111101 auf der Leitung, triggern auf steigende Flanke) 
Ausmessen von Trigger-Flanke zu Stopp-Flanke (genau 7 Takte. Da gleiche 
Flanke und nicht die Erste, mittelt sich andere Fehler raus)
c) 0x40 und 0xbf im Wechsel (#1110000000101 und #1110111111011 auf der 
Leitung, triggern auf fallende Startflanke) Es entsteht ein 
Augendiagramm.

von Johnny S. (sgt_johnny)


Lesenswert?

Bevor ich mit Daten etwas testen möchte, wäre es doch hilfreich zuerst 
mal mit einem Augendiagramm zu prüfen ob die Signale an sich überhaupt 
stimmen.
Daher suche ich im ersten Moment für die Daten der Signale an sich, also 
wie schnell die SIgnalle fallen und steigen müssen etc.

von Kurt (Gast)


Lesenswert?

Ja, 9600 Bd hat eine Schrittweite von 104,17 µs.

Fang doch einfach mal damit an, dass Anstieg 10 ... 90% und Abfall 
(Abklingen) 90 ... 10% <= 1/4 davon, also <= 26 µs sein sollten.

Wenn dann mit Jitter die "Augenöffnung" (2 - 3 / 6 - 5) mit eindeutigen 
Logikpegeln noch >= 1/4 der Schrittweite, also 26 µs minimale Breite 
hat, arbeiten handelsübliche UARTs noch sauber.

Wenn die Zeiten passen, ist die UART zu sensibel, wenn nicht, musst du 
die Ursache des Verschleifens der Pulse suchen...

von Wolfgang (Gast)


Lesenswert?

Kurt schrieb:
> Wenn die Zeiten passen, ist die UART zu sensibel, wenn nicht, musst du
> die Ursache des Verschleifens der Pulse suchen...

Wenn die Signale derart verschleißen ankommen, dass es am UART knapp 
wird, ist es Zeit für einen vernünftigen Schnittstellentreiber vor dem 
UART. Eine differentielle Übertragung würde z.B. mit Gleichtaktstörungen 
wesentlich besser umgehen können.

von Peter D. (peda)


Lesenswert?

Johnny S. schrieb:
> Der Verbaute MCU ist ein AT89C51

Was für einen Quarz hast Du angeschlossen?

Das Signal sieht doch super sauber aus.
In der Regel sind UART-Fehler immmer Softwarefehler. Ich hatte mal 
unerklärliche Fehler mit einem UART-USB Wandler. Mit einer neuen 
Treiber-DLL waren die weg. Schon seltsam, wie wenig Software getestet 
wird, ehe man sie verkauft.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Johnny S. schrieb:
> Um einen sporadischen Fehler auf einer UART-Schnitstelle zu finden
Wie oft kommt der Fehler? Wie stellst du fest, dass ein Fehler 
aufgetreten ist? Was passiert im Fehlerfall? Wer ist der Sender und 
warum sollte der solche "unschöne" Effekte wie "kurze Bits" machen 
können?

> möchte ich ein Oszilloskop anschliessen mit einem Maskentest (Eye Mask
> Test) um so herauszufinden ob ab und zu unförmige Signale oder Signale
> ausserhalb der Toleranz ankommen.
Ich würde da eher im Fehlerfall den entsprechenden Teilnehmer einen 
Triggerimpuls ausgeben lassen und damit das dausersampelnde Oszilloskop 
anhalten.

> Ich habe bereits herausgefunden das ein UART Signal bei 9600baud ca.
> 105uS lang ist, ich frage mich aber aktuell wie denn die Toleranz liegt,
> bzw auf was ich die Werte setzen soll.
Die Toleranz ist dort überschritten, wo dein Empfänger nichts mehr mit 
dem Signal anfangen kann und Fehler produziert. Weil es unterschiedlich 
robuste Implementationen von Empfängern gibt, sind auch diese Toleranzen 
unterschiedlich.

Johnny S. schrieb:
> Bevor ich mit Daten etwas testen möchte
Ohne Daten kannst du eh' nichts testen. Und wenn du dann schon Daten 
erzeugen musst, dann wenigstens solche, die bei der Fehlersuche helfen.

> wäre es doch hilfreich zuerst mal mit einem Augendiagramm zu prüfen
> ob die Signale an sich überhaupt stimmen.
Aus Erfahrung: wenn das Gelbe da oben dein Signal ist, dann hast du 
andere Probleme, denn dieses Signal sieht gut aus. Nächster Schritt.

Oder andersrum: wenn du ein Signal hast, das irgendwie in den schwarzen 
Bereich deines Augenduiagramms passt, dann kann dein Augendiagramm-Test 
sagen: "alles gut!", obwohl das Signal im Grunde an sich echt übel 
aussieht.

Denn wenn du ein 5V-UART-signal hast, das normalerweise immer 0V und 5V 
hat, und dessen H-Pegel wegen einer Buskollision zwischendurch mal auf 
2,5V "zusammenbricht", dann wird dein Augendiagramm trotz dieser 
Kollision keinen Fehler anmeckern, weil ja 2,5V immer noch gut oberhalb 
von 1,9V sind...


Lies und versuche zu verstehen, was
A. S. schrieb:
> 3 häufige Fehler
Denn so werden Fehler auf UART-Schnittstellen gefunden.

Johnny S. schrieb:
> Der Verbaute MCU ist ein AT89C51
Auf welcher Seite ist der verbaut? Als Sender? Oder als Empfänger?

: Bearbeitet durch Moderator
von Flachtroll (Gast)


Lesenswert?

Uartfehler sind zum groessten Teil Software Fehler. Falls EMV nicht 
beachtet wurde allenfalls auch EMV Fehler.

Bei einem hinreichend langen Kabel koennte es geschehen, dass die GND 
Potentiale verschieden sind. Das gibt auch Uebertragungsfehler.

Uebertragungsfehler sollten mit einem Protokoll abgefangen werden.

von Johnny S. (sgt_johnny)


Lesenswert?

Nochmal zur klarstellung:
Es tut mir leid falls es verwirrung gibt zum Screenshot. Der Screenshot 
zeigt NICHT! das zu analysierende Signal, sondern einfach ein 
ausgegebenes UART von einem Arduino. Das hatte ich benutzt, um überhaupt 
einmal die Augenmaske hinzubekommen!


Kurt schrieb:
> Ja, 9600 Bd hat eine Schrittweite von 104,17 µs.
>
> Fang doch einfach mal damit an, dass Anstieg 10 ... 90% und Abfall
> (Abklingen) 90 ... 10% <= 1/4 davon, also <= 26 µs sein sollten.
>
> Wenn dann mit Jitter die "Augenöffnung" (2 - 3 / 6 - 5) mit eindeutigen
> Logikpegeln noch >= 1/4 der Schrittweite, also 26 µs minimale Breite
> hat, arbeiten handelsübliche UARTs noch sauber.
>

Also wären die Punkte 2 und 3 bei +39us und bei +65us zu setzen?

Lothar M. schrieb:
> Wie oft kommt der Fehler? Wie stellst du fest, dass ein Fehler
> aufgetreten ist? Was passiert im Fehlerfall? Wer ist der Sender und
> warum sollte der solche "unschöne" Effekte wie "kurze Bits" machen
> können?

Der Fehler passiert relativ selten, schätzungsweise 1x pro 50'000 bytes. 
Leider ist es dann aber so, das er "ansteht". Ein Reset und so gar 
Spannungsfrei machen, nützt dann nichts. Deshalb sol das komplette 
System vermessen werden.


>> möchte ich ein Oszilloskop anschliessen mit einem Maskentest (Eye Mask
>> Test) um so herauszufinden ob ab und zu unförmige Signale oder Signale
>> ausserhalb der Toleranz ankommen.
> Ich würde da eher im Fehlerfall den entsprechenden Teilnehmer einen
> Triggerimpuls ausgeben lassen und damit das dausersampelnde Oszilloskop
> anhalten.
>
>> Ich habe bereits herausgefunden das ein UART Signal bei 9600baud ca.
>> 105uS lang ist, ich frage mich aber aktuell wie denn die Toleranz liegt,
>> bzw auf was ich die Werte setzen soll.
> Die Toleranz ist dort überschritten, wo dein Empfänger nichts mehr mit
> dem Signal anfangen kann und Fehler produziert. Weil es unterschiedlich
> robuste Implementationen von Empfängern gibt, sind auch diese Toleranzen
> unterschiedlich.
>


> Ohne Daten kannst du eh' nichts testen. Und wenn du dann schon Daten
> erzeugen musst, dann wenigstens solche, die bei der Fehlersuche helfen.
Um mit spezifischen Daten zu testen, müsste das komplette System 
angepasst werden, um Testdaten auszugeben, daher wollte ich vorher 
prüfen ob die Spannungen überhaupt dauerhaft passen, oder aus 
irgendeinem Grund nicht den Spezifikationen entsprechen


> Johnny S. schrieb:
>> Der Verbaute MCU ist ein AT89C51
> Auf welcher Seite ist der verbaut? Als Sender? Oder als Empfänger?

Nunja, der MCU ist Quasi der "Master", er Sendet die Initiale 
Kommunikation, empfängt danach aber natürlich auch Daten.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Johnny S. schrieb:
> Der Fehler passiert relativ selten, schätzungsweise 1x pro 50'000 bytes.
Wie oft passiert der Fehler: 1x am Tag oder alle 5 Minuten?
Denn beim Dauersenden wäre das etwa jede Minute. Und das ist ziemlich 
oft.

> Leider ist es dann aber so, das er "ansteht".
Wie steht "er" an? Woran merkt man diesen "Anstand"? Werden keine Daten 
mehr übertragen? Warum nicht?

> Ein Reset und so gar Spannungsfrei machen, nützt dann nichts.
?? Das ist leider für einen Aussenstehenden nicht nachvollziehbar.

> Deshalb sol das komplette System vermessen werden.
Dieser logische Spagat ist für mich nicht nachvollziehbar.

> Um mit spezifischen Daten zu testen, müsste das komplette System
> angepasst werden, um Testdaten auszugeben,
Ja, so ist das, wenn man einen solchen Dauerübertragungs-Testmodus nicht 
von vorn herein vorgesehen und mit eingebaut hat. Das rächt sich...

Nach wie vor wäre meine Strategie: wenn da zyklisch Daten übertragen 
werden und im Fehlerfall der Klimbim stehen bleibt, dann setze ich einen 
Trigger auf die serielle Übertragung (bzw. auf den Augenblick, wo sie 
aussetzt und eben nicht mehr zykelt).

von Abdul K. (ehydra) Benutzerseite


Lesenswert?

Poste echte Scopebilder am Empfänger gemessen.

von Peter D. (peda)


Lesenswert?

Johnny S. schrieb:
> Der Fehler passiert relativ selten, schätzungsweise 1x pro 50'000 bytes.
> Leider ist es dann aber so, das er "ansteht". Ein Reset und so gar
> Spannungsfrei machen, nützt dann nichts.

Das klingt dann eher nach einem Protokollfehler. Das implementierte 
Protokoll ist nicht in der Lage, nach einer Störung oder Unterbrechung 
wieder auf das nächst Paket zu synchronisieren. Das ist aber eigentlich 
die Mindestanforderung an ein Protokoll.

von Anne Kragen (Gast)


Lesenswert?

Johnny S. schrieb:
> Daher suche ich im ersten Moment für die Daten der Signale an sich, also
> wie schnell die SIgnalle fallen und steigen müssen etc.

Revision E des RS232-Standards (aktuell ist mindestens schon F). 
Transition Region ist der illegale Bereich zwischen -3V und +3V:

Certain limitations apply to all interchange signals (data, control, and 
timing) as follows:

* Interchange signals entering transition must proceed to the opposite 
signal state, and may not reenter the transition region until the next 
significant change in signal condition.

* The direction of voltage must not change while in the transition 
region.

* The time required for a control signal to pass through the transition 
region must not exceed one millisecond.

* The time required for a data or timing signal to pass through the 
transition region must not exceed one millisecond or 4% of the normal 
duration of a signal element on that interchange circuit, whichever is 
the lesser.

* The maximum instantaneous rate of voltage must not exceed 30 volts per 
microsecond

von Peter D. (peda)


Lesenswert?

Anne Kragen schrieb:
> Transition Region ist der illegale Bereich zwischen -3V und +3V:

In der Praxis sind aber RS232-Receiver TTL-compatibel (<=+0.8V, 
>=+2.4V), z.B. MAX232:
"These receivers have a typical threshold of 1.3 V, a typical hysteresis 
of 0.5V, and can accept ±30-V inputs."

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Anne Kragen schrieb:
> Revision E des RS232-Standards (aktuell ist mindestens schon F).
> Transition Region ist der illegale Bereich zwischen -3V und +3V:
Wer sich das Oszibild angesehen hat und es entziffern kann, der erkennt, 
dass es hier um einen UART mit "TTL"-Pegeln von 5V und 0V geht. Und eben 
nicht um einen RS232-UART. Insofern sind RS232 Spezifikationen hier 
nicht so arg hilfreich.

Peter D. schrieb:
> In der Praxis sind aber RS232-Receiver TTL-compatibel (<=+0.8V,
>>=+2.4V), z.B. MAX232:
> "These receivers have a typical threshold of 1.3 V, a typical hysteresis
> of 0.5V, and can accept ±30-V inputs."
In der Praxis hilft das aber nichts, weil die Pegel von '0' und '1' 
invertiert sind: der Ruhepegel '1' auf der RS232-Seite ist "negative 
Spannung", der Ruhepegel '1' auf der "TTL" Seite sind positive 5V.

: Bearbeitet durch Moderator
von Peter D. (peda)


Lesenswert?

Lothar M. schrieb:
> In der Praxis hilft das aber nichts, weil die Pegel von '0' und '1'
> invertiert sind

Doch, schon. Einige MCs können IOs umpolen. Oder als SW-UART geht das 
auch, z.B. in meinem Bootloader.

von HildeK (Gast)


Lesenswert?

Peter D. schrieb:
> Das klingt dann eher nach einem Protokollfehler. Das implementierte
> Protokoll ist nicht in der Lage, nach einer Störung oder Unterbrechung
> wieder auf das nächst Paket zu synchronisieren. Das ist aber eigentlich
> die Mindestanforderung an ein Protokoll.

Das passt aber gar nicht zu:

Johnny S. schrieb:
> Ein Reset und so gar
> Spannungsfrei machen, nützt dann nichts.

Wer merkt sich denn dann das Problem? Und wie bekommt er das System dann 
wieder zum Laufen?
Nur eine Seite spannungsfrei machen ist eh Mist, solange die eine Seite 
noch treiben könnte.

von Dieter R. (drei)


Lesenswert?

HildeK schrieb:

> Johnny S. schrieb:
>> Ein Reset und so gar
>> Spannungsfrei machen, nützt dann nichts.
>
> Wer merkt sich denn dann das Problem? Und wie bekommt er das System dann
> wieder zum Laufen?
> Nur eine Seite spannungsfrei machen ist eh Mist, solange die eine Seite
> noch treiben könnte.

Ich habe keine eigene Erfahrung mit AT89C51. Kann der aus einem 
anliegenden High-Pegel an einem Eingang weiter leben? Dann sollte der TO 
Optokoppler zwischenschalten oder sich was anderes zur Entkopplung 
ausdenken. Und den Fehler in seiner Software suchen.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Dieter R. schrieb:
> Kann der aus einem anliegenden High-Pegel an einem Eingang weiter leben?
Fast alle µC können diese Art der parasitären Versorgung. Wenn über den 
"High-Pegel" am Eingangspin genug Strom kommt.

Dieter R. schrieb:
> Dann sollte der TO Optokoppler zwischenschalten oder sich was anderes
> zur Entkopplung ausdenken.
Sowas z.B.
1
             5V
2
              o      
3
              |
4
             2k2
5
              |
6
TX ----|<-----o------- RX
7
     Schottky 
8
uC1                    uC2
9
10
GND ------------------ GND
Dann wird auch dann nichts parasitär versorgt, wenn TX vom uC1 auf 5V 
liegt und der uC2 keine Vcc bekommt.

: Bearbeitet durch Moderator
von Peter D. (peda)


Lesenswert?

HildeK schrieb:
> Wer merkt sich denn dann das Problem?

Die nicht abgeschaltete Seite. Entweder der eine sendet munter weiter, 
während der andere gerade aus dem Reset kommt. Oder einer sendet wieder, 
während der andere noch in seiner Empfangsroutine verklemmt ist.
Gegen beides hilft ein ordentliches Protokoll.
Und ja, ein Timeout ist nie ein ordentliches Protokoll, höchstens nur 
ein Würgaround.

von Abdul K. (ehydra) Benutzerseite


Lesenswert?

Break wurde auch schon lange erfunden. Kann auch einen Reset auslösen, 
wenn man es geschickt anstellt.

von Kurt (Gast)


Lesenswert?

Johnny S. (sgt_johnny) schrieb

> Also wären die Punkte 2 und 3 bei +39us und bei +65us zu setzen?

Was zierst du dich nur so mit den µs?
Probier es mit halbwegs plausiblen Daten:
0  -  1/4  -  3/4  -  1  also 0 - 26 - 79 - 104 µs, oder
0  -  1/3  -  2/4  -  1  also  0 µs, 35 µs, 70 µs, 104 µs
Wenn das Bild nichts aussagt, variierst du die Werte. Da kann man sich 
doch mit den vorgegebenen Eckwerten rantasten...

Oder...
Du denkst mal darüber nach, wie ein Byte-Fehler die ganze Übertragung, 
dauerhaft stören kann. Das ist bestimmt nicht der U(S)ART, auch nicht 
das Protokoll, sondern irgendwas nicht zu Ende gedachtes im Programm.

Was rettet denn den Fehler über einen Reset? Wird Müll in's EEPROM 
geschrieben, der beim Neustart wiederum Unfug hervorruft?

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Kurt schrieb:
> Da kann man sich doch mit den vorgegebenen Eckwerten rantasten...
Genau das passiert bei der Anleitung, die
A. S. schrieb:
>>> Es entsteht ein Augendiagramm.

Aber ewig nach der allein glückselig machenden Augenspezifikation zu 
suchen ist eben auch nutzlos. Denn wenn der Sender ein UART-Device hat, 
das funktioniert, wer soll dann ein Timing verletzen?
Und andere Fehler (ESD, Buskollisionen, ...) findet man mit anderen 
Werkzeugen besser.

Ich triggere auf die fallende Flanke und setze die Nachleuchtdauer auf 
"ewig". Und dann sehe ich mir an, was sich da tut.
Danach das selbe mit der steigenden Flanke. Und fertig ist der Test, ob 
"zu kurze" Bits auf der Leitung unterwegs sind. Gleichzeitig sehe ich, 
ob da irgendwelche ungültigen und dubiosen Pegel aufgetreten sind.

Ein Augendiagramm für diese Aufgabe zu verwenden ist wie ein Gurkenglas 
mit einem Minibagger aufzuschrauben. Irgendwie wird das schon gehen. Und 
Hauptsache man kommt an die Gurke. Dass es für diese Aufgabe viel 
einfachere und bessere Methoden gibt, das sollte man allerdings schon im 
Hinterkopf haben.

Augendiagramme sind gut für Übertragungsfrequenzen, die mindestens 5 
Zehnerpotenzen höher liegen. Damit wird auch nicht vorrangig nach 
einzelnen  Bitfehlern gesucht, sondern die Qualität der 
Übertragungsstrecke vermessen.

Abdul K. schrieb:
> Break wurde auch schon lange erfunden.
> Kann auch einen Reset auslösen, wenn man es geschickt anstellt.
Das ist so ein Fall, wo man sich glatt ins Knie schießen kann. Die 
Behandlung eines Übertragungsfehlers darf nicht automatisch zu einem 
Reset führen. Ein Reset (z.B. auch per Watchdog) ist kein 
Fehlerbehandlungsmechanismus. Auch wenn weniger erfahrene Entwickler das 
meinen.

Kurt schrieb:
> Du denkst mal darüber nach, wie ein Byte-Fehler die ganze Übertragung,
> dauerhaft stören kann.
Oder eben irgendein anderer Fehler (Framing, fehlerhafter Start oder 
umgekipptes Bit nach einem ESD-Spike, ...).

Das unterschiedet den schlechten vom mittelmäßigen und guten 
Programmierer:

Der Schlechte geht davon aus, dass die Hardware unfehlbar und absolut 
störungsfrei ist. Weil es in seiner Welt keine Fehler gibt, macht er 
keinerlei Fehlerbehandlungsroutinen und wundert sich über sporadische 
Fehlfunktionen bis zum "Stillstand". Er kommt dann zum 
Hardwareentwickler und sagt: mach das gut!

Der Mittelmäßige schreibt sein Programm so, dass es erkennt, dass da ein 
Fehler aufgetreten ist, stoppt die Übertragung und zeigt eine 
Fehlermeldung  an. Diese Fehlermeldung bekommt man dann durch Ein- und 
Ausschalten oder einen anderweitig aufwendigen Resetprozess wieder weg.

Der Gute macht die SW so, dass sie erkennt, dass da ein Fehler 
aufgetreten ist, setzt im Fehlerfall die Übertragung neu auf und zählt 
einen Fehlerzähler hoch. Bei zu vielen Fehler in zu kurzer Zeit kommt 
eine Warnung und letztlich eine Fehlermeldung. Während diese 
Fehlermeldung ansteht, funktioniert die Übertragung aber weiterhin (so 
gut es geht).

Letztlich ist das hier mit deutlich über 99% Wahrscheinlichkeit ein 
Softwareproblem.

: Bearbeitet durch Moderator
von A. S. (achs)


Lesenswert?

Es ist sogar andersrum: eine UART-übertragung musst kurze Störungen 
verkraften (Flanken, high oder low für einige Bitzeiten).

Framing/Parity/Overunfehler müssen erkannt werden und mindestens zu 
einem verlorenen Telegramm führen. Notfalls sequencecounter mit 
einbauen. Und danach muss es weitergehen.

Sonst ist das keine UART-Verbindung sondern synchronraten.

: Bearbeitet durch User
von Stefan F. (stefanus)


Lesenswert?

Kennt ich noch die Drucker, die nach einem einzigen fehlerhaften Bit das 
ganze Magazin mit Hieroglyphen bedrucken?

Wenn man diese vor lauter Verzweifelung aus schaltete, musste man den 
Papierstau heraus pulen und nach dem Wieder-Einschalten ging das 
Desaster direkt weiter so, mangels Zugriff auf den Printserver/Puffer.

Ich bin so froh, dass das vorbei ist.

: Bearbeitet durch User
von Dieter R. (drei)


Lesenswert?

Stefan ⛄ F. schrieb:
> Kennt ich noch die Drucker, die nach einem einzigen fehlerhaften Bit das
> ganze Magazin mit Hieroglyphen bedrucken?

Die hatten aber Centronics-Schnittstelle. Oder Zentronix?

von Stefan F. (stefanus)


Lesenswert?

Dieter R. schrieb:
> Die hatten aber Centronics-Schnittstelle

Ja, und das meistens mit Netzwerk-Adapter und Print-Server (Puffer) 
kombiniert.

von Günter W. (gw6719)


Lesenswert?

Wie wäre es, einem weiteren UART anszuschließen und mitzuprotokollieren, 
was auf der Leitung läuft? Eventuell kann das Protokoll 'von Hand' 
dekodiert werden und damit eventuelle Protokollfehler gefunden werden.

von Wolfgang (Gast)


Lesenswert?

A. S. schrieb:
> Sonst ist das keine UART-Verbindung sondern synchronraten.

Das 'A' in UART steht für asynchron ;-)

von Peter D. (peda)


Lesenswert?

Ein Hauptgrund für die Entwicklung des CAN-Busses war auch, daß die UART 
außer der 3-fach Abtastung keinerlei Übertragungssicherung hat. 
Professionelle UART-Protokollstacks belegen daher gerne mal 100kB an 
Code, das wird eng auf einem 8051.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.