Warum gibt es an Bord von Kommunikationen wie I2C, SPI usw. im Allgemeinen keine Fehlerprüfung?

Einige Fehlerprüfungsmethoden wie Paritätsprüfung, Prüfsumme, CRC usw. werden für die drahtgebundene / drahtlose Kommunikation verwendet. Die meisten ICs mit Schnittstellen wie I2C, SPI usw. verwenden jedoch keine Fehlerprüfmethode.

Lassen Sie uns nach "i2c i / o expander" suchen und ein zufälliges Datenblatt öffnen. Betrachten wir zum Beispiel PCF8574 von TI, einem 8-Bit-E / A-Expander. Wenn während der I2C-Übertragung ein dem Ausgangsregister entsprechendes Bit umgedreht wird, treibt der IC den entsprechenden Pin auf einen unerwünschten Pegel. Warum haben die meisten dieser ICs überhaupt keinen Fehlerprüfungsmechanismus? Ich gehe davon aus, dass selbst bei Kommunikation zwischen ICs alle Signale verrauscht sind. Obwohl die Wahrscheinlichkeit ziemlich gering ist, kann Rauschen einen kleinen Flip verursachen.

Darf dies der Grund sein?: Keiner der Fehlerprüfungsmechanismen garantiert eine vollständig fehlerfreie Kommunikation. Sie können uns nur helfen, die Fehlerwahrscheinlichkeit zu verringern. Es ist offensichtlich, dass die Wahrscheinlichkeit eines Bitfehlers bei der Kommunikation über große Entfernungen höher ist als bei der Kommunikation an Bord. Möglicherweise liegt die Bitfehlerwahrscheinlichkeit für die Kommunikation an Bord auch ohne Fehlerprüfungsmechanismus in einem akzeptablen Bereich.

Was denken Sie?

Sie müssen davon ausgehen, dass bestimmte Dinge auch in einer Welt mit Fehlerprüfung einfach funktionieren. Warum IIC oder SPI wählen, wenn sich normalerweise viel mehr digitale Signale auf einer Karte befinden? Sie scheinen damit einverstanden zu sein, dass diese alle wie beabsichtigt interpretiert werden.

Eine richtig gestaltete Schaltung auf einer richtig gestalteten Platine sollte zuverlässig sein. Stellen Sie sich einen CMOS-Ausgang vor, der einen CMOS-Eingang über eine Karte steuert. Denken Sie darüber nach, was tatsächlich schief gehen kann, abgesehen von einem direkten Komponentenausfall (der ein ganz anderes Problem darstellt als gelegentliche Datenbeschädigungen). Am Antriebsende haben Sie einen FET mit einem maximalen garantierten Widerstand, der eine Leitung entweder mit Vdd oder Masse verbindet. Was genau kann Ihrer Meinung nach dazu führen, dass das empfangende Ende nicht das richtige Niveau hat?

Anfänglich kann der Zustand unbestimmt sein, wenn die Kapazität auf der Leitung geladen oder entladen wird. Dann kann es in der kurzen Spur klingeln. Wir können jedoch die maximalen Worst-Case-Zeiten berechnen, damit sich all dies einpendelt und die Linie am anderen Ende zuverlässig über einem bestimmten Schwellenwert liegt.

Sobald diese Zeit erreicht ist und wir auf die ungünstigste Ausbreitungsverzögerung der Logik gewartet haben, gibt es wenig, um das Signal zu ändern. Möglicherweise denken Sie, dass Rauschen von anderen Teilen der Platine auf das Signal gekoppelt werden kann. Ja, das kann passieren, aber wir können auch dafür entwerfen. Das Ausmaß des Rauschens in einem anderen Teil der Platine ist allgemein bekannt. Wenn nicht, dann kommt es von woanders und in der richtigen Ausführung würde es geklemmt, um auf einige maximale dV / dt und andere Eigenschaften beschränkt zu sein. Diese Dinge können alle für entworfen werden.

Externes Rauschen kann theoretisch die Spuren auf einer Platine stören, aber die Feldstärke müsste für eine ordnungsgemäß gestaltete Platine unangemessen groß sein. Es gibt Umgebungen mit hohem Rauschen, die jedoch auf bekannte Standorte beschränkt sind. Eine Platine arbeitet möglicherweise nicht 10 Meter von einem 10-kW-Sender entfernt, aber selbst das kann dafür ausgelegt sein.

