Sofortige Übertragung, selektive Reaktion

Ich baue ein System auf, bei dem ich genau die gleichen Daten auf Dutzende von Geräten übertragen muss, aber ich muss individuelle Antworten erhalten. Ich muss auch die Anzahl der benötigten Pins begrenzen und eine möglichst schnelle Übertragung haben.

Meine aktuelle Idee ist folgende: Verwenden Sie SPI, um mit allen Slaves zu kommunizieren, indem Sie alle Slaves an denselben SS-Kanal binden. Auf diese Weise erhalten alle Slaves gleichzeitig die gleichen Informationen. Wenn es um den Empfang von Daten geht, würde ich Daten von jedem Slave über I2C anfordern. Auf diese Weise habe ich nur 6 Pins, um mit einer Rate von 10 Mbit / s zu senden und Daten mit 400 Kbit / s zu empfangen. Würde diese Idee funktionieren oder gibt es eine bessere Lösung?

Ich brauche eine schnelle Master-zu-Slave-Übertragungsrate, da die Daten in Echtzeit sein müssen, während die Daten von den Slaves etwas langsamer sein können, weshalb ich mich für I2C entschieden habe.

Gedanken?

Zusätzliche Daten:

  • Der Abstand vom Slave zum Master darf maximal 2 Meter nicht überschreiten. Ab einer Entfernung von mehreren Zentimetern wird es normalerweise viel kürzer sein.

  • Die Anzahl der Sklaven wird nicht auf 25 ansteigen

  • Die empfangenen Daten vom Slave zum Master variieren. Könnte jeweils 10 Bytes oder 100 Bytes gleichzeitig sein.

  • Übertragene Daten an Slaves müssen mit etwa 1 Mbit auf einmal schnell sein. Es gibt eine gewisse Flexibilität.

Danke!

Wenn Sie die vollständige Kontrolle über den Master und die Slaves haben, können Sie wahrscheinlich I2C-Broadcast implementieren und die SPI-Pins einsparen. Die Übertragung ist langsamer als SPI, aber wenn die gesendeten Daten nicht viel größer sind als die zurückgelesenen Daten, hat dies wahrscheinlich keinen großen Einfluss auf das Gesamttiming.
Die Sendedaten vom Master zum Slave sind viel viel größer. Manchmal haben die Slaves nichts zum Master zu übertragen, manchmal sind es etwa 10 Bytes. Aber sie alle müssen Live-Daten mit ca. 1 Mbit pro Sekunde empfangen, aber ich möchte Spielraum, also strebe ich eine größere an
OK. Es ist hilfreich, die Frage zu bearbeiten, um Ihre Anforderungen zu verdeutlichen. Wie viele Daten gesendet und empfangen werden, die tatsächliche maximale Anzahl von Slaves, die maximale Entfernung zu einem Slave usw. (Die Übertragung von 10 Mbit / s per SPI könnte schwierig sein, wenn es mehr als 10-20 Slaves gibt oder wenn es sich um mehrere Meter handelt weg zum Beispiel)
Mit ein wenig Hardware auf Platinenebene können Sie alle Slaves von einem SS-Kanal ansteuern lassen, aber alle ihre MISO-Ausgänge speisen einen N: 1-Multiplexer in den MISO des Masters. Dann benötigen Sie log2 (N) Bits, um einen Slave zum Abhören auszuwählen.
Klären Sie einige der Daten, die Sie gefragt haben. Brian ist ihr Vorteil, einen Multiplexer zu bauen, wenn ein I2C die Anforderungen zum Hören mit 2 Pins erfüllen kann?
@phivms Was ist die Natur der Slave-Geräte (Mikrocontroller oder FPGAs oder etwas Festverdrahtetes)? Ist das ein Produktionstestaufbau? Ist das eine Feldeinstellung?
Mikrocontroller, die Eingaben verarbeiten und Ausgaben anzeigen. Es wird ein Feldaufbau sein
Wie definierst du "gleichzeitig"? Müssen sie alle dieselben Daten empfangen, müssen sie sie im Allgemeinen ungefähr zur gleichen Zeit empfangen, oder verwenden Sie ein synchrones System, bei dem Sie auf die tatsächlichen Latenzen zwischen der Lieferung an jeden Slave achten (z gemeinsame Uhr)?
Vorteil der Vermeidung von I2C? Nur Einfachheit, eine Schnittstelle statt zwei. Wenn das kein Problem ist, scheint Ihr Vorschlag solide zu sein.
gleichzeitig bedeutet, dass alle Slaves denselben Port abhören. Wenn der Master ein Byte aussendet, verarbeiten sie, da alle Slaves auf demselben Port lauschen, die Daten gleichzeitig ohne Verzögerung, damit sie von einem zum nächsten gehen
25 Lasten und 2 Meter auf I2C bedeutet, dass Sie sich um die Antriebsstärke der Geräte kümmern müssen, starke Pull-Ups und/oder Puffer und/oder Busschalter verwenden müssen. Sollte aber machbar sein, wenn man vorsichtig ist.

