Frage:
Sollte ich für UART Parität auf Board-Ebene verwenden?
Thomas O
2011-01-17 03:50:19 UTC
view on stackexchange narkive permalink

Ich überlege, ob ich mit meinem UART Parität verwenden soll oder nicht. Es handelt sich um ein Hochgeschwindigkeitssignal auf Platinenebene (ab 115.200 Baud). Die Spuren sind sehr kurz (weniger als 2 cm), MCU zu DSP, aber sie könnten Rauschen aufnehmen. Während einer Logikanalysesitzung mit meinem Logik-Sniffer bemerkte ich, dass ein Byte falsch erfasst wurde, es war nur ein einzelner Fehler. Ich konnte es nicht replizieren. Jetzt frage ich mich, ob ich Parität einbeziehen soll.

Meine Anwendung ist insofern etwas sicherheitskritisch, als ein Fehler zu einem Grafikfehler auf einem HUD / OSD führen würde, der jemandem, der ein Modellflugzeug steuert, falsche Informationen liefern könnte. Das HUD wird jedoch mit 30 Bildern pro Sekunde aktualisiert, sodass jeder Fehler nur vorübergehend ist. Ein Problem, das auftreten kann, ist, dass ein Befehl gesendet wird, der das OSD in einen falschen Zustand versetzt, in dem nichts angezeigt wird, sodass der Pilot etwa 25 km von zu Hause entfernt blind bleibt ... was nicht gut ist.

Wird mich das Einschließen von Parität vor häufigen Störungen schützen oder wird das Protokoll dadurch nur langsamer? Warum haben die meisten UART-Protokolle keine Parität? Und gibt es einen Grund, ungerade oder gerade Parität übereinander zu wählen?

Wenn Sie ein kritisches System haben, von dem Sie sich vorstellen, dass es in einen nicht funktionsfähigen Zustand übergeht, der sich nicht von selbst auflöst, sollte es über eine vom Benutzer zugängliche Schaltfläche zum Zurücksetzen / Aktualisieren (Anzeige) verfügen und so konzipiert sein, dass es schnell zurückkehrt auf Funktionalität, wenn das gedrückt wird. ** Besonders ** wenn es sich um einen Prototyp handelt. Die richtige Lösung des Problems * ist * wichtig, aber es ist auch nicht richtig, nach der richtigen Lösung zu suchen, während Benutzer auf das Ziehen von Akkus zurückgreifen müssen, bis Sie ein Firmware-Update abgeschlossen, qualifiziert und verteilt haben.
Neun antworten:
#1
+13
JustJeff
2011-01-17 04:03:01 UTC
view on stackexchange narkive permalink

Nach meiner Erfahrung überspringen fast alle Geräte und Systeme, mit denen ich jemals gearbeitet habe, die Parität und verwenden nur Nachrichtenprüfsummen oder CRCs, um Fehler zu erkennen.

Ich dachte daran, die beiden in eine Art Nachrichtenformat zu kombinieren, das sowohl Parität als auch CRC8 oder CRC16 verwendet. Der von mir verwendete PIC24F verfügt über einen eingebauten CRC-Generator, der für mich sehr nützlich ist.
Es ist sehr selten, fast unmöglich, einen Fehler zu haben, den die Parität abfängt und der CRC nicht abfängt.
@markrages, für 32-Bit-CRC haben Sie eine Chance von 1/8 Milliarde, dieselbe CRC & Parität zu haben, vorausgesetzt, Sie haben Multi-Bit-Fehler.
@BarsMonster, Wie haben Sie diese Zahl bekommen?
Bei Multibit-Fehlern ist die Wahrscheinlichkeit gleich, CRC zu erhalten - 1/2 ^ 32. Wahrscheinlichkeit, die gleiche Parität zu erhalten = 1/2. Multiplizieren und los geht's.
Ah, ich verstehe, also "<# Bits / Paket> [Bits / Paket] * 2 ^ 33 [Pakete / Fehler] / 1Mbaud [Bps] = <# Bits / Paket> * 2,4 Stunden / Fehler" oder ungefähr 2,4 Stunden pro Fehler pro Bit oder ~ 102 Tage für 1-KB-Pakete.
Berücksichtigen Sie bei kleinen Controllern mit begrenztem Speicher die Fletcher-Prüfsummen, die fast so gut wie CRC sind und keine Nachschlagetabellen erfordern.
#2
+9
bt2
2011-01-17 04:53:15 UTC
view on stackexchange narkive permalink

