Hallo, ich suche gerade nach einem (möglichst einfachen) seriellen Bussystem. Ich hab mir ein paar angesehen, aber die Entscheidung ist doch schwerer als erwartet. An den Bus sollen ca. 32 Clients angeschlossen werden. Die Datenübertragung wird hauptsächlich von einem "Master" zu den restlichen Clients passieren. Wobei meistens alle Clients die selben Daten bekommen sollen (also per Broadcast). Unicast sollte aber trotzdem auch möglich sein. Es muss aber auch sichergestellt werden können, dass alle Clients die Daten bekommen haben (sowas wie ein ACK oder ein NACK). Folgende Bussysteme hät ich mal angeschaut: * RS422: Schneller und einfacher Bus. Jedoch befürchte ich, dass die Implementierung eines Protokolls, welches erlaubt Acknowledges an den Sender zurückzuschicken relativ schwierig werden kann, aufgrund von Kollisionen usw. * CAN: Denke besser geeignet als RS422 aufgrund des definierten Protokolls. Sieht mir aber wesentlich komplizierter aus. Mit CAN hab ich bisher noch keine Erfahrungen sammeln können. Außderdem ist die Nettodatenrate auch nicht unbedingt der Hammer. * Ethernet: Ethernet mit einem Switch IC (KSZ8893) pro Client. Damit müsst ich mir zumindest keine Sorgen um Kollisionen am Bus machen. Jedoch steigen auch die Anforderungen an den Mikrocontroller, der Clients. Außerdem muss gesichert werden, dass der Switch IC eines Clients korrekt konfiguriert ist, damit die Clients dahinter die Daten erhalten können. Vorteil von Ethernet wäre noch der Übertrager damit man keine Probleme mit den Massen der Clients bekommt. Welchen Bus würdet ihr für diese Anforderungen verwenden?? Besten Dank, Andreas
Wie lang soll denn der Bus sein und was für Daten sollen denn über den Bus geschickt werden.
Also der Bus wird so zwischen 30 und maximal 100m lang sein. Es werden einerseits größere Datenmengen (1-2 MByte) gesendet, die dann bei den Clients abgespeichert werden und andererseits Kommandos und kurze Textzeilen mit schätzungsweise so um die 64 Bytes.
Andreas Auer schrieb: > Also der Bus wird so zwischen 30 und maximal 100m lang sein. Es werden > einerseits größere Datenmengen (1-2 MByte) gesendet, die dann bei den > Clients abgespeichert werden und andererseits Kommandos und kurze > Textzeilen mit schätzungsweise so um die 64 Bytes. CAN - so kompliziert ist das nun wirklich nicht ...
Zum CAN Bus... Broadcast sollte ja gehen soviel ich beim Überfliegen mitbekommen habe. Bekomm ich auch mit, wenn ein Client einen Fehler beim Empfang hatte??
CAN ist in der Anwendung eigentlich relativ einfach, weil der Controller sehr viel mehr selber macht als bei RS485, wo Du selber auf Kollisionen achten, Prüfsummen implementieren, Buszustände monitoren etc musst. Das ganze ist bei CAN schon in Hardware im Controller implementiert. Für große Datenmengen ist CAN nicht gedacht, eher für kurze Befehle mit deterministischem Antwortverhalten, und genau das hast Du bei Deinen anderen Alternativen nicht. Ethernet ist in der Implementierung deutlich teurer, allein schon wegen des erforderlichen Übertragers und des PHYs. Das heutzutage übliche Twisted Pair Ethernet ist für eine Sterntopologie gedacht. Ausrufezeichen! Ob es zuverlässig klappt, 32 Switches zu kaskadieren, weiß ich nicht - gedacht ist es eigentlich nicht dafür. Ich würde es nicht machen, weil es Probleme bei der Kollisionserkennung geben könnte. Zumindest würde ich die Switches im Store&Forward Modus betreiben, nicht im Cut-Through-Modus. Damit erhöhen sich natürlich auch die Latenzzeiten, und die Zuverlässigkeit geht in den Keller. Was passiert, wenn ein Knoten in der Mitte ausfällt? Insgesamt halte ich das für eine ziemlich dumme Idee. Wenn Du Ethernet nimmst, betreibe es in Sterntopologie, wie es der Rest der Welt macht. fchk
Andreas Auer schrieb: > RS422: Das ist eine Punkt-zu-Punkt Verbindung. 485 ist ein Bus. Aber den meintest du wohl auch. Andreas Auer schrieb: > Datenübertragung wird hauptsächlich von einem "Master" zu den restlichen > > Clients passieren. Da bietet sich RS485 mit einem einfachen Protokoll doch geradezu an. Einer ist Master, die Slaves halten die Klappe, bis sie gefragt werden. Oder sollen die auch untereinander Daten austauschen? Damit beim Broadcast nicht alle gleichzeitig antworten, kann man z.B. unterschiedliche Verzögerungszeiten für das ACK/NACK definieren. mfg.
Andreas Auer schrieb: > Zum CAN Bus... Broadcast sollte ja gehen soviel ich beim Überfliegen > mitbekommen habe. CAN hat nichts anderes als Broadcasts. Jeder Teilnehmer empfängt erst einmal jede Message und entscheidet dann anhand der Message ID, ob er die Message verwirft oder weiterreicht. > Bekomm ich auch mit, wenn ein Client einen Fehler beim > Empfang hatte?? Ja. JEDER Teilnehmer empfängt ALLE Messages und prüft sie auch. Wenn auch nur einer einen Fehler meldet, zieht er das entsprechende Bit im Frame auf den dominanten Pegel (0), sodass der Sender weiß, dass er die Message erneut senden muss. fchk
Danke für die raschen Antworten. Das sind schonmal sehr viele Argumente für den CAN Bus! Vielleicht kannst du mir noch gleich einen Tipp für mögliche CAN Controller ICs geben!? Hast du vielleicht schonmal einen Cortex M3 Controller mit CAN Interface verwendet?? Würde mal gerne einen Cortex M3 verwenden. Hab gesehen, dass es z.B. welche mit CAN Interface von TI gibt.
Es gibt viele Hersteller von Cortex M3 mit CAN MAC: NXP, STM, TI/Luminary, Atmel; dazu noch Microchip (PIC32 oder PIC24/dsPIC) und Renesas. Du musst halt schauen, was für sonstige Anforderungen Du noch hast, wieviel Rechenleistung Du brauchst, wieviel Speicher, was für Peripherie etc. Einen einfachen CAN-Knoten bekommst Du mit einem PIC18 schon für deutlichst unter 5€ hin. Zum MAC kommt immer noch ein PHY dazu. Das ist wie bei Ethernet: der MAC macht den Digitalteil, der PHY die analoge Ankopplung an das Medium. Die CAN PHYs sind immer extern und alles 8-Pinner (DIL oder SO08). Hier musst Du sehen, welche Übertragungsrate Du mit Deiner Kabellänge fahren kannst und dann entweder einen schnellen PHY mit steilen Flanken oder einen langsameren, störsichereren mit flachen Flanken nehmen. Bei einigen PHYs kann man das per Widerstand einstellen. fchk
Atmel hat auch einen Cortex M3 mit CAN MAC?? Hab ich irgendwie nicht gefunden.
Ich wuerd RS422 verwenden. Er ist fullduplex & bidirektional, speziell in einem Master-Slave System. Das Protokoll ist machbar. Wenn der Slave auf jedes Packet des Masters eine Antwort sendet ist man etwa da wo man sein wollte. Broadcasts ergeben natuerlich keine Antwort.
Ein Oschi schrieb: > Ich wuerd RS422 verwenden. Er ist fullduplex & bidirektional, speziell > in einem Master-Slave System. Das Protokoll ist machbar. Wenn der Slave > auf jedes Packet des Masters eine Antwort sendet ist man etwa da wo man > sein wollte. Broadcasts ergeben natuerlich keine Antwort. Wenn ich einzelne Slaves ansprechen möchte, dann wäre RS422 auf jedenfall geeignet. Bei mir gehts hauptsächlich um Broadcasts zu den Clients, da alle Clients möglichst zeitgleich die Daten erhalten sollen. Und dann muss sichergestellt werden können, dass alle Slaves die Daten fehlerfrei erhalten haben. Und da befürchte ich die Schwierigkeit bei RS422. Ich weiß nicht wie oft das wirklich vorkommt, aber wenn es mehrere Slaves betrifft, die fehlerhafte Daten erhalten haben, dann muss ich vom Master die Daten nochmal schicken. Und dann muss ich auch Kollisionen am Bus erkennen können usw. Ich glaub CAN hat da wirklich so seine Vorteile.
Bei einem Bussystem gehen die Packete allenfalls wegen Reflexionen kaputt, oder bei einem Kabelbruch. Daher scheint mir wenn's die letzte Station im Kabel verstanden hat, haben's die anderen auch verstanden. Kollisionen gibt es bei einem Master Slave System nicht, denn es gibt ja keine unplanmaessigen Packete. Denkbar waere ein Bad-Packet Zaehler, der periodisch abgefragt wird. CAN ist ein Bus mit 6 byte Nutzdaten. Wenn das zuwenig ist, wird's muehsam. Denn man sollte einen Bus zustandslos haben.
Andreas Auer schrieb: > Atmel hat auch einen Cortex M3 mit CAN MAC?? Hab ich irgendwie nicht > gefunden. Ich eben gerade auch nicht mehr. Aber Atmel hat ohnehin so seine Lieferprobleme. Ich würde eher mal bei NXP und STM vorbeischauen. NXP baut mit die schnellsten Cortexe - insbesondere was das Flash angeht, aber ab und an auch häßliche Erratas. STM hat eine relativ breite Palette von klein bis groß und ist mir bezüglich Bugs nicht groß in Erinnerung geblieben.
Ein Oschi schrieb: > Bei einem Bussystem gehen die Packete allenfalls wegen Reflexionen > kaputt, oder bei einem Kabelbruch. Daher scheint mir wenn's die letzte > Station im Kabel verstanden hat, haben's die anderen auch verstanden. Oder wenn nebenan ein 35kW Motor anläuft :-) > CAN ist ein Bus mit 6 byte Nutzdaten. 8 Byte! > Wenn das zuwenig ist, wird's > muehsam. Denn man sollte einen Bus zustandslos haben. Die Automobilindustrie kommt damit ganz gut zurecht. fchk
>> CAN ist ein Bus mit 6 byte Nutzdaten. >8 Byte! Wow. Der Hammer ... > >> Wenn das zuwenig ist, wird's >> muehsam. Denn man sollte einen Bus zustandslos haben. > >Die Automobilindustrie kommt damit ganz gut zurecht. Das besagt leider absolut gar nichts. Ist kein Praedikat fuer nichts, ausser fuer ultrakurze Pakete. Fuer Megabyte file transfers waer's weniger geeignet.
Welche Datenrate brauchst Du denn? Es geht durchaus ein RS485-Bus mit broadcast und anschließender Abfrage, ob jeder Empfänger alles richtig empfangen hat. Das dürfte effizienter sein, als kBs - MBs über CAN zerhäckselt zu übertragen. Um nach einer Datenübertragung bei allen Slaves gleichzeitig Aktionen auszulösen, kann man sich einen Trigger-Befehl definieren, der nach der erfolgreichen Datenübertragung kommt.
Ein Oschi schrieb: > CAN ist ein Bus mit 6 byte Nutzdaten. Wenn das zuwenig ist, wird's > muehsam. Denn man sollte einen Bus zustandslos haben. Man kriegt problemlos auch grössere Datenmengen rüber (z.B. einen 4Mbit Protokollspeicher), ohne dass der Bus selbst irgendeinen Zustand braucht (die Nodes haben natürlich einen, aber warum auch nicht) oder es in übles Pingpong ausartet. Beispielsweise indem eine Teiladresse von burstartig gesendeten Daten als Teil einer 29bit Adresse übertragen wird. Der Empfänger akkumuliert die und reklamiert wenn ihm was fehlt.
Frank schrieb: > Das dürfte effizienter sein, als kBs - MBs über CAN zerhäckselt zu > übertragen. Effizient in Bits/Sekunde oder effizientes Programmieren? CAN reduziert die Nutzbitrate bei gleichen Rahmenbedingungen und erhöht die Nodekosten ein bischen, erhöht andererseits aber die Zuverlässigkeit dank fertiger Kontroll- und Fehlerbehandlungsmechanismen. Die Möglichkeit asynchroner Statusmitteilungen statt permanentem Polling kriegt man dann gratis. In vielen Fällen ist die effektive Nutzbitrate von Steuerbussen kein vordringliches Problem.
Frank schrieb: > Es geht durchaus ein RS485-Bus mit broadcast und anschließender Abfrage, > ob jeder Empfänger alles richtig empfangen hat. > Das dürfte effizienter sein, als kBs - MBs über CAN zerhäckselt zu > übertragen. Das Zerhäckseln ist überhaupt kein Problem, macht Dir jeder CAN-Bootloader vor. Dagegen mußt Du bei RS485 alles zu Fuß machen (CRC, Fehlererkennung, ACK, Retry, Adressierung, Kollision usw.). Du hast also bei RS485 erheblich mehr Code zu schreiben und auszuführen. Effizienz ist was anderes. Peter
Für RS485 wurde mal ein Protokoll entwickelt und nennt sich SISA/QD2. Es kann 64 Stationen adressieren. Ob diese Datenmengen möglich sind, müsste man noch erforschen. Einfach mal danach suchen. Fred
Danke für die vielen Antworten. Das hilft mir bei der Auswahl auf jedenfall weiter! Peter Dannegger schrieb: > Frank schrieb: >> Es geht durchaus ein RS485-Bus mit broadcast und anschließender Abfrage, >> ob jeder Empfänger alles richtig empfangen hat. > > Dagegen mußt Du bei RS485 alles zu Fuß machen (CRC, Fehlererkennung, > ACK, Retry, Adressierung, Kollision usw.). Du hast also bei RS485 > erheblich mehr Code zu schreiben und auszuführen. Effizienz ist was > anderes. Genau vor diesen Dingen hab ich bei RS485 etwas "Angst". Jede Zeile Code mehr ist natürlich eine mögliche Fehlerquelle! Von dem her wäre mir auf jedenfall recht, wenn der Bus bzw. ein definiertes Protokoll das von sich aus schon regelt. Und dafür würde sich auf jedenfall CAN eignen. Die Datenrate ist an sich nicht das Hauptkriterium (auch wenn ich hin und wieder 1-2 MByte schicken muss). Wichtig ist es, dass alle Nodes die Daten verlässlich und gleichzeitig bekommen. Und das würde CAN soweit ich das bis jetzt verstanden habe auf jedenfall gewährleisten. Danke euch, Andreas
hi für das was du willst, gibt es das modbus-protokoll das geht mit rs485 + rs422, da master - slave. infos findest du unter modbus.org ich mache das ( seit 30 jahren) mit den protokollen in basic,pascal,php, über rs422-485 und ethernet. cu zipp
Wie wäre es mit einem Ringbus? Der Master Sender an Client1, Client1 an 2, 2 an 3, ... n-1 an n, n an den Master. Hinter den Daten könnte ein Bitfeld sein welches jeder Client um 1 schiebt und sein Ack einträgt.
Wenn du es über RS485 machen willst, würde ich mir das S.N.A.P. Protokoll ansehen, einfach und leicht zu implementieren. Allerdings würde ich dann nicht per Broadcast die Slaves abfragen, sondern der Master sollte jeden Slave geziehlt abfragen und die Anderen halten dabei die Klappe, somit umgehst du schon mal Kollisionen. Christian
zipp schrieb: > einer kaputt und der bus steht... > sehr praktisch und "state of the art".. Doppelten (Token)ring benutzen ;-) Nee, war'n Scherz.
Christian H. schrieb: > Doppelten (Token)ring benutzen ;-) > > > Nee, war'n Scherz. nö wieso? die schmerzlichen erfahrungen habe ich mit einer 16x16 8048-matrix schon 1982 gemacht. hoffe nur, das keiner den schwachsin schon wieder erfinden will! ;-))
Naja, wenn bei CAN oder RSxyz einer kaputt ist und den Bus auf Masse zieht geht auch der ganze Bus nicht mehr. So ein Ring hat durchaus auch Vorteile. Zum Beispiel wird das Signal immer wieder aufgefrischt. Nur weil das alt ist, ist es doch nicht gleich schlecht. Räder gibt es auch schon eine Weile.
Andreas Auer schrieb: > Also der Bus wird so zwischen 30 und maximal 100m lang sein. Bei 1 MBit ist der CAN für bis zu 40m spezifiziert. Bei 100m und 32 Teilnehmern ist das schon sehr an der Grenze. Da wären dann 250kBit/s besser. Gruß Anja
Bei CAN können auch 9 oder 10 Byte mit einer Übertragung genutzt werden, habe ich auch schon programmiert. Die CAN-ID hat 29 Bit also fast 4 Byte, davon habe ich einfach die unteren 16 Bit als Daten "Missbraucht". + die 8 Byte Daten = 10 byte Wenn man einen größeren Datenblock übertragen möchte, so kann man z.B. die ersten 8 Bit der CAN-ID als Daten-Block-Adresse verwenden. Der Sender schickt immer Block 0..255, der Empfänger kann diese Daten anhand der Nummer in das RAM kopieren. Sollte eines Fehlen, so kann der Empfänger "Meckern". Auch wenn die Blöcke nicht in der Reihenfolge ankommen, so wird anhand dieser Adressierung immer der Block an die richtige Stelle eingefügt. CAN ist in jedem Fall leichter zu implementieren als RS422, da die Hardware viel abnimmt. Die Anzahl der Datenbytes kann durch einfache kluge Programmierung beliebig erweitert werden.
Markus Müller schrieb: > CAN ist in jedem Fall leichter zu implementieren als RS422, da die > Hardware viel abnimmt. Auch haben die CAN-MCs in der Regel mehrere Messagepuffer. Die CPU kann also ruhig mehrere Pakete abwarten und muß nicht gleich bei jedem Byte in den Interrupt springen. Wenn ich mir dagegen den Ärger mit RS485 ansehe. Wehe, man schaltet nicht schnell genug die Richtung des Transceiver um, dann gibts Datensalat. Die Interruptanforderungen von RS485 sind also um ein Vielfaches kritischer. Peter
Ok, ich glaub meine Entscheidung ist gefallen. Ich werds wohl auf jedenfall mit CAN probieren. Ich danke euch für die Hilfe und die Diskussion rund ums Thema! mfg Andreas
Ich halte auch Modbus für die einfachste Lösung, und mit einem guten Open Source Angebot bis zur Anwendungsebene (also jenseits der Frage "wie schiebe ich die Bits durchs Kabel") zB http://libmodbus.org für Linux, Mac OS X, FreeBSD, QNX und Win32 http://freemodbus.berlios.de/index.php?idx=32 - eine ganze Reihe von Mikrokontrollern Ich habe einen Modbus-Treiber für einen Frequenzumrichter und LinuxCNC geschrieben (http://git.mah.priv.at/gitweb/vfs11-vfd.git) und musste keineswegs "CRC, Fehlererkennung, ACK, Retry, Adressierung, Kollision usw." schreiben. -Michael
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.