Die Antwort lautet also im Grunde, dass digitale Signale auf derselben Karte, wenn sie richtig ausgelegt sind, für die meisten gewöhnlichen Anwendungen als absolut zuverlässig angesehen werden können. In besonderen Fällen, in denen die Ausfallkosten sehr hoch sind, wie z. B. Platzbedarf und einige militärische Anwendungen, werden andere Strategien verwendet. Dazu gehören normalerweise redundante Subsysteme. Sie halten einzelne Signale auf einer Karte immer noch für zuverlässig, gehen jedoch davon aus, dass gelegentlich Karten oder Subsysteme als Ganzes fehlerhaft sind. Beachten Sie auch, dass diese Systeme viel mehr kosten und eine solche Kostenbelastung die meisten gewöhnlichen Systeme, wie z. B. PCs, unbrauchbar machen würde, weil sie zu teuer sind.

Trotzdem gibt es Fälle, in denen selbst in der normalen Unterhaltungselektronik eine Fehlererkennung und -korrektur angewendet wird. Dies liegt normalerweise daran, dass der Prozess selbst eine bestimmte Fehlerwahrscheinlichkeit aufweist und dass Grenzen überschritten werden. Der Hochgeschwindigkeits-Hauptspeicher für Computer enthält häufig zusätzliche Bits zur Fehlererkennung und / oder -korrektur. Es ist billiger, die Leistung und die ultimative Fehlerrate zu erreichen, indem Grenzen überschritten und Ressourcen zur Fehlerkorrektur hinzugefügt werden, als Dinge zu verlangsamen und mehr Silizium zu verwenden, um alles von Natur aus zuverlässiger zu machen.

Insbesondere für Protokolle, die nicht für die Verwendung über Kabel ausgelegt sind, weist eine ordnungsgemäß gestaltete Karte keine Fehler auf, und eine schlecht gestaltete Karte funktioniert nicht mit oder ohne Fehlerprüfung. Beispielsweise können Störungen auf einem I2C-Bus mit mehreren Slaves den Bus dauerhaft blockieren (*), es sei denn, der Master verfügt über einen Treiber, der SDA hoch ziehen kann, selbst wenn Slaves versuchen, ihn niedrig zu ziehen. Wenn Sie sich dagegen schützen, wird das Protokoll langsamer. Wenn der Bus jedoch so störungsfrei ist, dass ein solches mögliches Verhalten nicht als Risiko angesehen wird, besteht im Allgemeinen kein großer Bedarf an Fehlerprüfungslogik.

(*) Wenn ein Slave glaubt, eine Startbedingung in der Mitte eines Datenbytes zu sehen, das von einem anderen Gerät gelesen wird, und die ausgelesenen Daten als Start eines Befehls interpretiert, der eine Folge von Nullen auslesen soll, ist dies möglich für jedes der Slave-Geräte, um an das andere gesendete Datenbytes so zu bestätigen, dass zu einem bestimmten Zeitpunkt mindestens einer der Slaves den Bus gedrückt hält.

Warum fragen Sie das nur bezüglich der Fehlerprüfung?

Wie können Sie sicher sein, dass die Startbedingung richtig interpretiert wird? Bei drahtgebundener oder drahtloser Kommunikation ist der Frame-Start eine sehr komplexe Kombination von Bits, während es sich bei RS-232 um eine einfache Änderung von hoch nach niedrig und bei I2C um eine einfache Protokollverletzung handelt.

Mein Punkt ist, dass nicht nur die Fehlerprüfung unterschiedlich ist, sondern alle Elemente des Protokolls für On-the-Board-Protokolle viel, viel einfacher sind als ihre Gegenstücke für drahtgebundene und drahtlose Kommunikation. Der Grund dafür ist, dass die Fehlerwahrscheinlichkeit um mehrere Ordnungen niedriger ist als bei der drahtgebundenen / drahtlosen Kommunikation.

Die kurze Antwort lautet, dass viele Geräte, auf die I2C und SPI abzielen, Geräte mit geringem Stromverbrauch, kleinen Befehlssätzen und begrenztem Programmspeicher sind. Die Spezifikationen ermöglichen die Implementierung in Firmware mit geringem Aufwand. Wenn Sie über die Leistung verfügen, können Sie so viele Ebenen hinzufügen, wie Sie benötigen. Diese Ebenen würden jedoch viele kleine eingebettete Anwendungen eliminieren.

