I2C zentrale Fehlerbehandlung

Ich hoffe auf weitere Meinungen zur Ergänzung meiner eigenen.

Ich hoffe, mein System so zu optimieren, dass es I2C verwendet, um alle meine Fehlerberichte zu verarbeiten.

Mein System kann anhand des folgenden Fotos verstanden werden.Geben Sie hier die Bildbeschreibung ein

Mein System besteht nur aus Arduino UNOs und jeder von ihnen hat seine eigenen internen Prozesse, aber ich möchte, dass Warnungen und Fehler an eine zentrale Fehlerbehandlungs-UNO gemeldet werden, wie das beigefügte Diagramm zeigt. Die „Arbeiter“-UNOs haben ihre eigenen Prozesse und werden mit ihren individuellen Geschäften fortfahren, solange die „Alles-Gut-Flagge“ hoch ist (ein HIGH GPIO wird auf der „Arbeiter“-Seite angezeigt).

Wenn die zentrale UNO einen katastrophalen Fehler feststellt, würde sie das gesamte System herunterfahren, indem sie das „All-Good-Flag“ auf Low setzt.

Ich gehe davon aus, dass die I2C-Leitungen anständig ruhig bleiben. Ich möchte das I2C auf der "Worker"-Seite nutzen, damit der "Worker" bei jedem Fehler in einem der "Worker"-Prozesse den Fehler an das "zentrale" Board sendet, wo er katalogisiert, welches Board gesendet wurde den Fehler und entscheidet, was mit dem besagten Fehler zu tun ist.

Ich glaube, um dies am besten zu erreichen, würde ich den "Central Error Handler" als Master (Listener) und die "Workers" als Slave (Sender) machen, bin mir jedoch etwas unsicher, wie ich ein solches System implementieren soll .

Hinweis: Alle Unos sind innerhalb von 2 Fuß voneinander entfernt.

Jede Anleitung wird sehr geschätzt.

Vielen Dank an alle im Voraus, Carlo

Antworten (2)

Bei der Verwendung von UNOs haben Sie eine direkte Steuerbarkeit. Bei I2C braucht man einen Master und ein paar Slaves (das weißt du ja schon).

Ein guter Ausgangspunkt ist, den Master die Slaves regelmäßig um einen Fehlerbericht bitten zu lassen. Wenn ein Slave einen Fehler sendet oder ein Slave nicht antwortet, fährt der Master das System herunter.

Für ein noch robusteres System (aber viel schwieriger einzurichten) ist, dass die Verbindung bidirektional ist. Der Master muss fehlerfrei von den Slaves hören, andernfalls fährt er das System herunter. Das Problem ist, dass das System außer Kontrolle geraten kann, wenn der Master ausfällt. Wenn die Slaves periodisch auch vom Master hören müssen, um wach zu bleiben, dann liegt Redundanz vor. Auf diese Weise werden die Slaves automatisch heruntergefahren, wenn der Master ausfällt. Dies ist schwierig einzurichten, da es problematisch sein kann, eine Verbindung einzurichten und stabil zu halten.

Mein Vorschlag wäre, das System in den Deaktivierungsmodus zu versetzen. Wenn die Verbindung aufgebaut und stabil ist, drücken Sie eine Taste am Master, um das System zu aktivieren.

Ein reiner I 2 C-Bus hat keine zusätzlichen Alert- und Interrupt-Leitungen. Auf einem solchen Bus kann der I 2 C-Slave keine Transaktionen initiieren, und der I 2 C-Busmaster kann kein reiner Zuhörer sein. Der Busmaster kann jedoch die Slaves nach dem Fehlerflag abfragen. Außerdem sieht es so aus, als ob Sie planen, eine Alarmleitung außerhalb des I 2 C einzurichten
. (Etwas verwandte Threads: this und this .)

Während Sie den I 2 C möglicherweise mit 2-Fuß-Verbindungen zum Laufen bringen können , ist ein Bus mit mehreren 2-Fuß-Verbindungen möglicherweise zu groß für einen einfachen I 2 C, und es wird Ihnen schwer fallen, ihn zuverlässig zum Laufen zu bringen . Eine Art verteiltes Steuerungssystem, das Sie beschreiben, wird oft mit CAN gemacht. Es wurde entwickelt, um über lange Kabel zu funktionieren, und es ist Peer-to-Peer, sodass jeder Knoten Transaktionen initiieren kann. (Gleichzeitig bin ich mir nicht sicher, ob Sie das CAN der Würmer öffnen wollen, weil CAN komplexer ist als I 2 C. Andererseits, wenn Sie sich nicht mit CAN befassen, könnten Sie wie dieser Typ enden mit überwuchertem I 2 C-Bus .)

I2C zentrale Fehlerbehandlung
AntwortenHierDatenschutz-Bestimmungen1y, 0v