Antworten (2)

Bei 10 Slaves, die 1 Mbit / s empfangen müssen: Ich würde argumentieren, dass Sie den Bereich der Dinge betreten, die mit einem dedizierten Bus mit mehreren Knoten gelöst werden sollten, anstatt zusammengeschustert zu werden.

Im Allgemeinen ist jedoch die Idee, SPI (mit entsprechender Fan-Out-Pufferung, es wird nicht gesagt, dass jeder SPI-Master einen Bus mit 10 Slaves in unterschiedlichen Entfernungen treiben kann) für die Übertragung und I²C als Rückkanal zu verwenden, ist solide.

Auf diese Weise erhalten Sie jedoch einen Hochgeschwindigkeits-Einweg-Rückkanal mit niedriger Geschwindigkeit ohne Unterbrechung, und das könnte kompliziert werden. Wie Brian Drummond empfohlen hat, würde ein Mux, der MISO nur einem einzelnen Slave zuweist, es Ihnen ermöglichen, den "normalen" bidirektionalen Modus zu verwenden, wobei TX als "Nebeneffekt" "ausgestrahlt" wird, und das würde die Buslogik immens vereinfachen.

Ich würde argumentieren, dass für SPI bei diesen Raten 2m eigentlich ziemlich viel sind . Es funktioniert definitiv, wenn Sie Leiterbahnen und Drähte puffern und sorgfältig entwerfen, aber es ist eine zerbrechliche Sache, die viel Abstimmung erfordern wird.

Alles in allem: Ich denke, Sie könnten mit etwas wie Ethernet besser dran sein. 10 × 1 Mb / s klingt sowieso nicht wirklich so, als würden Sie Arduinos anschließen.

Sehen Sie sich bestehende Busse an:

  • CAN klingt sehr nach dem, was Sie wollen. 2m, hohe Zuverlässigkeit, viel Broadcast-Verkehr, einzelne kleine Datenantworten. Ich denke, CAN funktioniert sehr gut für Broadcast-Daten und "fühlt" sich ansonsten ein bisschen wie ein Multi-Master-I²C-Bus an. Es ist allgemein als in MCUs integriert verfügbar, da es sich um einen Automobilbus handelt. Es ist sehr bewährt. Ich denke, der schnellste Modus läuft mit 1 Mb / s, sodass Sie dort keinen Headroom haben.
  • LIN: billigere Alternative zu CAN (und im Grunde obsolet, weil CAN heutzutage billig ist): zu langsam
  • I²C: zu langsam
  • SPI in einem Schieberegisterring: Gestalten Sie Ihr eigenes Protokoll. Alle deine Sklaven und dein Herr bilden einen Ring; Daten werden einfach in einer Richtung in einer festen Paketlänge durch die Slaves geschoben, wobei ein Header-Byte angibt, woher die Daten stammen; Viele SPI-Peripheriegeräte von Mikrocontrollern führen genau diese Weiterleitung mit ihren RX-Puffer aus, wenn Sie den TX-Puffer nicht ändern.
    Wenn ein Slave etwas zu sagen hat, fügt er sein eigenes Paket ein. Funktioniert, wenn Sie Ihren SPI-Bus schneller als 1 Mb/s takten, sodass zwischen Broadcast-Paketen zuverlässig Lücken entstehen. Nachteil ist: eigene Implementierung -> Fehler, begrenzte Segmentlänge und natürlich Latenz.
  • Ethernet: Benötigt Mikrocontroller, die mit einem PHY (MII, RMII, GMII, …) und Ethernet-PHYs „sprechen“. Auf einer einzelnen Leiterplatte kommen Sie möglicherweise ohne daran befestigte Magnete davon. Die Vorteile sind offensichtlich (gut getestetes Protokoll, einschließlich Broadcast, Unicast, Multicast, Hardwareintegrität, ausgereiftes und einfaches Debugging, Prototyping mit einem gottverdammten normalen PC mit einer normalen Netzwerkkarte). Nachteil: Kosten
  • USB: Master und Slaves sprechen USB 2 FullSpeed ​​= 12Mb/s. Ermöglicht nur Punkt-zu-Punkt (soweit ich weiß), benötigt einen USB-Hub-IC, aber eine sehr elegante, einfach zu testende, relativ billige Lösung. Nachteil könnte die Komplexität der Firmware sein.
