Kommunikation zwischen 2 verschiedenen Mikrocontrollern

Mein Arduino läuft mit 16MHz Taktfrequenz; Ein anderer Mikrocontroller läuft mit einer Taktrate von 13 MHz. Wenn ich die digitale Ausgabe direkt von einem Ausgangspin des ersteren zum Eingangspin des letzteren sende, kommt es zu einem Datenverlust und die Übertragung wird beschädigt.

Frage 1: Wie bringe ich die MCUs dazu, die Daten ordnungsgemäß und ohne Beschädigung zu übertragen? Muss ich sie irgendwie synchronisieren oder sollte ich ein anderes Gerät in der Mitte als eine Art Puffer verwenden (oder vielleicht um Daten mit einer niedrigeren Rate zu senden)?

Frage 2: Wenn ich Daten mit einer niedrigeren Rate von MCU#1 zu MCU#2 senden kann, gibt es dann einen Phasenunterschied, der zu einer Datenbeschädigung führen würde?

Antworten (2)

Die Punkte, die Sie machen, sind absolut gültig. Was Sie vermissen, sind einige Details, die Sie erhalten könnten, wenn Sie mehr über Kommunikationsprotokolle lesen. Hier sind einige davon.

  1. Die Kommunikationsgeschwindigkeit sollte immer aus der maximal benötigten Geschwindigkeit gewählt werden, nicht aus der erreichbaren.

Der Grund dafür ist, dass bis auf einige Ausnahmen (Transceiver, Buffer etc.) die übertragenen Daten entweder beschafft oder irgendwie verarbeitet werden müssen. Eingaben von der Benutzeroberfläche funktionieren sicherlich in einer völlig anderen Zeitdimension. Und wenn Ihr Controller mehrere Sekunden braucht, um 1 MB Daten zu verarbeiten, wäre es sinnlos, sie mit einer Geschwindigkeit von 16 Mbit/s zu übertragen.

  1. Da das Signal-Rausch-Verhältnis mit der Entfernung abnimmt, nimmt auch die maximal erreichbare Bandbreite ab.

In der Kommunikation wird häufig der Begriff "Bandbreite-Distanz-Produkt" verwendet. Dies ist ein weiterer Grund, warum direkte MCU-zu-MCU-Verbindungen selten so hohe Datenraten verwenden.

  1. In modernen MCUs sind die Kommunikationsgeschwindigkeiten oft unabhängig von den CPU-Takten.

Zum Beispiel haben Xmega-MCUs periphere Taktgeber, die mit der 2- oder sogar 4-fachen CPU-Geschwindigkeit laufen. Außerdem verfügen Controller mit USB-Schnittstellen oft über eigene Oszillatoren.

  1. Verschiedene Kommunikationsprotokolle werden jetzt in der Hardware unterstützt .

Bei synchronen Protokollen wie SPI (oder I2C auf der Slave-Seite) kommen ihre Taktsignale von verschiedenen MCUs. Die Hardware kann also diesen Takt verwenden, um Daten in den/aus dem Puffer zu verschieben und den Prozessor nur am Ende einer Nachricht einzubeziehen. Fortgeschrittenere MCUs mit DMA-Unterstützung können die Daten sogar zwischen verschiedenen Peripheriegeräten oder Speicher verschieben, ohne die CPU überhaupt zu involvieren.

Asynchrone Protokolle wie UART oder CAN erfordern synchronisierte Uhren. Sie beginnen mit der Zeitmessung beim Startbit und tasten die Eingänge dann einmal ungefähr in der Taktmitte (UART) oder bis zu dreimal bei etwa 75 % des Taktimpulses (CAN) ab. Offensichtlich hängt die Datenintegrität von der Taktgenauigkeit ab. Während CAN-Controller ihre Uhren mithilfe von Phasenverschiebungsinformationen anpassen können, können einfachere UARTs dies nicht.

Eine gängige Praxis, um eine bessere UART-Synchronisation zu erreichen, besteht darin, Quarze mit Frequenzen zu verwenden, die leicht auf übliche serielle Baudraten teilbar sind. Anstatt beispielsweise die oben genannten Xmega-Controller mit ihren maximalen 32 MHz zu betreiben, sieht man sie oft mit 14,7456 Kristallen, die mit 29,5 MHz laufen.

