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
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?
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.
