Allgemeines Protokoll für die Datenübertragung von einem System zu einem anderen?

18

Was ist das allgemeine Protokoll zum Senden von Informationen von einem System zu einem anderen? Nehmen wir beispielsweise an, wir haben über einen bestimmten Zeitraum einige Informationen vom Mikrocontroller gesammelt, die wir an einen anderen Mikrocontroller senden möchten. Ich habe von SPI- und I2C-Schnittstellen gehört, aber es ist unklar, wann Sie eine Methode über eine andere anwenden und wie Sie sie implementieren. Gibt es neben SPI und I2C noch andere gängige Methoden? Ist der Implementierungsprozess für verschiedene Mikrocontroller ähnlich? Analysiere ich eigentlich Datenbytes, die ich auf dem empfangenden Mikrocontroller mache?

i2c spi data

— O_O
quelle

4

Was möchten Sie konkret tun?

— Starblue

Wenn Sie sich nur überlegen, wie Sie verschiedene Teile eines Systems dazu bringen, Daten in einer kleinen Box aneinander zu übergeben, kann davon ausgegangen werden, dass die Entfernung sehr gering ist. Der Grund für die Verwendung unterschiedlicher Teile in einer Box ist die Vereinfachung der Funktionen, sodass jedes Teil seine eigene Funktion hat (dies ist hoffentlich sinnvoll)

— O_O

2

das wird normalerweise nicht als system bezeichnet. Das sind mehr, was ich als Subsysteme definieren würde. Sie sind Teil dessen, was Sie als ein einzelnes System betrachten können, das eine einzelne Reihe von Aufgaben erfüllt. Es ist eine Semantik, aber ich denke, viele Ihrer Antworten sind sehr weit gefasst, weil sie keine perfekte Vorstellung davon haben, wonach Sie aus der Frage suchen.

— Kortuk

1

In Anlehnung an das, was Kortuk gesagt hat, hilft es, das Problem zu definieren. Eine wichtige Frage, die Sie sich stellen müssen, ist, ob Sie möglicherweise beabsichtigen, einzelne Subsysteme durch verschiedene Implementierungen derselben Funktion zu ersetzen, oder ob dies ein einmaliger Ist-Entwurf ist. Wenn Sie einen realen Bus verwenden und die Implementierungsdetails der Subsysteme Ihrer CPU zur Verfügung stellen, ist für eine Subsystemänderung eine / w-Änderung für Ihren Controller erforderlich. Wenn Sie eine Kommunikationsschnittstelle verwenden, spielt es keine Rolle, wie Sie eine (-Ersetzung implementieren ) Subsystem, sofern es dasselbe Nachrichtenprotokoll erfüllt.

— JustJeff

Es ist nicht einfacher, Funktionen auf mehrere Geräte aufzuteilen, als Aufgaben zu trennen. Kommunikation und Synchronisation sind komplexer als zwei Prozesse im selben Mikro. Wenn diese Prozesse besonders inkompatible Latenzprofile aufweisen (eines muss schnell aktualisiert werden, während das andere einige Zeit in Anspruch nehmen kann, um einen Block fertigzustellen), gibt es möglicherweise einen gültigen Grund, sie zu teilen. Selbst dann besteht die häufigere Lösung darin, Interrupts zu verwenden oder einen Weg zu finden, um die längere Aufgabe weiter aufzuschlüsseln. Mit dem, was Sie beschrieben haben, neige ich dazu zu denken, Sie sollten dies überdenken.

— Darron

10

SPI und I2C ähneln sich insofern, als sie eher zum Anschließen von Peripheriegeräten an einen Controller oder eine CPU als zum eigentlichen Übertragen von Daten zwischen Systemen verwendet werden. USB ist eine weitere Schnittstelle, die von den Menschen als Kommunikationssystem behandelt werden soll, bei dem es sich in Wirklichkeit um einen Peripheriebus handelt.

Die Kommunikation zwischen Systemen ist nicht mit dem Anschließen eines Geräts an einen Bus vergleichbar. Über den Busanschluss kann der Prozessor direkt auf die Register in einem Gerät zugreifen, während über eine Kommunikationsschnittstelle Datenströme gesendet und empfangen werden können. Ein an einen Bus angeschlossenes Gerät benötigt in der Regel einen Gerätetreiber, wohingegen es bei der Kommunikation für den Host-Computer eigentlich nicht darauf ankommt, was am anderen Ende angeschlossen ist.

