Hallo alle beisammen, ich bin gerade dabei versch. Bussysteme miteinander zu vergleichen und zu evaluieren. Ziel ist es, ein Bussystem zu finden / entwickeln, welches in erster Linie schnell ist (> 5Mbit Nutzdaten), einfach erweiterbar ist (keine Hardware oder neue Leitungen für weitere Knoten), und Mutlimaster fähig ist. Ich habe schon einige Iden gesammelt und verschiedene Ansätze niedergeschrieben. Einen Ansatz davon will ich nun hier vorstellen und darüber diskutieren, ob es überhaupt Sinn macht, was man besser machen könnte, Fehler aufdecken, ... Ich möchte SPI als Half-Duplex Multimaster Bus system konzipieren mit eingebauter Hardware Kollisionserkennung.Dazu habe ich mal folgendes Blockschaltbild zusammengestellt (siehe Anhang). Folgende Punkte erleutern die Funktion meines Busses: - Im Idle Zustand befindet sich jeder Knoten im Slave/Listen Mode - Falls ein Knoten etwas schicken möchte, horcht er an der SCLK Leitung ob der Bus frei ist. Wenn ja, schaltet er um in Master mode und beginnt mit der Kommunikation. - Im Sendemodus kann der Master nichts empfangen. - Falls zwei Knoten gleichzeitig beginnen zu senden entsteht eine Kollision. Diese Kollision wird durch den Treiber und das Xor-Gatter vom Master selbst erkannt. Durch Bit Arbitrierung dominiert immer das LOW bit über dem High bit (Wie bei CAN). - Bei einer Kollision können Daten verloren gehen. Dies ist genau dann der Fall, wenn ein Master an gerade einen anderen, sendenden Master eine Nachricht schickt. Der Master bekommt diese Daten nicht mit, da er währen des Sendens nicht Empfangen kann. - Um dieses Problem zu umgehen sendet jeder Master am Anfang ein für jeden Knoten einzigartiges "Busanfrage Token". Das Token mit der höchsten Priorität gewinnt. Die Slaves die das Token erhalten haben bleiben im Listen Modus, die Master welche eine Kollision entdeckt haben, gehen auch zurück in den Listen Modus. Dann beginnt die eigentliche Kommunikation des Masters, welcher den Token hat. Während des Schreibens dieses Postes ist mir auch eingefallen, dass das ganze ja auch Voll-Duplex fähig sein müsste indem man einfach auch die MISO Leitungen miteinander verbindet. Ob dies dann nicht mehr Aufwand wegen des Master/Slaves Umschaltens zum richtigen Zeitpunkt bedeutet sei mal dahingestellt. Was haltet ihr von dieser Idee. Freue mich auf eure Antworten. Beste Grüße, Manuel
Angehängte Dateien:
-
Multimaster_SPI.png
16 KB
Warum willst du SPI für etwas vergewaltigen, für das er nicht und niemals geschaffen wurde? Und zwar das Protokoll nicht, und auch die Physik nicht. Das, was du willst, ist eigentlich ein schnellerer CAN... > Ziel ist es, ein Bussystem zu finden / entwickeln, > welches in erster Linie schnell ist (> 5Mbit Nutzdaten), einfach > erweiterbar ist (keine Hardware oder neue Leitungen für weitere Knoten), > und Mutlimaster fähig ist. Hört sich für mich ziemlich nach Ethernet an... Manuel schrieb: > ob es überhaupt Sinn macht Nein. Du hast viele, viele Seiteneffekte bei deinem Ansatz noch nicht beachtet. Vermutlich, weil du dir die anderen Bussystem noch nicht angeschaut und aus deren Verhalten gelernt hast. Wie handelst du z.B. Laufzeiten ab? Wie Leitungseflexionen? Wer macht die Busarbitrierung? Und vor allem: bei Multimastersystemen mußt du IMMER mit Kollisionen rechnen, diese auflösen und die resultierenden Fehler behandeln können.
Du versuchst 3 Dinge unter einen Hut zu bringen, die sich widersprechen: einfache Hardware - hohe Geschwindigkeit - komplexes Protokoll. Von einem der drei Punkte musst Du Dich verabschieden, und für den Rest gibt es schon gute Lösungen. Eine Alternative wäre, 2 Lösungen zu kombinieren, z.B. SPI mit einem I2C-Hilfsbus. Datenübertragung erfolgt über SPI, Adressierung und Multimaster-Arbitrierung auf einem eigenen I2C-Bus.
Klaus 2m5 schrieb: > Adressierung und > Multimaster-Arbitrierung auf einem eigenen I2C-Bus. Warum nicht über Interrupt-Leitungen? Gruß Anja
>- Falls zwei Knoten gleichzeitig beginnen zu senden entsteht eine > Kollision. Diese Kollision wird durch den Treiber und das Xor-Gatter > vom Master selbst erkannt. Durch Bit Arbitrierung dominiert immer > das LOW bit über dem High bit (Wie bei CAN). Geht so nicht. Die geschilderte Arbitrierung funkt. nur, wenn nur 1 Leitung die Informationen enthält. Hier sind es min. Clk. u D-Leitung. Somit könnte man zwar die Kollision erkennen, aber die Arbitrierung würde so nicht funktionieren. Bei Multimastersystem muss man aber nicht unbedingt mit Kollisionen rechen, wenn ein Bus-Arbiter da ist, der die Sache regelt. (Ggfs muss man dann die Kollision nur deketieren, nicht das Protokoll automatisch arbitrieren) Weil bei SPI (und anderen vergleichbaren Protokollen auch) alles taktsynchron ist, ist auch die max Bus-Länge rel. stark begrenzt. (Mit Source-Synchr wäre schon grössere Bus-Länge möglich. In diesem Fall wäre nur der Skew zw Clk- u Data-Signal relevant, aber auch der kann mit grösser werdender Leitungslänge immer grösser werden)
Hallo,
danke an alle für eure raschen und informativen Antworten.
@Lothar:
Warum ich SPI "vergewaltigen" will liegt an der Tatsache dass dies laut
Spezifikation schnell (> 10MBit/s) und einfach (Protokoll) ist. Dies
bietet mir kein mir bekanntes anderes Bussystem.
Ethernet oder auch USB, welche diese Geschwindikeiten hinbekommen
würden, sind für mich keine wirklichen Bussysteme, da ich nicht einfach
die Datenleitungen aller Knoten miteinander Verbinden kann. Ich brauche
Hubs und Swtiches für die Verteilung.
Angesehen hab ich mir wirklich schon viele Bussystem, was natürlich
nicht heißt, dass ich alle kenne, vermutlich exisitert bereits ein für
mich perfektes System; falls jemand eins kennt, bitte mir nennen :). Ich
hab z.B.: auch über das FlexRay nachgedacht jedoch ist mir da der
Overhead und das Protokoll zu komplex, ein einfacheres wäre mir lieber.
@Klaus:
Ok da muss ich mich nochmal genauer ausdrücken. Einfache Hardware ist
jetzt zu unspezifisch, kann ruhig auch kompliziert sein. Es sollen halt
bei hinzukommenden Knoten keine weiteren Leitungen für den Bus benötigt
werden. Der Bus soll nur Mutlimasterfähig und schnell sein.
> einfache Hardware - hohe Geschwindigkeit - komplexes Protokoll.
Und das Protokoll soll ja nicht komplex sondern einfach sein.
@Anja:
Interruptlösungen fallen weg, da ich für jeden Knoten dann eine
Interruptleitung benötige.
@MCUA:
Das mit der Arbitrierung wäre mir eigentlich egal, solang er die
Kollision erkennt (Deswegen ja auch die Token Nachricht, welche da ist
um nur einen Master von zeitgleich sendenden die Erlaubnis zum
Weitersenden zu geben).
Ich hab mir natürlich auch andere Ansätze ausgedacht, wie z.B.: das
ganze auf RS485 aufzuziehen. Habe auch diverse Wandler SPI<-> RS485, ...
angesehen, leider sind diese nicht schnell genug. Da wäre das ganze
Asynchron und die Arbitrierung würde so funktioneren, dass nicht nur
Kollisionen erkannt werden, sondern auch die Nachricht mit der höhsten
Priorität duch geht und gelesen werden kann.
Im Prinzip hat Lothar es genau auf den Punkt gebracht. Was ich suche ist
ein schneller CAN, nur wenn es dan noch nicht gibt, muss ich mir selbst
einen zusammenbauen.
Beste Grüße,
Manuel
Manuel schrieb: > Einfache Hardware ist > jetzt zu unspezifisch, kann ruhig auch kompliziert sein. nimm Ethernet > Der Bus soll nur Mutlimasterfähig und schnell sein. Deine Logik zur Kollisionserkennung macht in aber gerade langsamer. > Und das Protokoll soll ja nicht komplex sondern einfach sein. Ein Protokoll, dass mit Kollisionen und Datenverlust leben muss, ist immer komplex.
>Das mit der Arbitrierung wäre mir eigentlich egal, solang er die >Kollision erkennt Nur Kollisions-erkennung kann man mit Überprüfen des Protokolls auf Gültigkeit (bsp CRC) gleichsetzen. Allerdings müssen wegen der Signallaufzeiten die Module umso länger warten, je grösser das Netwerk ist bzw je länger die Buslinie ist. (Bei Point-to-Point ist das grundlegend anders) Die 1. Frage ist doch, wieviele m lang der Bus sein soll (danach richtet sich auch die Wartezeit der Module), und 2. wie schnell er sein soll. RS485 (auch CAN-Treiber) geht max bis ca 12Mbps (längenabhängig). LVDS geht viel höher, bei geringerer Länge.
Wobei sich RS485-Treiber nicht wirklich für Kollisionserkennung eignen, weil der sich dabei ergebende Buszustand nicht eindeutig ist und von verschiedenen Nodes unterschiedlich interpretiert werden kann.
@MCUA: Also mit Buslänge in Metern sind wir schon weit darüber. Das System sind mehrere Platinen welche gestackt werden. Insgesamt rechne ich mit 10-20cm maximaler Buslänge. Und die Geschwindigkeit ist wie bereits erwähnt >= 5MBit/s Nutzdaten. Wenn also angenommen eine durchschnittliche Message 4 Byte Nutzdaten enthält und 4 Byte Overhead das Protokoll erzeugt brauche ich 10MBit/s, sollte sich mit RS485 noch gut ausgehen. LVDS geht natürlich auch, und wäre bei viel höherer Geschwindigkeit auch zu empfehlen. Ich bin jedoch an die 0815 Schnittstellen von gängigen Microcontrollers angewiesen soll heißen (UART, SPI, I2C, USB, ...). @A.K.: Das ist wahr daran habe ich auch schon gedacht, bzw. hab ich schon wo gelesen. Da die CAN Treiber dies können hätte ich z.B.: so einen eingesetzt, vorrausgesetzt er unterstützt die genannten Geschwindigkeiten.
Ja, CAN-Treiber sind für Wired-Or optimiert, ähnlich
OpenCollector-Schaltung. Die sind von der Geschwindig her aber
langsamer.
RS485-Treiber sind schneller, haben aber diese o.g. Eigenschaften so
nicht. Aber auch mit denen lässt sich ja ein Fehler im Protokoll
erkennen, denn wenn ein Slave dazwischen funkt wird mit Sicherheit das
Protokoll (bei einigen Bits) gestört sein, also kann man es erkennen.
Und der RS485-Treiber wird es auch überleben.
Wenn man also die Wired-Or-Arbitrierung (ähnl CAN) nicht braucht und nur
Fehler erkennen will, kann man auch RS485-Treiber nehmen, weil
schneller.
>Insgesamt rechne ich mit 10-20cm maximaler Buslänge.
Da gehen einige Gbps! / oder BusLVDS mit ca 400..800Mbps.
MCUA schrieb: > erkennen, denn wenn ein Slave dazwischen funkt wird mit Sicherheit das > Protokoll (bei einigen Bits) gestört sein, also kann man es erkennen. Nicht notwendigerweise. Wenn sich zwischen den beiden Streithähnen einer Kolision genug Kabel befindet, dann kann der ziemlich hohe Kurzschlusstrom zusammen mit dem Leitungswiderstand dazu führen, dass beide Seiten ihren eigenen Zustand auf der Leitung sehen und eine Kollision unentdeckt bleibt. Der RS485-Treiber wird es überleben, aber bei häufiger Kollision möglicherweise übergangsweise aus thermischen Gründen abschalten.
>Wenn sich zwischen den beiden Streithähnen einer >Kolision genug Kabel befindet, dann kann der ziemlich hohe >Kurzschlusstrom zusammen mit dem Leitungswiderstand dazu führen, dass >beide Seiten ihren eigenen Zustand auf der Leitung sehen und eine >Kollision unentdeckt bleibt. Nicht wenn, wie oben erwähnt, lange genug gewartet wird (je länger der Bus, umso länger muss man warten), oder das Protokoll lange genug ist. >Der RS485-Treiber wird es überleben, aber bei häufiger Kollision >möglicherweise übergangsweise aus thermischen Gründen abschalten. Der RS485-Treiber sollte in die Strombegrenzung gehen und auch im thermisch erlaubten Bereich bleiben. (Es gibt ja genug RS485-Busse, mit Linien-Topologie. Und alle erkennen ja auch Fehler auf dem Bus)
MCUA schrieb: > Nicht wenn, wie oben erwähnt, lange genug gewartet wird Was ändert das am grundlegenden elektrischen Problem? Es kann der Zustand eintreten, dass jede Seite "ihren" Pegel sieht, weil die Differenz am Leitungswiderstand der Busleitung draufgeht. > Der RS485-Treiber sollte in die Strombegrenzung gehen und auch im > thermisch erlaubten Bereich bleiben. In die Begrenzung ja, aber die lässt auch einige hundert mA zu, und weil das auf die Dauer ungesund ist haben die Transceiver eine thermische Sicherungsschaltung drin.
MCUA schrieb: > (Es gibt ja genug RS485-Busse, mit Linien-Topologie. Und alle erkennen > ja auch Fehler auf dem Bus) Entscheidend ist nicht, ob man manchmal Fehler erkennen kann, sondern dass man Kollisionen mit Sicherheit erkennt. Ich weiss nicht, unter welchen Rahmenbedingungen das wirklich zum Problem wird, aber man sollte diese Problematik im Auge behalten.
>> Nicht wenn, wie oben erwähnt, lange genug gewartet wird >Was ändert das am grundlegenden elektrischen Problem? Es kann der >Zustand eintreten, dass jede Seite "ihren" Pegel sieht, weil die >Differenz am Leitungswiderstand der Busleitung draufgeht. Dass jede Seite IMMER nur ihren Pegel sieht wird wohl in Wirklichkeit nicht so sein. Und wenn, dann ist der Max-Strom zu hoch, einige hundert mA ist nach meiner Auffassung zuviel. >Entscheidend ist nicht, ob man manchmal Fehler erkennen kann, sondern >dass man Kollisionen mit Sicherheit erkennt. Wie gesagt, hängt von der Protok.Länge ab. Wenn jeder Slave (die etliche m auseinander liegen) nur ein paar Bits (auch noch mit sehr grossem Strom) versendet, dann wird der Fehler wahrscheinl nicht erkannt. Wenn das Protokoll aber deutlich länger ist (und auch nicht ein extrem grosser Strom fliesst), wird die Wahrscheinlichkeit viel grösser, dass die Fehler auch erkannt werden. Ausserdem , wenn als Bsp, in der Mitte ein Slave verrückt spielt und seinen extrem grossen Pegel auf den Bus treibt, werden die Slaves daneben das auch bemerken, weil das dort Empfangene erheblich von vom Master Erwarteten abweicht. Somit werden dann auch diese Slaves wieder eine Fehlermeldung verschicken. Jedenfall kann man nicht sagen, dass mit RS485 prinzipiell kein Fehlererkennen möglich wäre.
Angehängte Dateien:
-
rs485.png
2,6 KB
Danke für die interessante Diskusion. Ich denke zwar nicht, dass meine Leitungslänge von 20cm zum Problem mit den verschiedenen Pegeln auf einem Kabal führt, aber gut zu wissen, dass es nicht selbstverständlich ist dass immer überall der selbe Pegel an einem Kabel liegt. Ich habe mich jetzt ein wenig schlau gemacht, und mir vesch. Bus Line Transceiver angesehen. Unter anderem hab ich auch einen MultiPoint LVDS gefunden: (SN65MLVD207D http://docs-europe.electrocomponents.com/webdocs/0c5d/0900766b80c5dcc0.pdf) Den Transceiver würde ich wie im ersten Beispiel mit einem XOR erweitern, um Kollisionen während der Übertragung erkennen zu können (und nicht erst nacher bei der Messageauswertung per Software). Der Vorteil mit diesem Transceiver ist, dass alle Teilnehmer während des Sendens auch Empfangen können. Somit würde die Arbitirerung wie beim CAN Bus funktionieren, und bei einer Kollision ginge trotzdem die Nachricht mit der höchsten Priorität durch. Bei einer Kollision wird der Sendeteil sofort über den DE Eingang des Transceivers abgeschaltet. Der Block mit dem Collision detect ist entweder per Hardware ausgeführt oder der XOR Ausgang wird vom Micorcontroller ausgewertet. Kommt drauf an wie schnell der Sendeteil bei einer Kollision abschalten muss. Was haltet ihr von dieser Idee? Grüße, Manuel
Manuel schrieb: > @MCUA: > Also mit Buslänge in Metern sind wir schon weit darüber. Das System sind > mehrere Platinen welche gestackt werden. Insgesamt rechne ich mit > 10-20cm maximaler Buslänge. Du brauchst also eine Backplane. Was spricht gegen z.B. VMEBus? Der ist uralt, aber standardisiert. Allerdings braucht er einen Master - den braucht SPI aber auch. Alternativ Ethernet. 10Base2 ist ebenfalls uralt, erfüllt Deine Anforderungen aber auch. Oder wie schon vorgeschlagen: Arbitrierung über einen separaten Bus und eigentlicher Datenaustausch dann über ein serielles Protokoll. Oder auch: LIN verwenden mit einem Master, der im Round-Robin-Verfahren Zeitschlitze zuteilt. Oder: Daisy-Chain, jede Karte redet nur mit dem rechten Nachbarn und hört auf den linken, der letzte muss dann wieder an den ersten zurückgekoppelt werden. Was genau soll das ganze eigentlich geben? Muss jede Leiterplatte mit jeder mit 5 MBit/s reden können? Max
Manuel schrieb: > Und die Geschwindigkeit ist wie bereits erwähnt >= 5MBit/s Nutzdaten. > Wenn also angenommen eine durchschnittliche Message 4 Byte Nutzdaten > enthält und 4 Byte Overhead das Protokoll erzeugt brauche ich 10MBit/s... Soso, 4 Byte Nutzdaten-Pakete mit mindestens 5Mbit/s netto. Die Anwendung würde ich gerne mal sehen. Manuel schrieb: > Den Transceiver würde ich wie im ersten Beispiel mit einem XOR > erweitern, um Kollisionen während der Übertragung erkennen zu können Verabschiede Dich von Deinem XOR-Murks, dass wird so nie funktionieren. Es wurde schon mehrfach darauf hingewiesen, dass sich bei einer Kollision irgend ein undefinierter Mischpegel einstellt, den Dein XOR vielleicht richtig interpretiert oder auch nicht. Außerdem wirst Du durch die unterschiedliche Laufzeit von XOR und dem Bus-Tranceiver garantiert falsche Kollisionsauswertungen bekommen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.