Habe ein Gerät entwickelt, an dem man bis zu 30 andere Geräte mit einem 5 poligem Stecker anschließen kann. 12V, GND und 3 Datenleitungen. Bisher habe ich die Datenleitungen mit CLK, CS und Data belegt und ein SPI ähnliches Protokoll per Software geschrieben. Langsam versuche ich jedoch den ein oder anderen Pin zu sparen. Und dachte mir vieleicht alle parallel als UART zu klemmen und den CS zu behalten. Nur welches Protokoll kommt mit so vielen Clients zurecht? Durch die vielen Geräte bekomme ich ja eine ordentliche Kapazität. Ich muss nur mit einem Client gleichzeitig kommunizieren. Bitraten von 1000 Bit/Sekunde reichen aus. Mehr ist jedoch besser :)
Hallo Peter, Nach deiner beschreibung würde hier Twi/I2C funktionieren. Benötigst nur zwei Leitungen (drei mit der Masse). TWI/I2C ist ein Master Slave Bus. Einfach mal hier im Forum danach suchen. MfG Hohmi Edit: Bis zu 127/128 Busteilnehmer möglich.
Muss ehrlich sagen ihr Überfordert mich ein bisschen. Ich nutze einen MSP430 F149, brauche ich für die jeweiligen Protokolle noch zusätzliche Hardware? Wichtig wäre mir auch das man im laufenden Betrieb die Stecker tauschen kann und ich per Software alle Stecker rumpollen kann um zu sehen welches Gerät wo dran Steckt. Kommunikation besteht immer aus einer Frage vom Master und der Slave gibt dann eine Antwort.
Peter schrieb: > Wichtig wäre mir auch das man im laufenden Betrieb die Stecker tauschen > kann und ich per Software alle Stecker rumpollen kann um zu sehen > welches Gerät wo dran Steckt. Musst du das wirklich wissen? Denn dann verbietet sich ein Bussystem, bei dem im Grunde alle Teilnehmer an einem langen Kabel hängen. An welcher Buchse welches Gerät angesteckt ist, interessiert meistens nicht, weil jeder Slave 'auf seinen Namen hört', egal wo er angesteckt ist.
Karl Heinz Buchegger schrieb: > Musst du das wirklich wissen? > Denn dann verbietet sich ein Bussystem, bei dem im Grunde alle > Teilnehmer an einem langen Kabel hängen. An welcher Buchse welches Gerät > angesteckt ist, interessiert meistens nicht, weil jeder Slave 'auf > seinen Namen hört', egal wo er angesteckt ist. Wissen muss ich das weil es 3 verschiedene Gerätetypen gibt, davon jeweils aber mehrere. Die sind erstmal Baugleich bis auf eine ID. Von jedem Gerätetyp können also mehrere am Gleichen Bus hängen. Geplannt ist der Bau von ein paar Tausend Exemplaren. Eine Statische Bus-Adresse fällt also flach. Gäbe es eine Möglichkeit, das der Master den Slaves im laufenden Betrieb Adressen zuweist? Oder gibt es 24Bit Slave Adressen dann könnte man es natürlich Statisch machen.
Peter schrieb: > Die sind erstmal Baugleich bis auf eine ID. Damit kannst du sie schon mal unterscheiden. Peter schrieb: > Oder gibt es 24Bit Slave Adressen > dann könnte man es natürlich Statisch machen. Wozu brauchst du 24 bit Adressen? Das sind über 16,7 Millionen Stück. Peter schrieb: > Habe ein Gerät entwickelt, an dem man bis zu 30 andere Geräte mit einem > 5 poligem Stecker anschließen kann. Peter schrieb: > Bisher habe ich die Datenleitungen mit CLK, CS und Data belegt und ein > SPI ähnliches Protokoll per Software geschrieben. Bei 30 Geräten fällt SPI wohl definitiv aus den genannten Gründen aus. Zur Leitungslänge hast du nix geschrieben, aber I2C ist eher für kurze Wege geeignet. Und hat nur 7 bzw. 10 Adressbits. Ich denke, CAN sollte hier am geeignetsten sein. Protokoll ist auch schon vorgegeben. Wobei twisted pair schon sein muß. Aber um all sowas kümmert man sich doch zu Beginn eines Projektes.
Peter schrieb: > Habe ein Gerät entwickelt, an dem man bis zu 30 andere Geräte mit einem > 5 poligem Stecker anschließen kann. Jetzt mal zum Verständnis: Hast Du einen Stecker oder hast Du 30 Stecker? Wenn Du einen Stecker hast, hast Du eine Bus-Struktur und brauchst Du irgendeinen einen Hardware-Bus, also z.B. I2C oder CAN. Aber kein ChipSelect (denn dann bräuchtest Du ja 30 ChipSelect-Leitungen). In Deinem Fall (MSP430F149) würde sich I2C anbieten, da kein CAN onboard ist. Jetzt kommt's drauf an, ob die Störfestigkeitsanforderungen I2C zulassen.
Was ich in so einem fall schon erfolgreich gemacht habe: Jeder Slave hängt mit I2C an einem Multi/Master-Bus. Jeder Slave hat eine 16bit Adresse. Nach dem Booten frägt er den Master welche Adresse er bekommt. (Prinzip DHCP). Die 16bit Adresse wird dann auf weiteren Abstraktionsebenen und für den Bootloader zum eindeutigen Flashen verwendet. hat super funktioniert
Ein RS485 Bus kann mit einem Protokoll vrsehen werden das dynamisch adressiert.
Peter schrieb: > Habe ein Gerät entwickelt, an dem man bis zu 30 andere Geräte mit einem > 5 poligem Stecker anschließen kann. 12V, GND und 3 Datenleitungen. > Bisher habe ich die Datenleitungen mit CLK, CS und Data belegt und ein > SPI ähnliches Protokoll per Software geschrieben. Langsam versuche ich > jedoch den ein oder anderen Pin zu sparen. Und dachte mir vieleicht alle > parallel als UART zu klemmen und den CS zu behalten. Wie ist die Topologie? - Stern - Bus Wie groß ist die maximale Leitungslänge des Busses/Geräts zum Sternpunkt? Was für eine Umgebung? - outdoor - industriell - Büro - Wohnung PS: TWI/I2C ist nur für die Kommunikation innerhalb eines Gerätes bzw innerhalb einer Platine gedacht. Ich weiß, das einige hier das auch für größere Entfernungen verwenden, aber dafür ist es nicht gedacht und meines Erachtens auch nicht die optimale Wahl, sondern eine Bastellösung. CAN ist ein recht störsicheres Verfahren, das Deine Anforderungen erfüllen dürfte und im Automotive und industriellen Bereich sehr weit verbreitet ist. Es erfordert jedoch eine Bustopologie. fchk
Frank K. schrieb: > CAN ist ein recht störsicheres Verfahren, das Deine Anforderungen > erfüllen dürfte und im Automotive und industriellen Bereich sehr weit > verbreitet ist. Es erfordert jedoch eine Bustopologie. Nach welchen Kriterien hast Du Deinen Microcontroller ausgesucht? Die MSP430-Serie hat nämlich im Gegensatz zu Microchip oder teilweise AVR keine Derivate mit CAN Controller eingebaut, so dass Du einen externen Controller wie den Microchip MCP2515 verwenden müsstest. Für unwesentlich mehr Geld bekommst Du jedoch einen PIC18F25K80 Controller, der den MCP2515 und einen PIC Prozessor enthält. Für viele Anwendungen rechnet sich somit ein solcher externer CAN-Controller gar nicht. fchk
Pako schrieb: > Peter schrieb: >> Habe ein Gerät entwickelt, an dem man bis zu 30 andere Geräte mit einem >> 5 poligem Stecker anschließen kann. > > Jetzt mal zum Verständnis: > Hast Du einen Stecker oder hast Du 30 Stecker? Ich habe 30 Stecker mit jeweils 5 Polen. > Wie ist die Topologie? > - Stern > - Bus > Die Topologie ist momentan Stern kann sie aber im Stern durchschleifen und hätte einen Bus. > Wie groß ist die maximale Leitungslänge des Busses/Geräts zum > Sternpunkt? 0,5 bis 2m > > Was für eine Umgebung? > - outdoor > - industriell > - Büro > - Wohnung Outdoor + Industriell > CAN ist ein recht störsicheres Verfahren, das Deine Anforderungen > erfüllen dürfte und im Automotive und industriellen Bereich sehr weit > verbreitet ist. Es erfordert jedoch eine Bustopologie. > > fchk Von mir aus sehr gerne. Nur kann ich das oben genannte Problem mit den vielen Adressen beim CAN Bus? Zum wieso MSP430: Nur um Energie zu sparen. Wenn die Wahl nachher auf CAN fällt tausche ich auch den Mikrocontroller. Ich werde vermutlich 15000 Slaves bauen und weis nicht wie viele noch Nachkommen. Brauche daher genug Adressen. Gibts da irgendein Trick beim CAN Bus oder sollt ich da zu RS485 greifen?
Bei 15000 Slaves solltest du dir jemanden suchen der sich richtig gut damit auskennt. Sonst wirst du den Tag bereuen...
1500 Slaves das nenn ich mal sportlich !!! physikalisch an einem Bus/Kabel wird nicht gehen (meisten Buse nur bis 1km spezifiziert oder zu Aufwändig/Teuer) Ich würd mal die Slaves in Stränge unterteilen zB 250 via CAN oder so gekoppeltet (ein Strang). Diese 6 Stränge wieder verbinden. Jetzt kommt die logische Ebene nämlich die Adressierung: zB CAN hat 11 oder 29bit identifier! So schön so gut ein CAN Frame kann 8 Byte Transportieren. RS485 brauchst du einen Treiber und musst dir ein Protokoll überlegen. Nächste Frage wie soll der Datenaustausch ablaufen ? Werden die Werte "on Change" oder mit "snyc" telegrammen auf den bus gelegt ? Achja Schieberegister sind auch manchmal schöne Lösungen ;-) Mfg
Peter schrieb: > Ich werde vermutlich 15000 Slaves bauen und weis nicht wie viele noch > Nachkommen. Brauche daher genug Adressen. Gibts da irgendein Trick beim > CAN Bus oder sollt ich da zu RS485 greifen? Bitte unterscheide mal zwei Dinge: 1. Die verwendete Hardware (max. Länge, Störsicherheit, Topologie usw.) 2. Das verwendete Protokoll CAN spezifiziert nur die ISO/OSI-Schichten 1 und 2, d.h. Du hast mit CAN die volle Freiheit ab Schicht 3. Die Logik zur Verteilung von Slave-Adressen bzw. die Identifizierung von Messages ist Teil der höheren Schichten, d.h. das mußt Du selbst implementieren. RS485/RS422 spezifiziert meines Wissens nur Schicht 1, d.h. da mußt Du noch mehr machen als bei CAN. I2C/TWI dürfte bei Deinen Hardware-Anforderungen eher schwierig werden. Bei Deiner Menge an Teilnehmern wirst Du ggf. Subnetze aufbauen müssen.
Danke für die netten Antworten aber ich habe mich wohl leider falsch Ausgedrückt. Ich habe die 15000 nicht gleichzeitig in einem Bus hängen. Sondern es sollen Master Produziert werden die bis zu 30 Slaves betreiben. Also keine Probleme mit der Hardware. Es gibt erstmal in Absoluten Zahlen 15000 Slaves die auf viele Master verteilt werden. Jedoch sollte jeder von den Slaves zu jedem Master hinzugesteckt werden können und ohne Konfiguration direkt zu funktionieren. Wäre es bei CAN Möglich das der Slave nach dem Anschalten sendet: "Hallo ich bin Slave Nummer xyz." Oder muss ich dazu jede Mögliche Adresse durch pollen? Wenn ich es richtig verstanden habe kann ich ja 29 Bit bei CAN als Identifer nutzen. Reicht locker aber pollen würde ja ewig dauern.
Peter schrieb: > Wäre es bei CAN Möglich das der Slave nach dem Anschalten sendet: "Hallo > ich bin Slave Nummer xyz." CAN ist eigentlich ursprünglich so gedacht, dass der Slave nicht seine Adresse schickt, sondern spezifiziert, welche Daten er gerade so von sich gibt. Die Idee hinter CAN ist es auch nicht, dass da eine dezidierte 2 Wege Kommunikation stattfindet, sondern jeder Teilnehmer legt seine Daten einfach auf den Bus (zb die momentan aktuelle Motordrehzahl) und wenn es auch immer interessiert, der holt sich diese Daten vom Bus. Ob das jetzt das Anzeigeinstrument ist, welches eine Nadel ausschlagen lässt oder der Autoradio, welcher bei höherer Drehzahl lauter wird, ist im Prinzip dem Drehmomentsensor egal. Der teilt einfach unr mit: "aktuelle Drehzahl 2000 U/min". Es ist dieses "aktuelle Drehzahl", welches in der CAN-Id drinnen steckt. Das ist die Idee hinter CAN. Nicht mehr die Teilnehmer werden identifiziert, sondern die Daten selber identifizieren sich. Wird ein neuer Sensor angesteckt, dann gibt es eben am CAN-Bus eine Message mehr, die mitteilt: "linker Blinker eingeschaltet". Wie, wo und vor allem mit welcher Technologie dieser Sensor das macht interessiert keinen. Der Sensor ist auch nicht in dem Sinne adressierbar, dass die Zentrale sagen würde: "Sensor 85, wie ist dein Zustand?". Wenn schon, dann fragt die Zentrale in den Raum: "Weiß irgendwer, ob der linke Blinker an ist oder nicht?". Und wenn der Sensor vorhanden ist, dann schickt der dann eben eine entsprechende Message weg. Oder auch nicht, wenn er ausgefallen ist. Dann weiß die Zentrale anhand des Timeouts: Opps, vom linken BLinker hab ich schon lang nichts mehr gehört, ich denke der ist defekt. Natürlich steht es dir jetzt frei, über diese ID's irgendwas anderes abzuwickeln. CAN selber spezifiziert ja nicht, wofür diese IDs verwendet werden müssen, sondern nur dass es sie gibt.
> Wäre es bei CAN Möglich das der Slave nach dem Anschalten > sendet: "Hallo ich bin Slave Nummer xyz." Sicher ist das möglich. Die Frage ist aber eher: Woher weiß der Slave eigentlich seine Nummer? Und woher weiß die Zentrale dann, was das für ein Slave ist? Was kann der alles? Und was passiert, wenn sich 2 Slaves mit derselben Nummer anzumelden versuchen. Wie du diese Dinge regeln willst: Das ist dein Bier. CAN kümmert sich nicht darum. CAN ist die wie Telekom: Sie stellt dir die Möglichkeit für eine Konferenzschaltung bereit. Wie du das dann schaffst, dass sich alle verstehen und nicht durcheinander reden, das ist dein Bier als Diskussionsleiter.
Beim CAN werden Nachrichten verschickt. Eine Nachricht hat eine ID. Die ID bezeichnet, was für Informationen diese Nachricht enthält. Die ID bezeichnet nicht zwingend, von wem die Nachricht kommt. Man braucht an einer zentralen Stelle eine Datenbank, in der spezifiziert ist, welche Informationen in welchen Nachrichten drinnstecken. Du kannst z.B. einen intelligenten Temperatursensor mit CAN-Interface bauen, der den Meßwert in der Nachricht mit der ID 0x1234567 verschickt. Es ist auch möglich, mehrere solcher Sensoren an einem Bus zu betrieben, ohne daß es zu Kollisionen kommt. Du hast dann aber das Problem, daß Du nicht mehr erkennen kannst, welcher dieser Sensoren eine Nachricht mit ID 0x1234567 geschickt hat. Wenn Du mehrere identische Gerät an einem Bus hängen willst, mußt Du ihnen Basis-IDs zuweisen, d.h. einen bestimmten ID-Bereich, der für dieses Gerät reserviert ist. Was ich dazu schon gesehen habe: 1. DIP-Switch an den Geräten, mit denen die Basis-ID eingestellt werden. 2. Anlern-Mechanismen im Sinne von "Der Master schickt jetzt eine Basis-ID und das Gerät, dessen Anlern-Button gerade gedrückt wird, übernimmt diese Basis-ID und merkt sie sich im EEPROM"
Im Prinzip geht es auf eine Kostenfrage raus, deshalb auch der gute Rat von Bernt. Dies fängt z.B. damit an, was es kostet die ID´s programmieren und verwalten. Unter Umständen kann es günstiger sein, einen 1Wire Temperatursensor oder Batteriemanagement Chip zu nehmen, wie a i2c welcher eine eindeutige ID zur verfügung stellt. Auch möglich, Atmel data flash hat auch eine unique id sollte so etwas für die Applikation nötig sein. Zu Kostenfrage kommen noch ESD Aspekte wegen des hot-plugging. Da gibt es sei es Can wie Rs485 oder I2C / 1-Wire entsprechende Lösungen. Wenn sich diese um 1€ unterscheiden, kann es schon ein KO Kriterium sein. Wenn geringer Verbrauch ansteht, dann würde man eher an RS485 tendieren, ohne pull-up/down und ohne Terminierungswiderständen bei den Slaves, wenn z.B. die Slaves Batteriebetrieben sind, aber auch I2C kann sich da anbieten. I2C wird z.B. auch auf dem Monitorkabel gefahren, oder in Serverräumen als Managementschnittstelle usw. Can steht und fällt mit Objektorientiertheit sowie deren Tools zur Objektbeschreibung. Das kann einen zimlichen Rattenschwanz mit sich ziehen, wie auch Kosten der Can Implementierung. OpenCan z.B. ist LGPL und als solche darf es nur auf embedded systemen wenn diese quelloffen sind, da ein kleineres embedded system kein dynamisches linking hat. Auch RS232, LIN, .... sind möglich, wie auch z.B. ein einfachen Widerstand in einem RC Schwingkreis wenn eingestöpselt um den Typ zu detektieren, wie es z.B. bei Aufzugssteuerung oder Alarmanlagen verwendet wird.
Karl Heinz Buchegger schrieb: > Peter schrieb: > >> Wäre es bei CAN Möglich das der Slave nach dem Anschalten sendet: "Hallo >> ich bin Slave Nummer xyz." > > CAN ist eigentlich ursprünglich so gedacht, dass der Slave nicht seine > Adresse schickt, sondern spezifiziert, welche Daten er gerade so von > sich gibt. > Die Idee hinter CAN ist es auch nicht, dass da eine dezidierte 2 Wege > Kommunikation stattfindet, sondern jeder Teilnehmer legt seine Daten > einfach auf den Bus (zb die momentan aktuelle Motordrehzahl) und wenn es > auch immer interessiert, der holt sich diese Daten vom Bus. Ob das jetzt > das Anzeigeinstrument ist, welches eine Nadel ausschlagen lässt oder der > Autoradio, welcher bei höherer Drehzahl lauter wird, ist im Prinzip dem > Drehmomentsensor egal. Der teilt einfach unr mit: "aktuelle Drehzahl > 2000 U/min". > Es ist dieses "aktuelle Drehzahl", welches in der CAN-Id drinnen steckt. > > Das ist die Idee hinter CAN. Nicht mehr die Teilnehmer werden > identifiziert, sondern die Daten selber identifizieren sich. Wird ein > neuer Sensor angesteckt, dann gibt es eben am CAN-Bus eine Message mehr, > die mitteilt: "linker Blinker eingeschaltet". Wie, wo und vor allem mit > welcher Technologie dieser Sensor das macht interessiert keinen. Der > Sensor ist auch nicht in dem Sinne adressierbar, dass die Zentrale sagen > würde: "Sensor 85, wie ist dein Zustand?". Wenn schon, dann fragt die > Zentrale in den Raum: "Weiß irgendwer, ob der linke Blinker an ist oder > nicht?". Und wenn der Sensor vorhanden ist, dann schickt der dann eben > eine entsprechende Message weg. Oder auch nicht, wenn er ausgefallen > ist. Dann weiß die Zentrale anhand des Timeouts: Opps, vom linken > BLinker hab ich schon lang nichts mehr gehört, ich denke der ist defekt. > > > Natürlich steht es dir jetzt frei, über diese ID's irgendwas anderes > abzuwickeln. CAN selber spezifiziert ja nicht, wofür diese IDs verwendet > werden müssen, sondern nur dass es sie gibt. Sehr verständlich erklärt, Danke! Und pic user hat mein Problem genau erkannt. Habe mich heute den Tag über eingelesen und denke RS485 im Half Duplex ist für mich das Optimale. Vielen Dank an all die super Antworten ihr habt mir super geholfen!
Peter schrieb: > Ich habe die 15000 nicht gleichzeitig in einem Bus hängen. Sondern es > sollen Master Produziert werden die bis zu 30 Slaves betreiben. Also > keine Probleme mit der Hardware. Es gibt erstmal in Absoluten Zahlen > 15000 Slaves die auf viele Master verteilt werden. Jedoch sollte jeder > von den Slaves zu jedem Master hinzugesteckt werden können und ohne > Konfiguration direkt zu funktionieren. Peter schrieb: > Wissen muss ich das weil es 3 verschiedene Gerätetypen gibt, davon > jeweils aber mehrere. Peter schrieb: > Ich muss nur mit einem Client gleichzeitig kommunizieren. Dann ist kein Multimasterbetrieb nötig und alles ist ganz simpel. Aber eigentlich ist dann auch keine eindeutige, absolute Identifizierung erforderlich. Es reicht dann ja aus, wenn ein Slvae in seinem Netzwerk eindeutig ist. Und das kann man, wie beschrieben, schon dynamisch machen. Im Flash des Slaves ist abgelegt, welcher der 3 Arten er angehört. Nach dem Reset schaut er nach, ob er schon eine ID in seinem Netz hat (ebenfalls in seinem Flash gespeichert). Wenn ja, fragt er den Master, ob diese ID auch gültig ist (man darf Slaves doch sicherlich gebraucht in andere Netze stecken?). Wenn er noch keine ID hat, wird ihm vom Master eine zugewiesen und er speichert sie in seinem Flash. Auch die schon genannten Stromspargründe sprechen dann gegen CAN.
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.