Natürlich wird dies die ganze Zeit eine trübe Grenze. Dinge wie PCI und ISA sind unbestreitbar Busse; I2C, SPI, USB sind wohl Busse; Während RS232, RS485 und Ethernet definitiv Kommunikationsschnittstellen sind. Aber dann gibt es Dinge wie CAN-Bus und 1553, bei denen es definitiv darum geht, Daten zu verschieben, aber auf eine sehr komplizierte Art und Weise.

— JustJeff
quelle

CANbus ist sehr involviert und Ethernet nicht? Es ist sehr einfach, mit CAN für einfaches Hin- und Her-Messaging zu arbeiten. Sie sind dedizierte Chips und die meisten Familien unterstützen interne Mikrocontroller.

— Kortuk

@Kortuk - sofern so etwas wie 232 eine Art Peer-to-Peer-Symmetrie hat, während 1553 oder CAN eine Master-Slave-Beziehung auferlegen, ja. Ich glaube nicht, dass ich gesagt habe, dass Ethernet einfach ist, nur dass es den Endpunkten keine Unterscheidung zwischen Buscontroller und Busgerät auferlegt.

— JustJeff

vollständige Offenlegung - meine Meinung zu CAN beruht ausschließlich auf tangentialer Exposition; Es war ein ungenutztes optionales Peripheriegerät auf mehreren Systemen, an denen ich gearbeitet habe, aber nach Hunderten von Durchläufen in der Dokumentation werden Sie ein wenig über die ungenutzten Optionen nur durch Osmose erfahren. Daher gehe ich davon aus, dass es sich bei CAN um eine Architektur vom Typ Controller / Controlled Device handelt.

— JustJeff

Ich denke, Bus hat unterschiedliche Bedeutungen in unterschiedlichen Kontexten. Aus schematischer Sicht kann jede Schnittstelle mit mehreren Signalen als Bus betrachtet werden. Wenn Sie mit mehr Abstraktion zu höheren Ebenen wechseln, ändert der Bus die Bedeutung. Etwas höher, Bus bedeutet normalerweise, dass mehrere Geräte beteiligt sind oder sein können. RS485-Multipoint ist zum Beispiel definitiv ein Bus. Noch viel weiter oben wird RS485 aus der Sicht eines Linux-Geräts wieder zu einer Kommunikationsschnittstelle und wird von einem Bus herabgestuft ... bis Sie darüber eine eigene Protokollebene hinzufügen, die wieder zu einem Bus wird. Auf jeder Ebene hat unterschiedliche Bedeutungen.

— Darron

11

Es gibt keine einzige Möglichkeit zum Senden von Daten, es gibt viele verschiedene Möglichkeiten zur Kommunikation, abhängig von der Entfernung, der Datenrate, der Umgebung, der Anwendung ...

Die unterste Schicht ist die physikalische Schicht , die die Bits tatsächlich bewegt.

SPI und I²C sind für kurze Entfernungen innerhalb eines Geräts vorgesehen, bei denen es nicht zu starken Störgeräuschen kommt, die die Übertragung stören könnten.
Für eine nicht allzu schnelle Kommunikation über Entfernungen von bis zu einigen zehn Metern ist die serielle Kommunikation über RS-232 eine gute Wahl.
Bei stärkerem Rauschen oder größerem Abstand werden Differenzsignale verwendet, z. B. in RS-485. Für eine schnellere Datenübertragung gibt es Ethernet, das immer beliebter wird.
Dann gibt es auch verschiedene Funkstandards.

Auf der physischen Ebene befinden sich weitere Ebenen, die das Senden der Daten organisieren, um Übertragungsfehler, das Routing in einem Netzwerk und vieles mehr zu erkennen und zu korrigieren. Zum Beispiel ist das Internetprotokoll ein ziemlich komplexer Stapel von mehreren Schichten, typischerweise über dem Ethernet-Protokoll.

— sternenblau
quelle

7

Ein einfacher serieller UART kann verwendet werden (eine Tx- und eine Rx-Leitung ohne diskreten Takt) und kann mit Optoisolatoren oder magnetischen Isolatoren leicht an den Übergang zwischen verschiedenen Potentialen (sogar Primär- und Sekundärkreisen) angepasst werden .

Was die Protokolle betrifft, funktioniert alles mit definierten Befehlsbytes und einer Art Prüfsummenschema gut. Es gibt wirklich kein Standardprotokoll, das für alle Arten von Kommunikation geeignet ist. I2C verfügt über Signalisierungsstandards (Definition von Adressierung, Stopps, Starts usw.), aber das Protokoll darüber, was tatsächlich kommuniziert wird, liegt ausschließlich beim Entwickler.