Unabhängig vom Protokoll macht die Kombination aus Hardwarepufferung und DMA-Übertragungen die Übertragungsbandbreite ziemlich unabhängig von CPU-Takten.

  1. Wenn schließlich die Kommunikationsgeschwindigkeit steigt, sieht man eher separate Controller-Chips als eine direkte Verbindung zur MCU.

Darüber hinaus können Sie normalerweise eine parallele Busverbindung zwischen MCU und Hochgeschwindigkeits-Transceivern wie LAN- oder LVDS-Displays sehen. Dies liegt daran, dass der Durchsatz des Kommunikationsbusses schneller wird, als er seriell durch einen einzelnen MCU-Pin übertragen werden kann.

Sie haben Ethernet in einem Ihrer Kommentare erwähnt. Sie sollten sich darüber im Klaren sein, dass bei Ethernet-Geschwindigkeiten von 1 Gbit/s keine 16-MHz-MCU eine Chance hat, diese Datenverkehrslawine zu verarbeiten. Für diese Geschwindigkeiten sollten Sie sich nach viel leistungsfähigerer Hardware umsehen, wie sie beispielsweise in RPi verwendet wird.

Übrigens ist dieser letzte Punkt nur eine andere Form von Punkt 1, dh wenn Sie die Datenrate nicht auf etwas reduzieren können, das Ihre MCU verarbeiten kann, folgt logischerweise, dass Sie einen schnelleren Prozessor benötigen, um den Datenfluss zu bewältigen.

Mann danke für die Antwort. das hilft sehr. aber wie üblich schafft 1 Antwort tausend Fragen. und ich denke, einige davon können direkt vor Ort beantwortet werden. Da Sie gesagt haben, dass die MCU einfach nicht genug Geschwindigkeit hat, um die Daten zu verarbeiten, die von einem anderen Ende kommen, was wäre im Allgemeinen eine Lösung, wenn ich meine Sensordaten an den Remote-Server senden möchte. Ich muss nicht wirklich etwas zurückbekommen. und da es sich um einen Remote-Server handelt, würde ich HTTP als letzte Schicht aller verwendeten Protokolle bevorzugen. oder könnte sogar ein UDP-Datenstrom sein.
Nun, das ist einfach. Jeder Sensor hat seine eigene(n) Datenerfassungsrate(n). Die Genauigkeit hängt oft von dieser Rate ab, daher ist es üblich, sie langsamer als möglich laufen zu lassen, um eine bessere Genauigkeit zu erreichen. Auf der anderen Seite haben Sie einen Server, der auch eine maximale Datenrate hat, die durch Protokoll und Serverfähigkeit definiert ist. Darüber hinaus ändert sich die Verfügbarkeit des Servers mit der Last, dh der Anzahl gleichzeitiger Anforderungen, die er verarbeiten muss. Ermitteln Sie die maximal wünschenswerte Datenrate eines Sensors und die maximal verfügbare Datenrate eines Servers bei maximaler Last. Die geringere der beiden wäre Ihre Zieldatenrate.
Da Sie HTTP/UDP erwähnt haben, muss ich darauf hinweisen, dass Ihre gesamte Frage ungültig ist. Sie kommunizieren nicht nur zwischen zwei MCUs. Sie kommunizieren über einen bekannten Übertragungskanal , der ziemlich hohe Datenraten erfordert, um den Protokoll-Overhead zu bewältigen . Unabhängig von der Erfassungsdatenrate muss Ihr Controller Paketumschläge und im Grunde den gesamten TCP/IP-Stack verarbeiten. Mein Rat wäre, einige der Module mit eingebauten Ethernet/WLAN-Controllern und der dafür erforderlichen Software zu verwenden. Das Lesen des Sensors selbst wäre das geringere Ihrer Probleme.
Nun, das ist der Punkt. Ein Modul mit WLAN oder Ethernet spricht über SPI mit der MCU. und dieser Prozess wirft so viele Fragen auf, dass ich jedes einzelne Bit, das rein und raus geht, festnageln möchte :) alles, was ich gefragt habe, ist die Richtung, und ihr habt sie mir gegeben:)
In der Praxis weiß ich jetzt, dass MCU nicht in der Lage sein wird, mit der Geschwindigkeit zu schreiben, die Ethernet erfordert. Wenn ich also so etwas wie einen Mikroprozessor wie Arm Cortex verwenden und das gesamte Netzwerk dort implementieren würde. ich müsste immer noch über spi mit meinem winzigen mcu sprechen. das war also der Kern der Frage.
Es ist häufiger, USB-zu-Ethernet-Adapter als SPI-zu-Ethernet zu sehen. Aber Sie können SPI sicherlich für langsamere MCUs wie Arduino auf ATmega verwenden. Beachten Sie, dass die MCU in diesem Fall keine eigentliche Ethernet-Kommunikation verarbeitet. Wie ich in Nr. 5 erwähnt habe, übernimmt ein externer Chip wie der ENC28J60 das meiste Reden, indem er MAC- und PHY-Layer implementiert und riesige Puffer bereitstellt.
Maple kann Sie zu einem Chat in die Discord-App einladen, wenn Sie etwas Zeit haben. weil ich so viele Fragen habe, aber das meiste, was ich bei Google finde, ist nur Wiki-Copypaste)
Jahr danach fühle ich mich so dumm, diese Frage gestellt zu haben :)