Wenn Sie die Möglichkeit haben, eine Nachricht zu unterbrechen, kann ein Paritätsfehler verwendet werden, um eine fehlerhafte Übertragung schneller als eine CRC-Prüfung zu beenden, insbesondere bei großen Paketgrößen. Andernfalls fängt eine CRC-Prüfung alles ab, was eine Paritätsprüfung und mehr bewirkt. Wenn Sie wirklich besorgt sind, können Sie zusätzliche Methoden zur Softwareerkennung verwenden, z. B. Kontextprüfung und Nachrichtenspiegelung. Zeitüberschreitungen können verwendet werden, um zu verhindern, dass das OSD dauerhaft in einen falschen Zustand versetzt wird.

+1 auf die Zeitüberschreitungen. In einer solchen Anwendung müssen Sie Ihren Watchdog aktivieren und testen, um sicherzustellen, dass er ordnungsgemäß funktioniert.
#3
+7
Kellenjb
2011-01-18 02:25:32 UTC
view on stackexchange narkive permalink

Ungerade gegen gerade Parität

Dies hängt geringfügig davon ab, welche Kommunikation Sie verwenden. Ich weiß, dass Sie gesagt haben, dass Sie UART verwenden, aber ich werde etwas weiter antworten. Wenn Sie sich für die Parität entscheiden, wählen Sie die Option aus, bei der für Ihren "Leerlauf" -Zustand das Paritätsbit umgeschaltet werden muss.

Wenn Sie ein aktives High-System haben, sind alle Nullen im Leerlauf. Machen Sie es also zu einer ungeraden Parität, damit das Paritätsbit den Status von Leerlauf ändern muss.

In einem aktiven Low-System sollten Sie sich ansehen, wie viele Bits die Parität überschreiten wird. Wenn es sich um 8 Bits handelt, führt eine gleichmäßige Parität zu einem 0-Paritätsbit, das der Idee folgt, eine Zustandsänderung für die Parität zu erzwingen.

Sollten Sie Parität verwenden?

Nun, das sind einige schwierige Fragen. Im Allgemeinen möchten wir das Rauschen als Gaußsches Rauschen modellieren, was bedeutet, dass die Bitfehler vollständig zufällig sind. Tatsächlich ist Rauschen, das sich auf unser System auswirkt, nicht immer zufällig. Der Grund dafür ist, dass Dinge, die Fehler auf einer Leiterplatte verursachen können, Heizkörper von etwas anderem sind. Wenn Sie darüber nachdenken, musste eine so kurze Spur, die genug Rauschen enthält, um Bitfehler zu verursachen, etwas ziemlich Extremes sein. Wenn Sie eine solche Geräuschquelle haben, besteht eine gute Chance, dass Sie mehr als ein Bit umdrehen. Parität ist gegen eine gerade Anzahl von Bitfehlern nutzlos. Ohne in die Mathematik einzutauchen, hilft Parität, hilft aber nicht Tonnen. Wenn Sie es sich nicht leisten können, viel zu verarbeiten, ist Parität möglicherweise das Beste, was Sie tun können.

Warum einen CRC verwenden?

Zunächst einmal sagen Sie, Sie haben einen eingebauten CRC-Generator. Dies bedeutet, dass die Berechnung für Sie sehr einfach sein sollte. CRCs sind viel besser darin, Mehrbitfehler zu erkennen. In einer Umgebung, in der die Wahrscheinlichkeit von Fehlern sehr gering ist, möchten Sie wirklich einen CRC verwenden. Entscheiden Sie sich für den größten CRC, den Sie sich in Ihrem System leisten können. Ein kleiner Trick, von dem ich weiß, dass er für mindestens crc16 funktioniert, wenn nicht für andere, ist, wenn Sie die Nachricht CRC erhalten, die Sie mit dem CRC darauf erhalten haben, sollten Sie 0 als Antwort erhalten. Wenn Sie Hardware zum Berechnen des CRC haben, ist dies eine sehr effiziente Methode, um sowohl CRC zu generieren als auch CRC zu überprüfen.