PMBus ist beispielsweise ein Kommunikationsprotokoll für die Stromversorgung, das I2C als physikalisches Medium verwendet.

— Adam Lawrence
quelle

6

Es gibt wirklich kein "allgemeines" Protokoll. Was Sie letztendlich verwenden, hängt stark von der Anwendung ab. Damit wir Ihnen eine bessere Antwort geben können, müssen wir Ihre Anforderungen ein wenig besser verstehen. Sie erwähnen, dass Sie separate Mikrocontroller wünschen, die als Subsysteme miteinander kommunizieren.

Einige Fragen zu dieser Anwendung:

Wird es in diesem Projekt mehr als 2 Mikrocontroller geben?
Was sind Ihre Anforderungen an Geschwindigkeit und Durchsatz? Wie schnell müssen die Informationen dort ankommen und wie oft senden / empfangen Sie Daten?

Wenn Sie Frage 1 mit NEIN beantwortet haben:

Wenn in diesem Projekt nur 2 Mikrocontroller vorhanden sind, können Sie auf jeden Fall UART zwischen ihnen verwenden. Wenn beide die Kommunikation einleiten müssen, verwenden Sie die Flusskontrolle. Andernfalls sollte es trivial sein, Daten in eine Richtung zu senden. Zum größten Teil sollte es "schnell genug" sein, vorausgesetzt, Sie wählen eine der höheren Baudraten. I2C und SPI eignen sich normalerweise nur für die Master / Slave-Architektur.

Wenn Sie Frage 1 mit JA beantwortet haben (mehr als 2 Controller):

Wenn sich in Ihrem Projekt mehr als 2 Mikrocontroller befinden, welcher initiiert die Kommunikation? Wird es nur eine Master-Steuerung sein (dh Master-Slave-Architektur)? Oder könnte eines der Subsysteme jederzeit sprechen?
Muss eines der Subsysteme miteinander kommunizieren? Beispiel: für Geräte A, B und C: A kann an B und C senden und B kann an A und C senden usw.

Jetzt brauchen Sie etwas Skalierbareres, mit dem Sie adressierbare Geräte auf einen gemeinsamen Bus legen können. Die Antwort auf diese Anschlussfragen hilft Ihnen bei der Entscheidung zwischen I2C und SPI (Master-Slave) oder etwas wie CAN (Multi-Master).

Ihr Mikrocontroller verfügt höchstwahrscheinlich über ein UART-Peripheriegerät, die anderen (insbesondere CAN) sind möglicherweise nur auf höherwertigen Chips verfügbar. In beiden Fällen sollte ausreichend Dokumentation vorhanden sein, wie diese Peripheriegeräte zum Verschieben von Bytes verwendet werden können.

— Jon L
quelle

5

Wie @Jon feststellte, ist ein Problem bei der Auswahl einer Kommunikationsschnittstelle, ob immer eine Entität für die Initiierung der Kommunikation verantwortlich ist oder ob möglicherweise mehr als eine Entität dafür verantwortlich ist. Eine verwandte Frage ist, ob ein Unternehmen immer bereit ist, unerwünschte Mitteilungen zu erhalten. SPI wird häufig in Anwendungen verwendet, in denen eine Seite immer für den Empfang von Kommunikation bereit ist. So etwas wie ein 74HC595-Schieberegister ist beispielsweise nie "beschäftigt". Während SPI für die Kommunikation zwischen einem Mikrocontroller und Hardware, die das Mikro steuern soll, gut ist, ist es für die Kommunikation zwischen zwei Mikrocontrollern nicht gut. Wenn zwei Prozessoren mit I2C-Hardware für die Kommunikation verwendet werden, kann die Software (innerhalb sehr großzügiger Einschränkungen) so lange dauern, bis sie mit den Vorgängen fertig ist. ohne Datenverlust zu verursachen. Wenn ein Prozessor 100 Mikrosekunden benötigt, um jedes eingehende Byte zu verarbeiten, würde dies den Durchsatz erheblich einschränken, aber der Absender würde langsam genug sein, damit der Empfänger mithalten kann. Der einzige Weg, der im Allgemeinen mit SPI passieren kann, ist, wenn man eine separate Leitung für das Handshaking hat.