Sie haben ganz recht mit Ihrer Analyse des Problems, und es ist natürlich gelöst.

Die Lösung ist ein serielles Protokoll Ihrer Wahl. Ein Mikrocontroller verfügt normalerweise über eines oder mehrere der üblichen Inter-IC-Kommunikationsprotokolle:

UART ist "taktlos", daher muss jede Seite über eine Taktrate entscheiden. Die Geschwindigkeit ist niedrig genug, dass jeder Empfänger die richtigen Bits finden kann, und löst das "Phasen"-Problem, indem zusätzliche Bits eingefügt werden, die immer niedrig oder hoch neben einem Bit der entgegengesetzten Polarität sein werden.

SPI und I2C haben zusätzlich zu den Daten eine Uhr. Der Empfänger verarbeitet die Daten nur dann, wenn sich die Uhr ändert. Normalerweise kümmert sich die Hardware um alles. I2C hat eine standardisierte Taktgeschwindigkeitsbegrenzung, während SPI keine solche Begrenzung hat.

Unter diesen ist SPI wohl am einfachsten in diskreter Hardware zu implementieren. Es ist im Wesentlichen nicht mehr als ein Schieberegister und kann direkt mit einer Reihe billiger und gängiger Logikchips verbunden werden. Es gibt auch keine untere Geschwindigkeitsbegrenzung, und Jitter ist kein Problem, da es nur von der Uhr gesteuert wird, sodass es einfach in Software auf einem langsamen Prozessor implementiert werden kann.

Ich werde mir ansehen, wie diese Protokolle erstellt werden und wie die Hardware damit umgeht. vielen Dank. Aber was ist, wenn ich mit einem Gerät kommunizieren muss, das ich selbst gebaut habe und das keine integrierten Lösungen hat? wie würde ich phasen probleme lösen. und Uhren
@AntonStafeyev Ich hoffe, meine letzte Bearbeitung der Antwort hat bei Ihrer Frage geholfen, sonst bitten Sie mich einfach, es noch einmal zu klären!
Da bidirektionales SPI in Wirklichkeit ein Ringpuffer ist, ist es in der Tat recht einfach zu implementieren.
Stellen Sie einfach sicher, dass Ihre Takt-/Sample-Flanken-Polaritäten auf den beiden Geräten übereinstimmen.
Nur um sicherzugehen, dass ich auf dem richtigen Weg bin. Zum Beispiel möchte ich einen Chip machen, der Daten über das TCP-Protokoll sendet. Ich werde diesen Chip über das SPI-Protokoll mit Arduino verbinden. Das Ethernet-Gerät empfängt Daten -> speichert sie im Puffer und sendet dann beispielsweise ein Paket über Ethernet an einen PC. das ist vorerst mein kurzfristiges Ziel.
@AntonStafeyev Klingt vernünftig, abgesehen davon, dass Sie einen Chip herstellen möchten, bevor Sie überhaupt von seriellen Protokollen gehört haben. Ich denke, man muss kleiner anfangen. :)
Ich meinte, wenn ich ein anderes Arduino-Board nehme und es in die Netzwerkschnittstelle einschalte. Es unterstützt also die Kommunikation über WLAN und Ethernet. wie ein normaler PC-Netzwerkadapter, aber für Arduino.
Kommunikation zwischen 2 verschiedenen Mikrocontrollern
AntwortenHierDatenschutz-Bestimmungen1y, 0v