S3Bus Ich hätte gern Eure möglichst konstruktiven Kommentare zu einem geplanten Projekt. Wir haben oft mit speziell entwickelten Meßanordnungen und Funktionstestern zu tun und ich entwerfe gerade ein ein neues Bussystem dafür (Ich nenne es mal S3BUS, weil es 3 serielle Standards unterstützt). Es basiert auf 19" Technik, genau gesagt ein 3HE, 42 TE Rack im Umgehäuse, mit 12 Steckplätzen für Europakarten. Ich werde PCIe Steckverbinder auf dem Backplane verwenden (missbrauchen). Das gibt mir die Möglichkeit einen PIC32, ein FPGA und DC/DC Wandler auf der Backplane zu plazieren. Der PIC32 steht mit allen Slots per I2C, CAN und SPI (sternförmig über FPGA) in Verbindung und dient quasi als Datenrouter. Zusätzlich hat jeder Slot 3 oder 4 Statusleitungen die über das FPGA angeschlossen sind. Der Slot kennt seine Adresse. Als Spannungen habe ich 24V (das ist die Rack Versorgung), 3.3V und +/-15V vorgesehen. Zur Außenwelt steht das Rack über Ethernet, USB, CAN und RS232 in Verbindung, wobei die diesbezüglichen Steckverbinder direkt vom Backplane abgehen und aus der Alu Rückwand schauen. Dito für die 24V Stromversorgung. Die Vorteile die ich mir Verspreche und auch der Grund warum ich kein Standard Bussystem nehmen will sind: - Einfacher und kostengünstiger Aufbau des Grundgerätes (nur eine Platine) - Einfache Steckkarten, minimal wird nur I2C gebraucht. - Ist trotz Einfachheit professionell aufgebaut und sieht auch so aus - Trotz der Einfachheit ist dies ein allgemein verwendbares Bussystem - Über einen Adapter kann ich einen existierenden Fundus von 100x100mm Buskarten (unser 20 Jahre alter, quasi in die Jahre gekommener parallel Bus) benutzen. Das sind verschiedene I/O, Meßkarten, programmierbares Netzteil, Schnittstellentester etc. Was haltet Ihr davon? Kennt Ihr ein fertiges System was dem ähnlich ist?
habe vergeseen zu sagen: ich plane den Schaltplan des Backplanes und die Routing Software bei Interesse zu open source zu machen.
Michael S1. schrieb: > ich entwerfe gerade ein ein neues Bussystem > dafür (Ich nenne es mal S3BUS, weil es 3 serielle Standards > unterstützt). Neue Bussysteme sind immer völlig sch**** und amateurhaft wenn sie keinen Technologieschritt machen. Momentan gibt es für alle Anwendungsbereiche im Hinblick auf Geschwindigkeit, Störfestigkeit, Modularität, .... (von 1wire bis LVDS) völlig ausreichende weitestgehend standardisierte Bussysteme. Jetzt bastelt wieder jemand ein System dazu das zu nichts kompatibel ist. Das ist einfach Mist. Wenn du irgend eine Technologie realisieren willst die es noch nicht gibt (noch mehr Geschwindigkeit, höhrere Störfestigkeit o.Ä.) dann ok ansonsten ist das mMn. Faulheit oder Dummheit. Es ist schon eine Frechheit wieviele verschiedene Busse/Verbindungen es am Computer gibt nur weil sich keiner auf irgendwas einigen kann. Es gehört ein Stecker für alles und fertig. Technisch alles machbar. Nimm was standartisiertes oder einen defacto Standart (wie bei CAN & Vector) und gut is. Michael S1. schrieb: > Ich werde PCIe > Steckverbinder auf dem Backplane verwenden (missbrauchen). Wie stellst du sicher, dass niemand eine PCIe-Karte einsteckt und die dann gegrillt wird? PCIe ist nicht geschirmt, also musst du das dann wieder an deinen Aufsteckplatinen nachholen bzw. entsprechend robuste Busse wählen die stückweise auf Schirmung verzichten können. Michael S1. schrieb: > Der PIC32 steht mit allen Slots per I2C, CAN und > SPI (sternförmig über FPGA) in Verbindung und dient quasi als > Datenrouter. Du willst ja doch garkein neues Bussystem machen sondern nur ein Breakout board. PIC32 ist aber nix gut für viele schnelle Daten. Trotz DMA und allem drum und dran Flaschenhals. FPGA mit einer Ethernet PHY und einem CypressFX2 (USB2.0) oder FX3 (USB3.0) und du wirst glücklicher. Michael S1. schrieb: > Zusätzlich hat jeder Slot 3 oder 4 Statusleitungen die > über das FPGA angeschlossen sind. Um sozusagen die Störfestigkeit und Vorteile des Busses wieder zu ruinieren. Schlechte Idee. Differentiell übertragen ?! Pure Statusleitungen mit Pullup sind Mist. Michael S1. schrieb: > Die Vorteile die ich mir Verspreche und auch der Grund warum ich kein > Standard Bussystem nehmen will sind: Du verwendest nur Standart Bussysteme. Deine Statusleitungen sind Murks, das ist doch kein neues Bussystem. Sorry. Michael S1. schrieb: > - Ist trotz Einfachheit professionell aufgebaut und sieht auch so aus Murks bleibt Murks. Michael S1. schrieb: > - Trotz der Einfachheit ist dies ein allgemein verwendbares Bussystem Nein ist es nicht. Da musst du dann schon was normiertes und standardisiertes verwenden.
I2C ist der wohl am meisten missbrauchte Bus. Wenn Du wenigstens Busswitches (zB PCA9548A) auf der Backplane verwenden würdest. Und von der Störfestigkeit im Industriellen Umfeld hast Du Dir auch zielsicher das schlechteste ausgesucht. Plus: hotplugfähig isses wohl auch nicht. Es ist genauso wie in der Kryptografie: Wenn jemand meint, er hätte dort ein neues, supersicheres Verschlüsselungsverfahren entwickelt, dann kann man davon ausgehen, dass da mit Sicherheit Schwachstellen drinstecken. fchk
Ich muss mich über den Ton hier schon manchmal wundern. Naja ich habe ein dickes Fell. Und so pauschalierte unreflektierte Schimpftriaden lass ich eher an mir abprallen. Und trotz aller entgegengebrachten Schläue, habt Ihr keinen Standard Bus benannt, wie kommt denn das? Ich suche keinen High Speed Bus! Die 10MBit der SPI reichen für die meissten Mess- und Testaufgaben vollkommen. Und in anderen Fällen reicht sogar I2C wenn nur ein paar Messwerte pro Sekunde anfallen. In anderen Fällen ist CAN eine gute Lösung. Ich stelle quasi existierende Standards elektrisch und mechanisch sauber zu einem Bussystem (und genau das ist es) zusammen. Hotplug habe ich kurz überlegt, aber wegen des Aufwands und mangels Anwendungsfall verworfen. Ein PIC32 ist für den reinen Datentransport zu einem PC alle mal schnell genug. Warum mit Kanonen auf Spatzen schiessen. Auf den 20cm ist ein I2C bei guten Layout auch ohne LVDS störsicher genug. Und die SPI und Statusleitungen sind ja noch kürzer. Ich brauche eine simple Lösung. Ich habe keinen Anspruch ein genormtes System zu entwickeln, sondern nur handwerklich sauber verpackt, einfach und günstig meine Mess- und Testsysteme aufzubauen.
Habe vergessen: Normale PCIe Karten passen da mechanisch nicht rein, kann also auch beim DAU nichts passieren. Obwohl allzu dumme User beim Klientel ohnehin rar sein sollten ;)
Michael S1. schrieb: > Ich muss mich über den Ton hier schon manchmal wundern. Naja ich habe > ein dickes Fell. Und so pauschalierte unreflektierte Schimpftriaden lass > ich eher an mir abprallen. Warum schreibst du dann hier? Du wolltest doch Meinungen hören. Ist aber bei allen so, die hier eigene Ideen posten. Sie bitten um Meinungen, wollen aber in Wirklichkeit nur einfach Lob und Anerkennung haben. Kritik ist nicht erwünscht. Dann werden sie pampig. Du reihst dich da schön sein. > Ich brauche eine simple Lösung. Ich habe keinen Anspruch ein genormtes > System zu entwickeln, sondern nur handwerklich sauber verpackt, einfach > und günstig meine Mess- und Testsysteme aufzubauen. Hier liegt dein Fehler. Du hast im Eingangspost vollmundig einen neuen Bus angekündigt, ja sogar mit Namen. Das suggeriert genau das Gegenteil von dem obigen Absatz. Das suggeriert du willst einen allgemeinen Bus hier vorstellen, der auch für andere Aufgaben verwendet werden kann. Und zählst auch vollmundig die Vorteile auf. Das stößt natürlich auf harsche Kritik, weil so was schüttelt man nicht kurz aus dem Ärmel, ist meist überflüssig und auch meistens Murks. Wenn du geschrieben hätte, du willst ein paar Meßgeräte über bestimmte Busse mit zusätzlichen Datenleitungen verbinden und möglichst schnell und einfach und nur für diese eine Aufgabe, dann wären die Reaktionen ganz andere gewesen. gruß cyblord
Lob brauche ich hier nicht, Zustimmung oder konstruktive Kritik ist was ich suchte. Ist es pampig, unreflektierte, pauschal begründete und nicht konstruktive "Murks" aussagen abzulehnen? Ich denke nicht. Es ist halt schade, dass ein technisches Forum mit Gefühlausbrüchen verseucht wird, statt zur Sache Stellung zu nehmen. Für mich sind I2C, CAN, SPI erst mal Standardschnittstellen, selbst wenn sie busförmig verdrahtet werden können. Ein Bussystem (kurz Bus) entsteht durch vereinheitlichte Nutzung von Schnittstellen, sowohl elektrisch wie auch mechanisch, so dass man Komponenten erzeugen kann, die zusammenpassen. Und genau das habe ich S3BUS genannt und der hat wie jedes Bussystem einen bestimmten Zweck und seine Grenzen. Für Videoprocessing ist der natürlich nicht geeignet, aber für eine Echtzeitsteuerung mit verteilten Prozessoren, auch wenn das nicht die primäre Aufgabe ist, würde er schon gehen. Und das ganze schüttele ich deshalb aus dem Ärmel, weil ich auf Standards setze, die wir elektrisch und softwaremässig beherschen. Wenn Ihr Euch für so schau haltet, dann zeigt mir doch eine Lösung, ohne ein Fuder Platinen oder Geräte auf dem Tisch zu verteilen. Und ohne die Entwicklung der Komponenten zur Wissenschaft zu machen. Wenn Du das kannst, dann stampfe ich meine Idee als Murks ein.
Und Du bist ignorant. Deine Posts sind kein Gewinn für dieses Forum. Was hast Du eigentlich für einen Hintergrund? Hast Du überhaupt fundiertes Wissen in diesem Bereich? Bisher hat sich das jedenfalls nicht gezeigt.
Ja nu, I2C ist ein sch*-Ding. Ernstlich, der ist geeignet, um etwas Logik auf einer Platine einzusammeln, für mehr aber auch nicht. Am liebsten möchte man den schon garnicht über die Platine hinaus verteilen, noch weniger auf Stecker führen und nach draußen geben... Da gibt es zwar dann Krücken für galvanische Trennung mit Richtungserkennung und so weiter, aber das macht meistens mehr Probleme als dass es nutzt. Zuletzt habe ich in meiner Studienarbeit zusammen mit anderen im Team ferngesteuertes Auto mit Elektrik ausgestattet. Das wurde dann eine Backplane mit den nach DIN genormten Messerleisten (VG-Leiste). Verteilt auf dem Bus haben wir dann geregelte Spannungsversorgungen für Logik und Arbeitspunkte sowie einen CAN-Bus. Als Basis für die Steckkarten gab es dann eine quasi leere Platine, die nur den Stecker, den CAN- und einen kleinen Mikrocontroller enthielt. Den Rest hat der Andwender dann drumherumgebaut. Jetzt kommt aber die etwas abweichende Anforderung, denn in diesem Fall hat ein etwas größerer Mikrocontroller im Zentrum gesteckt. Abgesehen vom CAN-Bus war das nun tatsächlich nur ein Breakout-System für die Ports dieses Controllers. Du solltest dir mal einig werden, wohin du willst. Warum drei Systeme zusammenfrickeln? Nimm einen einzigen Bus. Und pack dann auf jede Steckkarte dieselbe Schnittstelle, z.b. bestehend aus einem FPGA oder einem Controller, für den es ein Grundgerüst an Software gibt. Mit simplen Bussen wie SPI usw. sparst du wenig. Aber wenn der zukünftige Anwender ein sauberes API für die Kommunikation bekommt und sich nur noch in den Prozessor setzen muss, dann haste etwas gewonnen. Durch das API kann es auch ein komplexerer/"modernerer" Bus sein, denn das API nimmt dem Anwender möglichst viel davon wieder ab.
Michael S1. schrieb: > Wenn Ihr Euch für so schau haltet, dann zeigt mir doch eine Lösung, ohne > ein Fuder Platinen oder Geräte auf dem Tisch zu verteilen. VXI und PXI sind die verbreitetsten. Schau Dich einfach mal bei Meilhaus oder National Instruments um. Solche Module gibts von vielen Herstellern. > Und ohne die > Entwicklung der Komponenten zur Wissenschaft zu machen. Tut mir leid. Für Dein Know-How können wir echt nichts. Bei mir hat die Zusammenstellung der seriellen Verbindungen Kopfkratzen erzeugt. Du hast einfach alles, was Dein PIC32 hergibt, auf den Bus gepackt. Da frage ich mich: muss das so sein? Wir da nicht Funktionalität gedoppelt? Und: Möchte ich ein und den selben CAN-Bus sowohl intern als auch extern verwenden? Ich eher nicht - ich sehe im Moment keinen Anwendungsfall, wo ich eine geräteinterne Kommunikation mit ausschließlich proprietären Modulen nicht auch über SPI abwickeln könnte. Was mir noch fehlt: Wie identifizierst Du die verschiedenen Karten? Ein Anwendungsentwickler würde gerne wissen "Auf Slot 3 steckt Karte W6532 mit der Seriennummer 223678, und die hat die und die Resourcenanforderungen." So macht es PCI, und so hat es vor über 20 Jahren der Amiga schon gemacht. Die I2C Switche lege ich Euch trotzdem ans Herz, sofern Ihr I2C braucht. Viele Bausteine haben nämlich nur begrenzt Adressen, und die Switche erlauben es Euch unter anderem, beispielsweise 16 identische Karten einzusetzen, ohne dass es zu Adresskollisionen kommt. Und dann kann auf jede Karte ein I2C EEPROM mit den Karteninfos gesetzt werden, das fix auf einer bestimmten Adresse liegt. Plus: Die kapazitive Buslast auf dem I2C sinkt, und im Fehlerfall könnt Ihr eine defekte Karte ohne Betriebsunterbrechung einfach isolieren. fchk Addon: Pro Karte mindestens ein Interrupt und eine Resetleitung sollten auch drin sein.
Michael S1. schrieb: > Lob brauche ich hier nicht, Zustimmung oder konstruktive Kritik ist was > ich suchte. > Ist es pampig, unreflektierte, pauschal begründete und nicht > konstruktive "Murks" aussagen abzulehnen? Ich denke nicht. Es ist halt > schade, dass ein technisches Forum mit Gefühlausbrüchen verseucht wird, > statt zur Sache Stellung zu nehmen. Das waren für dich schon Gefühlsausbrüche? Ich fand die Kritik vom Stil her und fachlich (auch wenn ich da kein Profi bin) sinnvoll und nachvollziehbar. > Für Videoprocessing ist der natürlich nicht geeignet, aber für eine > Echtzeitsteuerung mit verteilten Prozessoren, auch wenn das nicht die > primäre Aufgabe ist, würde er schon gehen. Mindestens in der Theorie. In der Praxis kanns, wie überall, anders aussehen :) SPI als Bus über Stecker würde ich persönlich jetzt nicht unbedingt machen. > Und das ganze schüttele ich deshalb aus dem Ärmel, weil ich auf > Standards setze, die wir elektrisch und softwaremässig beherschen. Aber warum müssen es denn gleich mehrere sein? Kann man die ganzen Sachen nicht auch mit CAN only oder SPI only erschlagen? > Wenn Ihr Euch für so schau haltet, dann zeigt mir doch eine Lösung, ohne > ein Fuder Platinen oder Geräte auf dem Tisch zu verteilen. Und ohne die > Entwicklung der Komponenten zur Wissenschaft zu machen. Wenn Du das > kannst, dann stampfe ich meine Idee als Murks ein. Meine Idee (wie gesagt, kein Profi) wäre noch, die Backplane rein passiv zu machen und die gesamte Bus-Technik auf die einzelnen Steckkarten zu verorten. Welche Technik man dafür nimmt, keine Ahnung. Da du ja sowieso Europakarten nimmst wärs doch auch eine Idee, gleich diese VG-Leisten zu nehmen.
@Sven: Erst mal Danke für den sachlichen Beitrag. Ich stimme Dir zu, dass I2C nicht über Systeme verteilt werden sollte. Das tue ich aber auch nicht. Es ist nur über die 20cm Backplane plus 2cm pro Karte verteilt und bei 100 oder 400 KHz wird das störungsfrei laufen. Es ist ein gute Schnittstelle für ganz einfache Kommunikation. Ich werde damit wahrscheinlich nur die Karteneigenschaften einlesen. Ein FPGA auf den Karten möchte ich nicht. Mit den DMA Fähigkeiten der PIC32 ist das bei SPI auch nicht notwendig. Die Slave Karte (ich werde auch PIC32 benutzen) wird ein sauberes API bekommen. Der zentrale PIC32 hat ein festes parametergesteuertes Programm, das Daten vom/zum PC routet. Und auf dem PC gibt es auch ein sauberes API.
Michael S1. schrieb: > Es ist nur über die 20cm Backplane plus 2cm > pro Karte verteilt Und geht dabei kreuz und quer durch das Gerät, damits auch ja alle Störungen, die irgendwo senden, einfängt... Es gibt deutlich robustere Systeme. > Es ist ein gute Schnittstelle für ganz einfache Kommunikation. Vollständiges I2C ist eine ziemlich komplexe Schnittstelle, die meisten Bausteine benutzen halt nur eine Untermenge davon. Die Bausteine werden sich auch gegenseitig beeinflussen und wenn sie kein Clock Stretching machen, bremst dir der langsamste Baustein den ganzen Bus aus. Bedenke auch, dass bei I2C die gesamte Leitungskapazität nur von den Pullups umgeladen wird, wenn ein High-Pegel gebraucht wird... > Ein FPGA auf den Karten möchte ich nicht. Mit den DMA Fähigkeiten der > PIC32 ist das bei SPI auch nicht notwendig. Warum nicht? Es wäre um Welten flexibler und kostet vermutlich nicht mal mehr. Schau vorsichshalber auch mal ins Errata. Microchip ist in sowas führend... > Die Slave Karte (ich werde auch PIC32 benutzen) wird ein sauberes API > bekommen. Der zentrale PIC32 hat ein festes parametergesteuertes > Programm, das Daten vom/zum PC routet. Und auf dem PC gibt es auch ein > sauberes API.
Ich würde auch dringend zu einem Standardsystem raten, wobei Du dir klar machen musst welche Anforderungen Du genau hast (Übertragungsgeschwindigkeit intern / extern, Anzahl der Einschübe die gleichzeitig kommunizieren können, Parameter der Spannung/Strom-Versorgung über die Backplane, sollen die Einschübe untereinander kommunizieren können oder nur über den Crate-Controller?). Frank hat ja schon VXI genannt, was mithin am verbreitesten sein dürfte zu Zeit. Das man sich anpassen muß, würde ich nicht als Nachteil, sondern als Vorteil betrachten: Man kann fertige Crates, Leerkarten (wo die Buslogik schon implementiert ist), etc. einfach so kaufen und muß nicht viel Zeit in Entwicklung von Protokollen, Mechanik und anderem stecken. Darüber hinaus sollte man nicht den Vorteil unterschätzen, das man passende Einschubkarten einfach dazu kaufen kann, wenn benötigt, egal ob man eine Spannungsversorgung benötigt oder einen ADC und diese dann sauber in das Crate passen.
Jetzt wird es sachlich, danke. Hier einige Antworten. VXI und PXI sind sicherlich berechtigte aber recht komplizierte Standards. Da eigene Karten zu entwickeln ist mir zu aufwendig und mit zuviel unbezahltem Lernaufwand verbunden. Ich brauch was simples. Die Karten im S3BUS bekommen über den Busstecker eine Adresse, die für I2C und CAN Adressierung verwendet wird. SPI ist ja ohnehin sternförmig ausgeführt. Die Karten identifizieren sich und Ihre Eigenschaften und Ihre Softwareversion über eine I2C Abfrage. Die Software der Karten kann über den BUS geupdatet werden. Mit SPI über Steckverbinder habe ich keine schlechen Erfahrungen solange die Leitungen kurz sind. Und das sind sie. Das ist auf vielen CPU Modulen auch auf dem Steckverbinder. Ja, Reset, Interrrupt sind da. Zusätzlich ein noch ein Busy des Slaves und ein Request, bzw. Sync des Masters an den Slave. Das mit dem I2C Switch überlege ich mir nochmal. Ich plane allerdings keine IO Bausteine sondern pro Slave einen uC. Drei Schnittstellen für verschiedene Zwecke. I2C als Minimalinterface und zur identifizierung der Karten beim Start. CAN für Echtzeit und Broadcasts und evtl. um SPI Tranfers besser zu Timen. SPI für den hohen Durchsatz. Nach meiner Erfahrung ist SPI alleine sehr unflexibel zwischen zwei Prozessoren, weil es schwierig ist zu wissen wann der Slave genau welche Information senden will und wann er kommunikationsbereit ist. Eine HDMI Verbindung nutzt auch 4 verschiedene Schnittstellen (LVDS Sync Data, I2C, Ethernet und einen 1 Bit Fernsteuerungsbus), weil jede seine Stärken hat. VG Leisten haben deutlich mehr Pole als ich benötige und würden mir die Möglichkeit nehmen die zentralen Komponenten auf dem Backplane unterzubringen. PCIe ist gängig, sehr billig und hat gute Übertragungseigenschaften.
Nachtrag: Der nach aussen gelegte CAN Bus ist ein separater. Der ist nicht mit dem Internen CAN Bus verbunden. Neues Equipment würde ich über Ethernet von einem PC steuern. Es gibt aber einige Anwendungen wo CAN sinnvoller ist. USB ist erst mal nur dran weil es ohnehin da ist. Dito für die nach aussen geführte RS232. Man weiss ja nie ;)
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.