I2C ist wirklich ein wunderbares Protokoll. Die größten Einschränkungen, die es daran hindern, das perfekteste Protokoll zu sein, das man sich vorstellen kann, sind:

Die Geschwindigkeit ist etwas begrenzt; SPI kann viel schneller gehen, und sogar UARTs können manchmal etwas schneller gehen
(2) Während es sehr praktisch ist, dass I2C nur zwei Drähte benötigt, müssen beide Drähte zur bidirektionalen Open-Collector-Kommunikation fähig sein. Dies macht es schwierig, I2C über Repeater zu senden.

Persönlich würde ich gerne sehen, dass Controller-Hersteller eine Drei-Draht-Variante von SPI unterstützen, die Handshaking beinhaltet. Mir ist jedoch kein Controller bekannt, der dies tut.

— Superkatze
quelle

Witzigerweise sollten Sie dies erwähnen ... Ich muss eine SPI-Schnittstelle in eine nicht bidirektionale I2C-ähnliche Schnittstelle umwandeln (das erste Byte ist eine Adresse), damit viel mehr Geräte am Bus teilnehmen können, als ich für die Chipauswahl habe . Es funktioniert, wenn Ihre Slave-Geräte alle FPGAs sind. :) Ich wünschte auch, es gäbe etwas zwischen diesen beiden großen synchronen Standards.

— Darron

Oh, ich schätze, ich sollte klarstellen, dass die Ausgabefreigaben für die Slaves erst aktiviert werden, wenn das Adressbyte empfangen wird. Sie bleiben aktiviert, bis die Einzelchipauswahl deaktiviert wird. Es ist also offensichtlich ein wenig anders als bei normalem SPI + High-Level Protokoll. Aus Sicht des Master-Geräts ist es jedoch vollständig mit Standard-SPI kompatibel. (wie ein Mikroprozessor)

— Darron