Danke! Ich stelle nur klar, dass sie nicht jeweils 1 Mbit / s benötigen, falls Sie das denken, ich würde auch alle auf einmal mit 1 Mbit / s übertragen. Ich beäuge einen 32-Bit-PIC-Mikrocontroller für dieses System. Werde mir mal anschauen was du gesagt hast! Danke!
Also, welche Zahl ist dann eine harte Anforderung? Denn wenn Sie tatsächlich nur ein paar Dutzend kb/s benötigen, funktioniert I²C einigermaßen gut und Sie müssten überhaupt keinen besonderen Tanz aufführen.
Das Senden von Daten an Slaves stellt die viel höheren Anforderungen dar, ich kann wahrscheinlich weniger als 1 Mbit/s Sekunde erreichen, aber es sind einige grobe Berechnungen, die ich erst gegen Ende wissen werde
Ja, wirklich, wenn wir nicht wissen, dass es niedriger sein wird, dann ist 1 Mb/s eine harte Grenze für Ihr Design. Man kann keinen Kuchen essen und noch unentschlossen sein, ob man ihn essen möchte.

Würde diese Idee funktionieren...

Das sollte es, sofern die Schnittstellenvoraussetzungen erfüllt sind (SPI-Fanout?) und die Geräte die Datenraten bewältigen können.

...oder ist ihr eine bessere Lösung?

Möglich, aber warum sollte es dich interessieren? Wichtig ist, eine Lösung zu entwickeln, die zufriedenstellend funktioniert . Ein Vorteil Ihrer Idee ist, dass sie einfach und leicht zu debuggen ist, während eine "bessere" Lösung, die z. Das Multiplexen der SPI-Slave-Antworten erfordert möglicherweise zusätzliche Hardware und komplexere Software, die möglicherweise schwer richtig zu machen sind.

Ich bin neu in diesem Bereich, also habe ich ausgiebig nach der besten Methode recherchiert, und ich hatte das Gefühl, dass dies bisher die beste war, die mir einfallen konnte. Ich wollte sicher sein, dass ich während des Prozesses nichts übersehen habe
Es gibt wahrscheinlich Dutzende von Möglichkeiten, dies zu tun, von denen einige je nach Ihren genauen Anforderungen besser oder schlechter sein können. Aber je komplexer die Lösung, desto schwieriger wird es, sie richtig zum Laufen zu bringen. Ein häufiger Fehler ist zu denken, dass Sie nur einen Bus brauchen, der schnell genug ist, um alles zu erledigen. In der Praxis kann es zu Latenzproblemen kommen, die separate Schnittstellen besser machen (sowie einfacher zu debuggen).
Sofortige Übertragung, selektive Reaktion
AntwortenHierDatenschutz-Bestimmungen1y, 0v