Ich konzipiere gerade ein 19" basiertes modulares System für spezielles Mess- und Testequipment, was auf PIC32 basierten Slave Karten bestehen soll, die über Ethernet mit einem PC verbunden werden. Standardbusse wie VXI o.ä. sind mir zu aufwendig. Ein Ansatz ist ein Router mit externem Ethernet Port auf der Backplane, der mit den Slaves via I2C (Konfiguration), SPI (Durchsatz) und CAN (Echtzeit, InterSlave) verbunden ist. Dies nur zur Info, nicht als Thema dieses Posts. Eine weitere Möglichkeit wäre die Karten direkt an ein 100MBIt Ethernet anzuschliessen, z.B. über einen Switch Chip auf dem Backplane. Zusätzlich CAN für Echtzeit Kommunikation zwischen den Karten. Hat jemand Erfahrungen mit Ethernet (100MBit) über die Backplane. Wie macht man das am besten? Google hat mir hauptsächlich High Speed (10GBit u.ä) für Server geliefert, aber ich brauche 100MBit wo man die PIC32 auf den Slaves ankoppeln kann. Reicht mir auch vollkommen von der Geschwindigkeit.
Nachtrag: Das System soll 12 Slave Slots haben, braucht also mindestens 13 switch ports (in Praxis hat ein switch chip wahrscheinlich 16)
Ehrlich gesagt, habe ich nicht recht verstanden, wie das nachher aussehen soll. Wo ist die Backplane, auf den Slaves? Sind die Slaves auch auf dem 19" untergebracht? Gibt es einen PC, der extern als Master fungiert? Fragen über Fragen. Kannst du ein Blockschaltbild malen? Eventuell kannst du auch mal bei micrel schauen: http://www.micrel.com/index.php/en/technical-support/application-notes.html
Hi, Wenn Du auf der Backplane einen "Router" mit Ethernet Anschluß verbaust und dieser mit den Slaves über SPI, CAN oder was weis ich kommuniziert, wozu muss dann jeder Slave noch ans Ethernet? Gruß Martin
Martin K. schrieb: > Hi, > > Wenn Du auf der Backplane einen "Router" mit Ethernet Anschluß verbaust > und dieser mit den Slaves über SPI, CAN oder was weis ich kommuniziert, > wozu muss dann jeder Slave noch ans Ethernet? > > Gruß Martin Fragen über Fragen....
Martin K. schrieb: > Hi, > > Wenn Du auf der Backplane einen "Router" mit Ethernet Anschluß verbaust > und dieser mit den Slaves über SPI, CAN oder was weis ich kommuniziert, > wozu muss dann jeder Slave noch ans Ethernet? Er hatte 2 Alternativen präsentiert. (1) Router auf Backplane, SPI+I2C+CAN auf den Karten. (2) Switch auf Backplane, Ethernet+CAN auf den Karten.
A. K. schrieb: > Martin K. schrieb: >> Hi, >> >> Wenn Du auf der Backplane einen "Router" mit Ethernet Anschluß verbaust >> und dieser mit den Slaves über SPI, CAN oder was weis ich kommuniziert, >> wozu muss dann jeder Slave noch ans Ethernet? > > Er hatte 2 Alternativen präsentiert. > > (1) Router auf Backplane, SPI+I2C+CAN auf den Karten. > (2) Switch auf Backplane, Ethernet+CAN auf den Karten. upps, Dann würde ich - passender Datendurchsatz vorrausgesetzt - Variante 1 empfehlen. Die Backplane sammelt alles ein und schickt das über Ethernet weiter. Der PC muss dann nur mit einem Teilnehmer über das Ethernet kommunizieren und die einzelnen Slaves benötigen das ganze Ethernet Zeugs nicht. Gruß Martin
Hallo Michael! Vielleicht hilft dir das hier weiter: Die Firma Commend hat meines Wissens ein solches System gebaut. 19" Rack mit einem Einschub der die Switches enthält und die anderen Karten per Ethernet Verbindet: http://www.commend.com/en/intercom/systems/d/2/p/1755%2C1730/category/ge_800_ip_intercom_server_in_19_technology-3.html LG Thomas
@Daniel: Bei Micrell schau ich mal rein. Die haben 8 fach switches @AK: Danke für die Klärung. Hätte ich nicht besser sagen können @oszi: Das ist keine Alternative, da dann haufenweise Kabel rumhängen Anbei ein vereinfachtes Blockschaltbild. Hat jemand Ahnung wie schwierig es ist einen Switch zum laufen zu bekommen. Braucht man dazu einen Prozessor?
Ich würde mich Martin anschließen. SPI ist vermutlich das Mittel der Wahl, da am schnellsten. Bei CAN brauchst du entsprechende µC und die Transceiver, trotzdem ist bei 1 MBit/s brutto Schluss. I2C ist eher noch langsamer. SPI habe ich schon mit bis zu 10 MBit/s gesehen, erfordert natürlich ein bisschen mehr Aufwand bei Leitungsführung und Terminierung. Dafür ist bei SPI der Overhead faktisch Null. Max
Max G. schrieb: > SPI habe ich schon mit bis zu 10 MBit/s gesehen, erfordert natürlich ein > bisschen mehr Aufwand bei Leitungsführung und Terminierung. Dafür ist > bei SPI der Overhead faktisch Null. Dafür entsteht dann der erhöhte Aufwand im SPI/Ethernet-Gateway, d.h. seinem Backplane-Router.
Du könntest auch USB nehmen. Die PICs haben OTG USB, d.h. sie können Host und Device spielen, Du brauchst keine PHYs, nur zwei 7-Port USB-Hubs, Du kannst auf den Karten kleinere PICs nehmen, und summa summarum sinken die Systemkosten erheblich. fchk
Michael S1. schrieb: > > Anbei ein vereinfachtes Blockschaltbild. > > Hat jemand Ahnung wie schwierig es ist einen Switch zum laufen zu > bekommen. Braucht man dazu einen Prozessor? Wie schnell muss denn die Verbindung vom PC zum Slave sein? Eventuell reicht es ja deinen Config-uC an den PC anzuschliessen und über CAN die Slaves anzusprechen? Dann fällt das ganze Switch-Geraffel weg.
Ja mein erster Ansatz war auch SPI (plus CAN, plus ggf. I2C für Konfiguration). Aber der Aufwand für den Router schreckt mich etwas ab. SPI ist bei CPU an CPU Kommunikation ein Beast. Bei Ethernet bekommt man vieles "geschenkt", zumal die Controller die ich vorgesehen habe (und die wir an anderer Stelle schon in grössen Stückzahlen einsetzen) einen Ethernetport und ausreichend Speicher haben.
Michael S1. schrieb: > Ja mein erster Ansatz war auch SPI (plus CAN, plus ggf. I2C für > Konfiguration). > > Aber der Aufwand für den Router schreckt mich etwas ab. SPI ist bei CPU > an CPU Kommunikation ein Beast. Bei Ethernet bekommt man vieles > "geschenkt", zumal die Controller die ich vorgesehen habe (und die wir > an anderer Stelle schon in grössen Stückzahlen einsetzen) einen > Ethernetport und ausreichend Speicher haben. Von SPI habe ich nicht gesprochen. Dein Ethernetkabel geht an den Konfig-uC, der hat dann eine CAN-Verbindung zu den Slaves. Fertig. Kein SPI, kein I2C oder sonstwas. Reicht das von der Geschwindigkeit her?
Michael S1. schrieb: > Eine weitere Möglichkeit wäre die Karten direkt an ein 100MBIt Ethernet > anzuschliessen, z.B. über einen Switch Chip auf dem Backplane. > Zusätzlich CAN für Echtzeit Kommunikation zwischen den Karten. Wenn du 100MBit/s Ethernet hast, wofür brauchst du dann noch den CAN, der gerade mal 1% davon schafft (jaja, ich weiß: Milchmädchen)? Aber trotzdem: man kann mit ein wenig Nachdenken auch mit Ethernet Echtzeit machen. Die Bandbreite reicht da aus. Insbesondere, wenn man direkt aus OSI-Layer 7 (Applikation) auf den Layer 2a (MAC) durchgreift. Und auf einem uC ist das üblich...
Michael S1. schrieb: > z.B. über einen Switch Chip auf dem Backplane. Das ist für ein modulares System eher kontraproduktiv. Auf der Backplane sollte sowenig wie möglich aktive Elektronik verbaut werden wegen der Austauschbarkeit im Fehlerfall - der Sinn so eines Systems ist ja, Karten durch einfaches Rausziehen ersetzen zu können, eine Backplane im Fehlerfall auszutauschen bedeutet aber eine Totalzerlegung des Systems. Wenn überhaupt, würde ich den Backplane-Switch auf eine eigene steckbare Leiterplatte packen. Ausserdem kommt es auf die Stecker an, in einem 19-Zoll-System mit DIN-Steckern ist auf der Backplane garkein Platz für etwas anders. Gruss Reinhard
Hi, Wie man sieht hängt (fast) alles von den notwendigen Datenraten ab und den Echtzeitanforderungen ab. Wenn Du 100MBit zum PC hast, ist das dann das maximum für alle 12 Slaves gleichzeitig? Dann hast Du mit z.B. 10MBit pro Slot wenig Probleme. Oder soll auch eine höhere Datenrate pro Slot erreicht werden, solange die 100MBit Gesamt nicht überschritten werden? Wie sind die Timing Anforderungen, muss ein Datenpaket von einem Slave in x µS den PC erreichen oder erzeugen die Slaves zum Beispiel eigene Zeitangaben die zu den anderen Slaves syncron sind und die Datenpakete dürfen auch später eintrudeln, da steht dann die exacte Zeit drin. Gruß Martin
@Daniel: CAN alleine wäre mir auch am sympatischten, aber das reicht leider nicht vom maximalen Durchsatz. @Lothar: Klar kann man Ethernet für Echtzeit verwenden, aber warum nicht jede Schnittstelle für das benutzen was sie am besten kann. Zumal mein µC beides hat. Es geht auch nicht um eine einzige spezielle Anwendung, sondern quasi um eine mehr oder weniger universelle Platform. Ich habe vor ein IP Protokoll (wahrscheinlich UDP) zu fahren. Wir haben auch schon mit Raw Frames gearbeitet, was zwar Vorteile in Einfachheit und Durchsatz hat, aber wenn da z.B. Kunden PC im Spiel sind ist es immer schwierig die die notwendige Software (WinPcap o.ä) zu installieren. Mein Hauptproblem ist, wie bringt man am einfachsten Ethernet über ein Backplane. Welchen Switch, kann man sich die vielen Trafos sparen, gint es gar einen speziellen backplane PHY, etc.
> Wenn überhaupt, würde ich den Backplane-Switch auf eine eigene steckbare > Leiterplatte packen. Eine gemeinsame, spezielle Leiterplatte oder ein Bus hat oft den kleinen Nachteil, daß im STörfall ALLES finster ist. Deshalb sind leicht beschaffbare Teile im Betrieb günstiger als spezielle Sonderanfertigungen.
Wir haben bisher noch nicht gehoert, was das Ganze soll. Ethernet auf jede Leiterplatte bedeutet einen 32bit controller auf jeder Leiterplatte. Da geht eine Menge an Rechenleistung drauf fuer moeglicherweise wenig. Ethernet iist ein Stromfresser. Moeglicherweise gibt es eine passendere Alternative, wenn wir mal wissen, was das Ganze soll. Ich wuerd mir das Ethernet nicht antun. Nur schon die Verwaltung ... ein eigenes Subnetz fuer das Rack ? DHCP fuer ein statisches Gebilde... macht alles wenig sinn.
Das ganze Gerät ist wohl eine einzige Sonderanfertigung. Backplane wie Karten. Da Verfügbarkeit und Nachbeschaffbarkeit im Gegensatz zu Sonderanfertigungen stehen ist das eine strategische Entscheidung des Gesamtsystems, da kommts auf eine einzelne Karte dann auch nicht an.
Jeeehoo Juppieyeei schrieb: > Wir haben bisher noch nicht gehoert, was das Ganze soll. Ethernet auf > jede Leiterplatte bedeutet einen 32bit controller auf jeder > Leiterplatte. Das hat er mit den PIC32 sowieso vor. Mit oder ohne Ethernet. > Da geht eine Menge an Rechenleistung drauf fuer > moeglicherweise wenig. Für nicht verbrauchte Rechenleistung gibts kein Geld zurück. ;-) > Nur schon die Verwaltung ... ein eigenes Subnetz fuer das Rack ? DHCP > fuer ein statisches Gebilde... macht alles wenig sinn. Adressverwaltung hast er bei allen (topologischen) Bussystemen an der Backe, egal ob CAN, I2C oder Ethernet. DHCP ist kein Hexenwerk, wenn man sowas in der Kategorie eines RPi als Verwaltungsinstanz einbaut. Allerdings will er die MACs zentral verwalten, was DHCP nicht zwingend erscheinen lässt, denn wenn die Node sowieso outband die MAC Adresse vom Stick beziehen soll, dann kann man das auch für die IP-Adresse so machen. Alle Karte in allen Bussen mit zentralen Adressen/IDs zu versehen klingt freilich ein wenig nach Henne-und-Ei Problem.
Na. Wenn's um Messwerte in groessen Bloecken geht, waere allenfalls auch ein SERDES passend. Die bisher nicht beantwortete Frage ist Multimaster oder Master-Slave. Dann gibt es auch noch LVDS, Multipoint-LVDS, usw. Wenn man sich den ganzen Protokoll Overhead sparen will/kann. Ein kleines FPGA fuer eine Handvoll Euro wuerde die Anbindung auch koennen. Falls man denn fuer ein Timing sowieso eins braucht.
Michael S1. schrieb: > Mein Hauptproblem ist, wie bringt man am einfachsten Ethernet über ein > Backplane. Wenn du ausreichend Erfahrung im Entwurf von HiSpeed-Multilayern mit kontrollierter Impedanz hast, ist das Null Problem. Einfach differential pair Leitungen verlegen, die fast identische Eigenschaften wie ein CAT6 twisted pair haben (ganz genau gleich geht nicht). Die Abschirmung ergibt sich von selbst wegen der erforderlichen Impedanz. Gruss Reinhard
Die Frage ist nun was fuer eine Backplane? Eine Aeltere mit 41612, oder eine mit PCI Express. Ich wuerd auf PCI Express gehen. Eine Ahnung zu Highspeed Layout muss eh vorhanden sein.
Jeeehoo Juppieyeei schrieb: > Ich wuerd auf PCI Express gehen. Ich hoffe du meinst bloss die Stecker...
Hallo, was ich vergessen habe, nur der Vollständigkeit halber: auf der Backplane darf kein Halbduplex verwendet werden, nur Vollduplex. Dürfte aber kein Problem sein wenn man darauf achtet. Gruss Reinhard
Bringe es über den Stecker raus, Übertrager auf der Backplane und von da aus auf RJ48 Buchse, wenn günstiger externer Switch, ansonsten dasselbe und dann über Switch, da kannst du dir dann einen Übertrager sparen, brauchst also nur 1x für Switch und device, nicht 2x. Wegen dem Switch, dieser muss zwecks EMV managed sein, sprich die Ports nur aktiv wenn eingesteckt, ev. ein Pin dafür reservieren, oder dies dann über i2c/... lösen.
Hast du mal über eine FPGA Lösung nachgedacht? http://www.altera.com/products/ip/iup/ethernet/m-mtip.html http://www.ixxat.de/switch-ip-core_de.html
Ein paar Antworten: Ich denke an (missbrauchte) PCIe Steckverbinder, damit ist dann genug Platz auf der Backplane und für hohe Geschwindigkeiten ist das auch ausgelegt. Wir sind vertraut mit Impedanzkontrollierten Layouts. Den Wartungsfall Backplane-Austausch statt eine Master Karte nehme ich in kauf. Die Einfachkeit und Kostengünstigkeit des Aufbaus- So kann man z.B. die externen Steckverbindern direkt von der Backplane abgehen lassen. Die schauen dann durch die Alu Rückwand. Es ist keine Sonderanfertigung, aber eine proprietäre Entwicklung mit dem Anspruch viele Meß- und Testprojekte der nächsten 10 Jahre damit abzuwickeln. Daher kann ich auch keine genaue Spezifikation abgeben. Klar ist geswitchtes 100MBit Ethernet ist schnell genug. Ja das muss Vollduplex sein, was aber auch Standard bei Switches ist. Ein externer Switch kommt nicht in Frage wegen des Kabelgedöns. Ein FPGA auf der Slave Karte möchte ich nicht. GROSSE FRAGE: Wie schliesst man das Ethernet am besten ohne Übertrager an. Gibt es dafür vielleicht spezielle PHY?
Michael S1. schrieb: > > Ein FPGA auf der Slave Karte möchte ich nicht. > > GROSSE FRAGE: > Wie schliesst man das Ethernet am besten ohne Übertrager an. Gibt es > dafür vielleicht spezielle PHY? Das hast du falsch verstanden. Der FPGA sitzt auf der Backplane, MII-Signale gehen über den Stecker auf die Backplane an den FPGA, von dort 1x PHY & 1x Übertrager zm PC. - kein PHY auf dem Slave - kein Übertrager auf dem Slave Ob das über Stecker funktioniert weiß ich nicht...
Daniel V. schrieb: > Hast du mal über eine FPGA Lösung nachgedacht? > > http://www.altera.com/products/ip/iup/ethernet/m-mtip.html > http://www.ixxat.de/switch-ip-core_de.html Wäre bei Bedarf an ordentlichem Durchsatz auch meine Wahl. Aber er hat sich bisher über die geplanten Datenraten nicht ausgelassen. Gruß Martin
Michael S1. schrieb: > GROSSE FRAGE: > Wie schliesst man das Ethernet am besten ohne Übertrager an. Gibt es > dafür vielleicht spezielle PHY? Man verwendet kapazizive Kopplung. Es sind keine speziellen PHYs erfordrlich, aber man muss sich die Application Notes der Herstelleer genau ansehen. Manche PHYs benötigen noch shunt coils, da sie interne Terminierungen haben, manche nicht. Dasselbe gilt für die PHYs im Switch!! Wie gesagt, üblicherweise gibt es zum Thema Capactive coupling entsprechende Application notes. Impedanzkontrollierte Leiterbahnen sind für den Aufbau ein Muss. Gruss Micha
Michael S1. schrieb: > Wie schliesst man das Ethernet am besten ohne Übertrager an. Gibt es > dafür vielleicht spezielle PHY? Schau mal nach BroadRReach. Ist zwar aus der Automotive-Ecke und recht neu (lies: teuer), aber kommt ohne Übertrager aus. Max
Michael S1. schrieb: > Wie schliesst man das Ethernet am besten ohne Übertrager an. Gibt es > dafür vielleicht spezielle PHY? Ethernet ist auf der Steckerseite genormt, auf der Übertragerseite zum Chip nicht, da musst du schon selbst engineeren. Die Chipausgänge sind auch nicht für Leitungen gedacht, sondern zum Treiben von Übertragerwicklungen. Fraglich ob es sich lohnt, da lange herumzuexperimentieren, bei Preisen von 1 $ oder so. Gruss Reinhard
Michael S1. schrieb: > GROSSE FRAGE: > Wie schliesst man das Ethernet am besten ohne Übertrager an. Gibt es > dafür vielleicht spezielle PHY? Einen habe ich noch: http://www.ti.com/lit/an/slla310/slla310.pdf
Irgendwie muß ich Reinhard rechtgeben. Das wird zwar ein Trafograb aber die anderen Alternativen scheinen mir zu Problem- und Entwicklungsintensiv. Und Switches mit PHY drin sind billig. Habe mir KSZ8997 (Micrel) angeschaut, mit 2en davon würde das wohl gehen. Switch FPGA mit 14 mal MII: Stimmt, hatte ich erst falsch verstanden. Das sind ca. 14*20=280 FPGA Anschlüsse und das Ganze wird sicher eher ein teures FPGA mit teurer IP. Ungewissheit was der Steckverbinder und die deutlich länger als üblichen MII Verbindungen bewirken. Kapazitive Kopplung: Geht wohl, aber lohnt sich Stress und Risiko wirklich? Hat damit jemand gute Erfahrungen? BroadRReach: Sehe ich keine wirklichen Vorteile für ein Backplane
Michael S1. schrieb: > BroadRReach: > Sehe ich keine wirklichen Vorteile für ein Backplane * Nur zwei statt vier Leitungen * Keine Übertrager Max
Vieleicht könnte das hier auch interessant sein: http://www.kip.uni-heidelberg.de/DCS-Board/datasheets/ethernet/MagneticlessEth.pdf
@Max: Das sind nur mehrere PHYs in einem Gehäuse, die müsste man an einen Switch mit MII Ausgängen anschliessen, oder verstehe ich das falsch? @V: Ja interessant, vielleicht mach ich mal 'ne Testplatine. Was mich ein bisschen irritiert sind die unterschiedlichen Schaltungsvorschläge verschiedener Hersteller.
Ich habe den perfekten Backplane Switch gefunden: zl50408 Leider ist er durch Firmenverkäufe verschollen. Kennt jemand den Chip, einen Nachfolger oder etwas Ähnliches? Hier ist ein älteres Dokument: http://downloads.codico.com/misc/Newsletter/2005/06-2005/ZL50402_Product_Preview_0705.pdf
Je exotischer die Teile werden, desto schneller klemmt der Nachschub. http://en.wikipedia.org/wiki/Zarlink
Da hast Du leider recht. Aber wer weiß, vielleicht gibt es den Chip inzwischen irgendwo unter renomiertem Namen. Habe bisher aber keine Quelle gefunden.
Michael S1. schrieb: > @Max: Das sind nur mehrere PHYs in einem Gehäuse, die müsste man an > einen Switch mit MII Ausgängen anschliessen, oder verstehe ich das > falsch? Richtig, jedenfalls am Switch. Du kannst natürlich auch jeder Karte einen Switch spendieren, quasi als Daisy Chain. Für die einzelnen Karten gibt es (wenn du mit dem Stern arbeiten willst) den BCM89810. Beim Switch dann den BCM54881. Bezüglich des eigentlichen Switch wirst du etwas suchen müssen, mehr als sechsfach (Realtek) habe ich bei einer kurzen Suche nicht gefunden. Und nein, ich bekomme kein Geld o.ä. von Broadcom. Es ist nur die einzige trafolose Lösung, die mir einfällt. Max
Nein, ich dachte daß du den üblichen LAN8710A nimmst, Preis ca .75€ und dann ein 5 port Switch von Micrel mit 1x RMII/MII nimmst, da kannst du dann auch gleich deinen Host Pic32 dranmachen oder die 3x Switches mit RMII/MII back to back betreiben, dann hast du einen 12 port Switch bzw 12 Switches und 3 Hub Ports, ev. die PHY der Hubs rausgebracht, damit man diese auch mit weiteren Chassie verbinden kann oder mit einem Network analyzer draufgehen kann. Die Quad Magnetics kannst du ja zusammen mit dem Footprint für die 33nF Kondensatoren draufsetzen, sodaß du beide Möglichkeiten hast. Ansonsten nimm den AX88615, leicht beschaffbar und hat 5 RMII/MII Interface. Auch ev. brauchbar, KSZ8864RMN , 5.36€ , ist zwar nur 4 port, dafür aber mit 2x mac interface und Mittelfristig auch beschaffbar. MII/RMII Ports brauchen keine kontrollierte Impedanz, und haben auch eine unkritische Länge, es gibt nur kleinere Designvorgaben.
Mein Favorit für das Backplane im Moment ist: - MICREL - KSZ8997 - SWITCH, 10/100, 8PORT, PHY, 128PQFP (~15 US$) - Pulse 4-fach Übertrager ((~7 US$) Also zusammen ~60 US$ Und das sind keine exotischen Bauteile
Ich hab grad was ähnliches vor. Kann man die MII-Interfaces der üblichen MCUs/SOCs direkt an die Switch-Chips klemmen, oder brauchts dazu noch extra Beschaltung ? Wenn ich nicht komplett falsch liege, sollte das ja ohne PHYs gehen. Aber wie siehts da mit maximaler Leitungslänge, Connectoren, etc aus ? --mtx
Bitte 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.