@ Darron: Cool. Ich frage mich, was passieren müsste, damit die Branche einen Drei-Draht-Kommunikationsbus mit offenem Standard verwenden kann, bei dem die Drähte aktiv hoch und niedrig geschaltet werden. Ich denke, es gibt einen kleinen Konflikt zwischen dem Vermeiden passiver Klimmzüge und dem Zulassen, dass ein Gerät einen Interrupt signalisiert. Dies kann jedoch durch Hinzufügen eines Interrupt-Pins behoben werden, der nach Belieben des Slaves mit dem Master verbunden werden kann (meine derzeitige Implementierung von Das Protokoll hat nur einen Slave, so dass es über die Datenrückleitung asynchron signalisieren kann, wann es gewartet werden soll.

— Superkatze

@darron: Um die Verwendung eines Chip-Select-Pins zu vermeiden, signalisiert der Master den Start des Befehls, indem er zwei ansteigende Flanken auf der Datenleitung sendet, während der Takt niedrig ist. Slaves können anzeigen, ob ihr letztes Datenbyte gültig war, indem sie einen Statuswert ausgeben, wenn sowohl Takt als auch Daten niedrig sind (Leerlauf); Andernfalls geben sie an, dass sie Aufmerksamkeit wünschen, wenn der Takt niedrig und die Daten hoch sind. Wenn ich Master-Hardware für dieses Protokoll entwerfen würde, würde ich die Fähigkeit hinzufügen, 8 Taktimpulse zu senden, bei denen die Datenleitung den Takt spiegelt, und bei Slave-Hardware eine asynchrone Zählung der Anzahl ansteigender Flanken während ...

— supercat

@ Darron: ... ein Datenbyte. Bei fünf oder mehr wird das Byte ignoriert (der Slave geht davon aus, dass der Master an einem Datenbyte interessiert ist, aber nichts hat, was er eigentlich sagen möchte). Das wäre jedoch nicht annähernd so wichtig, als hätte der Slave den Status des letzten Bytes bei niedrigem Takt gemeldet (wenn das Slave-Gerät ein Prozessor wäre, würde der Master wissen, dass der Slave nicht bereit war und hatte die letzte "Transaktionsmöglichkeit" verpasst

— supercat

3

In keiner bestimmten Reihenfolge scheinen die beliebtesten Physical-Layer-Instanzen für 2 CPUs in derselben Box zu sein:

Daisy-Chain-SPI (wie von JTAG verwendet)
Select-Wire-Per-Slave-SPI
"TTL-Level RS-232" oder "asynchrone serielle Start-Stopp-Kommunikation" (direkte Verbindung des UART TX-Pins einer CPU mit dem UART RX-Pin einer anderen CPU)
I2C
8-Bit-Daten + Strobe (z. B. paralleler IEEE 1284-Druckeranschluss)
Shared Memory (nur eine CPU steuert gleichzeitig den Adress- / Daten- / Steuerbus)

Diese Physical-Layer-Instanzen (sowie andere Physical-Layer-Instanzen für 2 CPUs in separaten Boxen) stellen der Software, die die höheren Ebenen des Kommunikationssystems implementiert, in der Regel einen Bytestrom bereit.

Intelligente Programmierer schreiben die Software so, dass sie, wenn der Hardwaretechniker eine Instanz der physischen Schicht herausnimmt und diese durch eine vollständig andere Instanz der physischen Schicht ersetzt, nur einige Funktionen neu schreiben müssen, um ihren Ausgabestrom von Bytes zu speisen auf die Hardware und lesen Sie einen Strom von Bytes von der Hardware zurück, und das gesamte Protokollmaterial auf höherer Ebene funktioniert unverändert weiter.

Das Protokoll zum Senden von Informationen von einer CPU an eine andere beinhaltet fast immer die Interpretation des Bytestroms als eine Reihe von Paketen:

Präambel
Header
(möglicherweise ausgeblendete) serialisierte Daten
Anhänger

Einige Leute scheinen es zu genießen, völlig neue, benutzerdefinierte, inkompatible Protokolle zu erfinden, indem sie (2) eine von vielen Arten von Header-Strukturen mit (3a) einer von vielen Arten von Serialisierungsdaten mit (3b) einer von vielen Arten von kombinieren Flucht vor diesen serialisierten Daten mit (4) einer von vielen Arten von Anhängern.

Einige der einfachsten Protokolle zum Einkapseln von Daten in ein Paket umfassen:

Etwas kompliziertere Protokolle zum Einkapseln von Daten in ein Paket umfassen:

Es gibt eine lange Liste von Protokollen bei

Vielleicht lesen Sie gerne "Protocol Design Folklore" von Radia Perlman, in dem beschrieben wird, wie das Protokolldesign schief gehen kann.

— Davidcary
quelle

3

Kein einziges "allgemeines" Protokoll. Die Wahl kann (zum Beispiel) von Folgendem abhängen:

Entfernung
erforderlicher Durchsatz
Verfügbarkeit spezieller Peripheriegeräte
Geräuschpegel
Notwendigkeit einer optischen Isolation
Kritikalität (tolerierbare Fehlerrate)
verfügbare CPU-Leistung an beiden Enden
verfügbare I / O-Pins an beiden Enden

In vielen Fällen müssen Sie die physikalische Schicht (Signalpegel) von der Datenverbindungsschicht (+/- die Art und Weise, wie Daten codiert werden) trennen (siehe OSI-Modell, untere 2-4 Schichten). Mögliche phyiscal Schichten sind zum Beispiel:

einfache 5V oder 3,3V oder sogar 1,8V TTL
eine der oben genannten Möglichkeiten, jedoch Open-Collector anstelle von Push-Pull
Balanced Lov Voltage Signaling (oft mit FPGAs verwendet)
ausgeglichene höhere Spannung (RS485, RS432)
single ended höhere Spannung (RS232)
symmetrisch trafo-gekoppelt (verschiedene Ethernet-Versionen, PDIF-Audio)
optisch (optisches Ethernet, Toslink)

Sie können eine Zeile verwenden, um Daten- und Uhrzeitinformationen zu übertragen, oder diese in mehrere Zeilen aufteilen. Letztere waren früher beliebt, aber heutzutage verwenden die meisten neuen / schnellen Protokolle in der Regel eine Leitung (oder ein Leitungspaar, das als eine Leitung fungiert).

Es gibt viele Möglichkeiten, Daten und Takt in einer Zeile zu codieren. RS232 verwendet traditionell NRZ, es gibt Machester-Codierung und die verschiedenen Formate, die auf Festplatten mit merkwürdigen Namen verwendet werden, Zeile 2.7 RLL.

Um es zusammenzufassen: Es gibt unzählige Möglichkeiten, Kommunikation zwischen Systemen herzustellen. Und ich habe noch nicht einmal Konnektoren oder übergeordnete Aspekte wie Fehlererkennung und -wiederherstellung, Datenkodierung, Komprimierung und Verschlüsselung erwähnt ...

— Wouter van Ooijen
quelle