Ich möchte erwähnen, dass einige Systeme bei der Berechnung von Paritätsbits auf die Logik und nicht auf die tatsächliche Spannung achten. Meine Antwort gilt immer noch. Stellen Sie nur sicher, dass für jeden Ruhezustand eine Änderung der Spannung erforderlich ist, unabhängig davon, wie die Parität funktioniert.
#4
+5
BarsMonster
2011-01-17 14:49:22 UTC
view on stackexchange narkive permalink

Ich würde zuerst daran arbeiten, diesen Draht abzuschirmen.

Legen Sie Bodenebenen um ihn herum (und / oder) vergraben Sie ihn in innere Schichten zwischen Bodenebenen. Dann verlassen Sie sich auf CRC. Verwenden Sie Parität, wenn es kostenlos ist.

Können Sie erklären, was Sie unter "frei" verstehen?
@Kellenjb - Ich stelle mir vor, dass sich Bars im Gegensatz zu Software auf eine hardwarebasierte Paritätsprüfung bezieht. Ein Paritätsbit erfordert jedoch ein zusätzliches Bit im Datenstrom, sodass es nicht wirklich kostenlos ist.
Ja, kostenlos = es ist bereits auf beiden Seiten in Hardware implementiert.
Ich verwende ein Hardwaremodul auf einem PIC24F, das ungerade, gerade und keine Parität unterstützt.
#5
+5
russ_hensel
2011-01-18 00:49:35 UTC
view on stackexchange narkive permalink

Wenn Sie Parität verwenden, überlegen Sie, wie Sie den Fehler in Ihrem Code verwalten. Wenn Sie die Fehlererkennung nicht ordnungsgemäß verwalten können, hilft dies nicht viel.

Dies ist ein sehr wichtiger Punkt, den Menschen, die theoretische / Sesselargumente vorbringen, oft vergessen, zu berücksichtigen. In einigen Systemen, in denen die Integrität der Ausgabe wichtiger ist als die Produktion der Ausgabe, kann es richtig sein, nur Alarmglocken auszulösen und sich zu weigern, weiterzugehen. In vielen Fällen kann es jedoch weitaus kostspieliger sein, einen Fehler zuzulassen, um einen Denial-of-Service zu verursachen, als ihn passieren zu lassen - es ist anwendungsabhängig.
#6
+4
davidcary
2011-01-18 01:15:25 UTC
view on stackexchange narkive permalink

Parität ist meiner Meinung nach nutzlos.

