Bester elektrischer Mikrocontroller-Bus für synchronisiertes Hochgeschwindigkeits-Sampling von Slaves

Für eine Abtastrate von 0,25 Hz sollte jeder Bus in Ordnung sein. CAN hat mehr "eingebaute" Funktionen für Nachrichtenpriorisierung und Arbitrierung usw. als RS-485. Sie hätten also mit CAN ein etwas komplexeres, aber etwas höheres Protokoll. Die elektrischen Signal- und Stromversorgungsanforderungen für die Verdrahtung wären in beiden Fällen praktisch identisch. Sie sagen, dass "synchronisiertes" Sampling erforderlich ist, definieren jedoch nicht, welche Präzision und Genauigkeit und Latenzzeit für "Synchronisation" erforderlich sind.

Wenn Sie die Abtastung innerhalb von Nanosekunden "gleichzeitig" haben müssten, hätten Sie einige erhebliche zusätzliche Bedenken in Bezug auf Kommunikationslatenz, Verkabelungsverzögerungen usw. Aber ich vermute, dass Sie die Anforderung nicht definiert haben und "relativ" niedrig betrachten Leistungsbusse, ohne irgendeine Art von Trigger-/Taktungs-Strobe für den Sampling-Trigger zu erwähnen, können Sie mit einer Synchronisation bis auf das Niveau von mehreren Mikrosekunden oder länger zufrieden sein. Wenn dies der Fall ist, ist wahrscheinlich jeder Bus für Sie geeignet, abhängig von der Architektur Ihres Systems.

Führen die Knoten autonome Abtastungen mit der vorgegebenen Rate und den festgelegten Abtastzeiten durch? Wenn dies der Fall ist, macht es dies einfacher, solange die Abtasttakte an den Knoten ausreichend synchron gehalten werden. Wenn die Knoten auf dem Kommunikationsbus jeweils auf einen "Jetzt abtasten"-Befehl warten, sollten Sie überlegen, was passiert, wenn der Nachrichtenempfang gelegentlich verzögert wird oder von einem oder mehreren Knoten verloren geht. In einem solchen Fall kann die Synchronisation der Abtastung verloren gehen oder der Abtastzeitpunkt verzögert werden.

Wie sieht es mit der Übermittlungsreihenfolge der Stichprobendaten an den Controller aus? Wenn sich die Knoten einen gemeinsamen seriellen Bus teilen, muss einer sein Ergebnis vor den anderen senden, sodass die Möglichkeit von Busarbitrierungskonflikten besteht. Sofern nicht parallele unabhängige Busse zu jedem Knoten gehen, werden die Datenübertragungen einiger Knoten dadurch verzögert, dass sie später als andere Knoten übertragen werden. Wie funktioniert die Bus-Schlichtung? Wird jeder Knoten der Reihe nach abgefragt oder spricht er der Reihe nach? Wie sieht es mit der erneuten Übertragung von Nachrichten aus, wenn aufgrund von Buskonflikten, Übertragungsfehlern oder anderen Umständen keine Bestätigung empfangen wird?

Wenn die Knoten lokale Uhren haben, die verwendet werden, um die Abtastdaten mit einem Zeitstempel zu versehen und möglicherweise die Abtastzeiten zu bestimmen, wie wird die Uhrensynchronisierung aufrechterhalten? Sie sehen also, Sie haben am Ende die gleichen Arten von potenziellen Problemen und potenziellen Lösungen / Architekturen, unabhängig davon, welchen Bus Sie verwenden. CAN bietet einige Protokollfunktionen auf höherer Ebene, um bei der Strukturierung einiger Aspekte von Buskonkurrenz, Arbitrierung, Priorisierung, Neuübertragung, Fehlererkennung usw. zu helfen. Sie können ähnliche Dinge in RS-485 mit Ihrem eigenen Protokoll implementieren. Letztendlich sind die wichtigsten Aspekte des Kommunikationsnetzwerks die architektonischen Entscheidungen und Anforderungen in Bezug auf Dinge wie Fehlertoleranz, Timing, Synchronisation, Fehlererkennung, Fehlerbehandlung, Netzwerkdesign und -verkabelung usw.

Eine Möglichkeit, die Sie nicht erwähnt haben, ist Ethernet, das in einigen eingebetteten Anwendungen mit PTP erweitert wurde, das hilft, Ereignisse zwischen verteilten Knoten zu synchronisieren und mit Zeitstempeln zu versehen. Typischerweise sind die ICs und Komponenten für die Implementierung von Ethernet im Vergleich zu CAN oder RS-485 etwas teurer, obwohl dies von Ihren Implementierungsentscheidungen abhängt und Dinge wie ein hohes Maß an elektrischer Isolierung zwischen der Verkabelung und den Knoten erforderlich sind (möglich mit zusätzlichen Schaltkreisen in CAN). , RS-485 oder Ethernet, aber eigentlich nur als grundlegender Implementierungsansatz in Ethernet erwartet). Ethernet bietet Ihnen ein mögliches standardisiertes Mittel zur Stromversorgung der Knoten, obwohl die Stromversorgung häufig auch zusammen mit CAN oder RS-485 erfolgt.

Sie erwähnen serielle Kommunikation und hier sind ein Paar Chips, die bis zu sehr hohen Datenraten gut funktionieren. Sie müssen Daten nicht mit diesen hohen Raten übertragen, aber Sie benötigen eine minimale Taktfrequenz von 10 MHz: -

Es hat zehn digitale Eingänge, dann werden sie für die Übertragung über ein symmetrisches Twisted-Pair-Hochgeschwindigkeitspaar serialisiert, dann hat der Empfänger (Deserialisierer) zehn digitale Ausgänge, die den zehn Eingängen entsprechen, die Sie in den Serialisierer eingespeist haben.

Ich habe diese zum Kombinieren von Sensorausgängen mehrmals verwendet und sie eignen sich hervorragend für Jobs mit hoher und niedriger Geschwindigkeit. Maxim führt ein Pin-für-Pin-Äquivalent durch, aber der Sender benötigt einen anständigen Power-Reset oder startet nicht richtig.

Ohne viel Aufhebens habe ich 10x 20 Mbit/s serielle Datenströme in die Eingänge eingespeist und 25 Meter geschirmtes Twisted-Pair-Kabel hinuntergeschickt. Die Deserialisierung war perfekt und Sie erhalten ein wiederhergestelltes Taktsignal. XTALs an beiden Enden müssen nicht zu eng aufeinander abgestimmt sein - ich erinnere mich, dass ich das Setup mit einem Signalgenerator an einem Ende getestet habe und wir die Frequenz um etwa +/- 7 % variieren konnten, bevor die Verbindung unterbrochen wurde. Billiges Twisted-Pair (50 Ohm) sollte für ein paar Meter in Ordnung sein, aber vergessen Sie nicht, mit 50R zu terminieren.

Haben Ihre Sensoren serielle Datenausgänge? Wenn nicht, verwenden Sie ADCs mit seriellem Ausgang. Wenn Sie mehr IO benötigen, machen sie auch größere, aber ich habe diese größeren nicht verwendet, daher kann ich nicht für sie sprechen.