Ich konnte keine legide Antwort geben, aber einen Vergleich. Netzwerkprotokolle benötigen Schichten von Mechanismen. Es ist keine gute Idee, alle Aufgaben gleichzeitig auszuführen. Sie haben keine Paket-CRC in PHY, bis die MAC-Schicht den RF-Fehler in 802.11 erkannt hat.

SPI und i2c verfügen alle über eine synchronisierte Taktung, sodass Fehlerraten und Kommunikationskonflikte beim Timing minimal sind und Hardware zur Implementierung als selten angesehen wird.

das ist alles woran ich denken kann.

Finden Sie eine bestimmte Lösung für ein bestimmtes Problem.

Wenn Sie 3 Relais haben, die absolute Zuverlässigkeit erfordern: Messen Sie deren Ausgang mit 3 digitalen Eingängen, einem redundanten Bestätigungssystem, das auf Ihre Anwendung zugeschnitten ist.

Wenn Sie ein benutzerdefiniertes Kommunikationsprotokoll entwerfen würden, um alle Zuverlässigkeitsprobleme ein für alle Mal zu lösen, würden Sie einen häufigen Entwurfsfehler machen. Abweichend von den spezifischen Anforderungen, um allgemein abgelenkt zu werden.

Zunächst ist zu beachten, dass I2C für die Kommunikation zwischen integrierten Schaltkreisen und integrierten Schaltkreisen steht. Es wurde entwickelt, um auf einer Leiterplatte von Chip zu Chip zu laufen. Bei Systemen wie dem Raspberry Pi, die die I2C-Verbindung über Kabel steuern, wird der Standard jedoch nicht für das verwendet, wofür er vorgesehen war, und die daraus resultierende Signalverschlechterung bedeutet, dass die Übertragung viel fehleranfälliger wird. Ich lese diesen Thread, weil ich nach Hinweisen suche, wie ich I2C-Fehler in meinem Raspberry Pi-Setup reduzieren kann.

Das heißt, jedes I2C-kompatible Gerät auf meinem Bus validiert und generiert CRCs, um nach Busfehlern zu suchen. Was nicht nach Fehlern sucht, ist der eingehende I2C-Gerätetreiber unter Linux. Sie können jedoch problemlos online Bibliotheken für C oder Python finden, um die zurückkommenden CRCs zu überprüfen. Was ich Ihnen sagen kann, ist, dass die Überprüfung die Augen geöffnet hat, weil ein alarmierender Teil der zurückkommenden Daten schlecht war. Jetzt verwerfe ich es einfach und versuche erneut, die Daten zu lesen. Die längerfristige Lösung besteht jedoch darin, mein I2C-System so zu gestalten, dass es weniger Abstand / Kapazität enthält. Ich erwäge einen I2C-Schalter, um die Geräte auf ihren eigenen Signalläufen zu isolieren. Oder Sie wechseln zu Modebus oder CANbus, die elektrisch robuster sind (und etwas teurer zu verwenden sind, weil Geräte teurer sind.)

Aufgrund von Schwächen im Standard, die durch lange Signalläufe hervorgerufen werden, gibt es einige Fehler, wie z. B. das Herunterhalten von SDA durch ein Slave-Gerät, die mit typischen Linux-I2C-Treibern nicht wiederhergestellt werden können und ein Aus- und Wiedereinschalten erfordern können. Um Bus-Überbrückungen auf Ihrem Pi zu korrigieren, können Sie die I2C-Pins in allgemeine E / A-Pins ändern und dann den Bus in der Software mit den erforderlichen 9 Takten bei 400 kHz zurücksetzen, bevor Sie sie wieder auf die I2C-Funktion zurücksetzen, aber es gibt viele Fallstricke für Dazu gehört, dass C-Code erforderlich ist, um den CLK-Pin schnell genug für einen Reset umzuschalten. Während ich dies online besprochen habe, habe ich noch keinen Code dafür gefunden und denke darüber nach, ihn einfach selbst zu schreiben. Oder auf I2C aussteigen.

Übrigens denke ich, dass die Verwendung von I2C in der Nähe dessen, wofür es gedacht war, wie das Anschließen von Tochterkarten an einen Pi, ziemlich sicher ist. Ich habe keine Probleme mit solchen Designs gehabt.