Bei kurzen Chip-zu-Chip-Verbindungen auf einer solchen Karte sollte sie praktisch rauschfrei sein, solange Sie die Leitungen ordnungsgemäß ansteuern. - Zumindest im Vergleich zu beispielsweise Ihrem DRAM. Einige Leute erwarten einen Soft-Bit-Fehler pro Tag und Gigabyte DRAM. Woher wissen Sie, dass der Fehler, den Sie gesehen haben, nicht durch einen solchen Soft-Bit-Fehler verursacht wurde, sondern durch Rauschen Wenn Sie Rauschen induziert haben, das groß genug ist, um auf einer ordnungsgemäß angetriebenen Leiterplattenspur ein wenig zu kippen, haben Sie wahrscheinlich andere größere Probleme, über die Sie sich Sorgen machen müssen. (Mit "richtig angetrieben" meine ich, dass entweder jede Leitung die ganze Zeit aktiv angesteuert wird oder verwenden Sie einen Pull-Up-Widerstand oder Pull-Down-Widerstand, um den Status zwischen Nachrichten festzulegen.

Bei Off-Board-Verbindungen mit größerer Reichweite ist es häufig unvermeidlich, dass gelegentlich schwebende Drähte einen Eingangspin aufweisen mit mehr oder weniger kontinuierlichem Zufallsrauschen, und selbst wenn Sie eine Nachricht senden, erhalten Sie häufig Bitfehler. In diesem Fall ist die Parität besser als nichts bt2 erwähnt, möchten Sie CRC verwenden, damit Sie viele Fehler abfangen können, die bei der Parität vollständig übersehen werden. Wenn Sie CRC haben, hilft das Hinzufügen von Parität nicht wesentlich.

Wenn es möglich ist, Ihre zu setzen System in einem "schlechten Zustand", versuchen Sie, die Dinge so zu gestalten, dass sie in angemessener Zeit in einen guten Zustand zurückkehren. Verwenden Sie Kommunikations-Timeouts und Watchdog-Timer als Markrages und BT2 erwähnt In welchem ​​seltsamen Zustand sich der Empfänger befindet, wird er auf den richtigen Zustand zurückgesetzt.

"Die statische Aufladung des Satelliten wirkte sich auf seinen Computer aus, der das Rauschen als Befehl zum Herunterfahren las. Um das Problem zu lösen, haben die Controller einen kontinuierlichen Strom von EIN-Befehlen an den Satelliten gesendet, um ihn eingeschaltet zu halten. "- Amateurfunk-Satelliten: OSCAR-6

#7
+3
stevenvh
2011-07-31 12:27:01 UTC
view on stackexchange narkive permalink

Sie wollen keine Parität. Sie möchten eine zuverlässigere Kommunikation.

Der Grund, warum Parität wenig genutzt wird, ist, dass sie im Hinblick auf den Datendurchsatz teuer ist. Es beginnt damit, dass ein Frame fast 10% länger wird: Startbit + 8 Datenbits + Parität + Stoppbit = 11 Bits statt 10. Aber es ist weitaus schlimmer. Wenn Sie feststellen können, ob Sie die Daten korrekt erhalten haben, müssen Sie damit etwas anfangen. Das einfache Ignorieren der fehlerhaften Kommunikation reicht nicht aus. Der Sender muss es erneut senden. Es muss also wissen, ob es gut aufgenommen wurde. Sie müssen nach jedem Byte eine Bestätigung ( ACK / NAK ) senden, und der Sender kann das nächste Byte nicht senden, bevor er die ACK empfangen hat . Wenn Sie ASCII-Codes verwenden, sind das 11 Rückgabebits. Dies halbiert den Durchsatz, und wir haben bereits 10% verloren, sodass wir jetzt eine Nutzlasteffizienz von 36% von 80% erreichen. Und das ist der Grund, warum niemand Parität wirklich mag.

Hinweise:
1. Sie müssen den Erhalt einer Bestätigung nicht bestätigen. Der Hamming-Abstand zwischen den ASCII-Codes für ACK und NAK beträgt 3 (mit einer Parität von sogar 4), sodass ein Fehler beim Empfang von ACK / NAK kann nicht nur erkannt, sondern auch korrigiert werden.
2. Viele UARTs können mit Datenlängen von bis zu 5 Bit arbeiten, und es ist möglich, auf 5 Bit umzuschalten Zum Senden des ACK ist dies jedoch nur eine Schaufensterdekoration und erschwert nur die Kommunikation.

Eine bessere Lösung kann die Verwendung eines CRC am Ende jedes Blocks. CRCs sind besser als Paritätsbits, wenn es darum geht, mehrere Fehler zu erfassen (sie können sie jedoch nicht korrigieren). Eine verbesserte Effizienz kann nur für lange Blöcke erzielt werden. Wenn ein Block nur aus 2 Bytes besteht, kann kein 8-Bit-CRC hinzugefügt werden.
Ein weiterer Nachteil wäre, dass Sie immer noch den korrekten Empfang bestätigen müssen. Das ist es also wahrscheinlich auch nicht.

Wie wäre es mit selbstkorrigierenden Codes? Hamming-Codes verursachen wenig Overhead und ermöglichen es Ihnen, 1 fehlerhaftes Bit selbst zu korrigieren. muss nicht mehr bestätigt werden. Wie CRCs sind Hamming-Codes bei längeren Blöcken effizienter. Die Anzahl der zusätzlichen Bits ist definiert als

\ $ N + H < 2 ^ H \ $

wobei N = Anzahl der Datenbits und H. = Anzahl der Hamming-Bits. Um 1 Bit in einer 8-Bit-Kommunikation zu korrigieren, müssen Sie 4 Hamming-Bits hinzufügen. Ein fünftes Hamming-Bit wird nur von 12 Datenbits benötigt. Dies ist die effizienteste Methode zur Fehlererkennung / -korrektur bei Kurznachrichten (einige Bytes), erfordert jedoch ein gewisses Jonglieren mit Ihren Daten: Die Hamming-Bits müssen an bestimmten Positionen zwischen Ihren Datenbits eingefügt werden.

Bevor Sie nun Hamming-Fehlerkorrekturcodes hinzufügen, sollten Sie sich Ihr Setup ansehen. Sie können Fehler auf einer 100 m langen Linie zwischen schweren Maschinen erwarten, aber Sie sollten keine Fehler auf einer 2 cm langen Linie haben. Wenn es Rauschen aufnimmt, ist die Impedanz möglicherweise zu hoch. Drücken / ziehen die Fahrer? Wenn ja, sollten sie in der Lage sein, Ihnen schnelle Kanten zu geben, es sei denn, Ihr "Kabel" ist kapazitiv, was bei dieser kurzen Entfernung nicht der Fall ist. Gibt es Hochstromspuren, die parallel zu den Datenleitungen verlaufen? Sie könnten Lärm verursachen. Benötigen Sie diese hohe Geschwindigkeit wirklich und stimmen die Uhren auf beiden Seiten genau genug überein? Eine Verlangsamung auf 57600 Bit pro Sekunde kann das Problem lösen.

#8
+1
AngryEE
2011-01-18 06:53:52 UTC
view on stackexchange narkive permalink

Trotz der Fülle von Antworten werde ich mein Stück hinzufügen. Die Parität funktioniert auf Byte-Ebene, und eine CRC funktioniert (im Allgemeinen) auf Paketebene. Paketschemata sind meiner Meinung nach der Kommunikation vom Rohbyte-Typ überlegen. Wenn Ihre Hardware ein einzelnes Byte basierend auf der Parität ablehnt, ist dies ideal für einen rohen Bytestream, aber nicht so gut für ein Paket. Plötzlich, Boom, haben Sie ein Byte in der Mitte eines Pakets verpasst - das bringt Ihre Analyse durcheinander. Im besten Fall ist Ihr gesamtes Paket weg, aber wenn Ihr Paketsuchalgorithmus nicht gut ist, können Sie möglicherweise mehr verlieren (und ich habe einige hirntote Paketerkennungsalgorithmen gesehen, die in realen Produkten verwendet werden). Verwenden Sie Pakete und CRCs wie vorgeschlagen.

#9
  0
supercat
2011-03-01 21:57:16 UTC
view on stackexchange narkive permalink

Parität ist im Allgemeinen bei "normaler" asynchroner Kommunikation nutzlos, kann jedoch in einigen anderen Kontexten nützlich sein. Beispielsweise erfordern einige differenzielle Codierungsschemata, dass jedes Zeichen eine gerade Anzahl von Zeilenübergängen aufweist, damit der Endzustand der Zeile mit dem Anfangszustand übereinstimmt. Code 39-Barcodes verwenden Parität, Art (*), um einzelne Zeichen zu validieren, und eliminieren im Allgemeinen die Notwendigkeit eines Prüfsummenzeichens.

Wenn Einzelbitfehler viel häufiger und Mehrbitfehler oder Framing waren Fehler, die Paritätsprüfung pro Byte könnte eine nützliche Ergänzung zu einer Prüfsumme oder CRC sein, da das Auffinden eines Bytes mit einem Fehler die Korrektur des Fehlers ermöglichen würde. In den meisten praktischen Situationen mit UARTs verursachen jedoch viele Zeilenfehler Rahmenfehler, wodurch die Datenwiederherstellung in vielen Fällen mit oder ohne Per-Byte-Parität unmöglich wird.

(*) Ein gültiges Code 39-Zeichen muss ungerade sein Anzahl der breiten Leerzeichen (1 oder 3) und eine gerade Anzahl der breiten Balken (0 oder 2).

@supercat, Viele Leute verwenden Parität, um nur zu wissen, dass das Byte schlecht ist, nicht weil sie es korrigieren müssen. Das ist ein ECC-Problem.
@supercat, verursacht jedoch Abstände, sodass jedes Datenwort eine gerade Anzahl von Übergängen aufweist, die Sie paritätisch implementiert haben. Es wird mindestens ein wenig verschwendeten Speicherplatz benötigt, um dies zu implementieren. Barcodes sind jedoch das Ende der Redundanz, da ein sehr großer Teil ihres Speicherplatzes für Redundanz verwendet wird.
@Kortuk: Welchen Vorteil hat es zu wissen, dass z. Das sechste Byte in einer Nachricht ist schlecht, anstatt nur zu wissen, dass etwas schlecht ist, wenn man keine Fehlerkorrektur versucht. Manchmal kann es nützlich sein, ein Protokoll zu haben, bei dem jedes Paket eine kurze Prüfsumme und jede Gruppe von Paketen eine lange hat. Wenn ein fehlerhaftes Paket abgefangen wird, muss nur dieses Paket erneut übertragen werden. Wenn ein fehlerhaftes Paket ohne Prüfsummenfehler durchkommt, zeigt die längere Gruppenprüfsumme an, dass etwas nicht stimmt, es ist jedoch erforderlich, die gesamte Gruppe erneut zu übertragen.
@Kortuk: Ich bin mir jedoch nicht sicher, ob dieses Prinzip für die Paritätsprüfung einzelner Bytes gelten würde, es sei denn, man hätte die Möglichkeit, anzufordern, dass nur bestimmte Bytes erneut übertragen werden müssen. Es würde Möglichkeiten geben, damit umzugehen, aber ich kann mir keine Kommunikationskontexte vorstellen, in denen es wirklich helfen würde.
@supercat, ein einfaches Beispiel, Sie setzen Parität auf die Ausgabe von einer Tastatur. Wenn Sie ein falsches Byte erhalten, ignorieren Sie es, anstatt diese Nummer zu verwenden. Ich denke, es würde viele Situationen geben, in denen das Löschen eines fehlerhaften Bytes nicht schadet. Alle für den Benutzer völlig transparent. Sie könnten sogar eine byteweise Bestätigung haben. Ich kann verstehen, warum dies für Sie sinnlos erscheint, aber wenn ein eingehendes Byte ein Befehl ist, sind Sie möglicherweise ohne den Befehl besser dran, als den Datenpuffer zu leeren oder einen anderen möglichen Befehl, der fälschlicherweise aufgerufen wurde.
@Kortuk: Es kann nützlich sein, die Parität mit einer Tastatur zu verwenden, obwohl das bevorzugte Verhalten darin besteht, eine erneute Übertragung anzufordern, anstatt einen Tastenanschlag zu ignorieren, und die Einzelbit-Parität ist ein wenig schwach (zu hohe Wahrscheinlichkeit eines nicht erkannten Fehlers).
@supercat, Ich sage nicht, dass Ihre Logik nicht solide ist, ich versuche zu sagen, dass Sie an Fälle denken, in denen Einzelbitparität sinnvoll ist. In Situationen mit hohen Fehlern möchten Sie möglicherweise einen Hamming-Code. Wie nützlich ist eine CRC in einem Kanal mit höherer Fehlerrate? Dies liegt nicht daran, dass Sie jedes Mal einen Fehler haben und einfach in einer erneuten Übertragungsschleife stecken bleiben. ECC und Fehlererkennung müssen von Fall zu Fall ausgewählt werden.


Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 2.0-Lizenz, unter der er vertrieben wird.
Loading...