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.

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.

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

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.

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

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.

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.

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).