Hallo, ich stöbere nun seit Tagen nach einem passenden Bus für mein Projekt, werde aber nicht wirklich schlauer. Ich hoffe, ihr könnt mir helfen. Ich möchte mehrere Knoten (ATmega oder so) an einem Bus anschließen, ein Master holt sich dann regelmäßig Daten von denen ab. Geschwindigkeit ist zweitrangig, es sind nur ein paar Byte alle paar Minuten. Topologie ist eine Stern- bzw. Baumstruktur, die Kabellänge beträgt maximal 5 Meter. Wichtig ist, dass man im laufenden Betrieb Knoten anschließen oder entfernen kann, ohne dass was kaputt geht. Wenn dadurch ein Datenpaket zerschossen wird ist nicht schlimm, solange ich das erkennen kann. Das Ganze steht im Freien, als Störquellen kommen Mobilfunk (direkt daneben, gehört zum Projekt) und etwaige Hochspannungsleitungen(?) in Frage. Zudem muss es mit sehr wenig Energie auskommen, da der Strom aus einem Akku kommt. Am liebsten wäre mir wenn es mit 3,3 V geht, die µC sollen nämlich auch damit laufen. Als Medium habe ich an Ethernetkabel gedacht, da muss ich nicht selber basteln. An den Master ein paar RJ45-Buchsen und fertig. Außerdem kann ich dann übrige Adern für die Stromversorgung verwenden. Dazu vielleicht noch eine Leitung für einen Interrupt, um die Slaves aufzuwecken. Was ich mir näher angeschaut habe sind I2C, CAN und RS485. Bei CAN ist die Sterntopologie und die Terminierung ein Problem, wenn ich das bisher richtig verstanden habe, bei RS485 sind Stichleitungen anscheinend auch nicht ganz ohne. Am interessantesten finde ich I2C, weil die ATmegas das bereits eingebaut haben, weil es einfach ist und weil es Multimaster gibt. Multimaster finde ich interessant, weil ich mir überlegt habe, dass ein neuer Knoten zunächst als Master dem eigentlichen Master seine Adresse bekannt gibt und dann zum Slave wird. Nur scheint es bei I2C ja eine Art Ideologiekrieg zu geben. Die einen, die darauf schwören, und die anderen, die behaupten dass es nicht geht. Würde es in meinem Fall laufen? Eventuell mit Extendern oder differentiell? Welchen Bus würdet ihr empfehlen? Vielen Dank, Christian
Christian schrieb: > Bei CAN ist die Sterntopologie und die Terminierung ein Problem Nur bei hohen Geschwindigkeiten. Ansonsten kann man CAN sogar einadrig (open-Drain) betreiben oder auf die VCC modulieren. Der große Vorteil bei CAN ist, es erfordert mit Abstand den geringsten Softwareaufwand, da sich um alles die Hardware kümmert (Arbitrierung, CRC, Retry, ...). Christian schrieb: > Nur scheint es bei I2C ja eine Art Ideologiekrieg zu geben. Die einen, > die darauf schwören, und die anderen, die behaupten dass es nicht geht. Es ist sehr störempfindlich und manche I2C-Controller haben ernsthafte Bugs. Im Prinzip geht es, aber der Softwareaufwand, um Störungen abzufangen, ist enorm. Als mindestes kommt man um einen Timeouthandler nicht herum, d.h. alle Teilnehmer müssen ihr I2C disablen, wenn es eine bestimmte Zeit hängt. Sind außerdem I2C-ICs ohne Controller dran, muß der Master noch ein spezielles I2C-Reset durchführen (bis zu 9 mal SCL takten und versuchen, Stop zu senden). Da das aber kein Controller unterstützt, muß es zu Fuß (Bit-Banging + Delayloops) gemacht werden. Peter
Ich würde dir angesichts der Störfaktoren auch dringendst zu einem CAN-Bus raten. Der CAN Controller MCP2515 http://www.mikrocontroller.net/articles/CAN#CAN_Controller ist weltweit bekannt und extrem verbreitet. Es gibt abertausende Projekte mit diesem. Als CAN Treiber nimmt man dann meist den MCP2551. Sind beide sehr gut erhältlich (Reichelt) und kosten je 1€ und ein paar Cent. Ich muss sagen, dass ich kein großer Freund von I2C bin ... Ansichtssache.
I²C geht im Prinzip und böte sich an, wenn da nicht der hohe Innenwiderstand der Leitungen wäre und damit die Störempfindlichkeit. CAN hat durchaus nicht den geringsten Programmieraufwand, denn die Initialisierung ist sehr umfangreich. Dafür ist die Übertragung, wenn der Bus erstmal funktioniert, störfest und schnell genug. Folglich ist er die erste Wahl. Eine weitere Möglichkeit ist SPI. Da hierbei die Leitungen sehr niederimpedant ausfallen, ist er allemal störfest. Er braucht drei Leitungen plus Masse (was hier aber kein Problem darstellen wird). Das Kommunikationsprotokoll muß man sich hier selbst schreiben, womit man aber freie Hand hat. Bei allen drei Bussystemen kann man Geräte dazustecken oder abziehen. Eine eventuell auftretende Fehlersituation muß von der Firmware abgefangen werden. Gruß - Wolfgang
I2C über mehr als 4 Meter würde ich wegen der Störanfälligkeit auf keinen Fall empfehlen. Gruß, Yaro
Wie würde denn Sterntopologie bei CAN aussehen? Laut den Wiki-Seiten hier auf µC.net gehen Stichleitungen nur ein paar cm, ansonsten muss man zu jedem Knoten hin und wieder zurück. Das geht dann wieder mit dem anschließen neuer Knoten nicht. Weiteres Problem bei CAN ist, dass ich zusätzlich zu meinem µC immer noch einen Controller UND einen Treiber brauche, die meistens auch noch 5 V brauchen. Bei manchen Knoten krieg ich da schön langsam ein Platzproblem. Wie schaut es denn generell mit Stromverbrauch aus bei I2C? Bezüglich I2C: Von welchen Geschwindigkeiten reden wir hier eigentlich, bei denen es kritisch ist? Besteht das Problem auch bei 10 KHz? Mir würde das locker reichen. @Peter: Kannst du das Problem mit dem Aufhängen genauer erläutern? Wann kann das auftreten? Was meinst du mit disabeln? Einfach eine Zeit lang ausschalten und dann neu starten, wenn kein Müll mehr kommt? Sämtliche Knoten sind AVR ATmega bzw. ATtiny, ich verwende keine Sensoren mit eingebautem I2C. Ich kann also entsprechende Routinen einbauen. Varianten zur Erhöhung der Störsicherheit von I2C wären: - Master + 1 Repeater pro Port - Master + 1 Expander pro Port + 1 Expander pro Knoten - Master + Diff-Treiber (pro Port?) + 1 Diff-Treiber pro Knoten Die letzte Variante wäre quasi I2C over RS485, bzw. I2C over CAN (-Transceiver).
Christian schrieb: > Welchen Bus würdet ihr empfehlen? I2C wurde für Konsumer-Geräte (Fernseher) entwickelt um die Bausteinkommunikation innerhalb des Gerätes abzuwickeln. Also auf der Leiterplatte und maximal ein über Flachbandkabel abgesetzes Bedienteil. SPI ist ausschließlich für periphere Chips innerhalb der Leiterplatte entwickelt worden. Sowohl SPI als auch I2C sind nicht für sicherheitskritische Datenübertragung in verseuchter Umgebung entwickelt worden. Wenn auch bei I2C treiber für bis zu 10 m Kabellänge existieren. CAN wurde für sicherheitskritische Kommunikation im KFZ entwickelt (40m Kabellänge bei 1 MBit). RS485 wird im Industriellen Umfeld eingesetzt. (200 m Kabellänge oder mehr). In EMV-verseuchter Umgebung würde ich entweder CAN oder RS485 einsetzen. RS485 benötigt als Aufwand nur die Treiber wenn der UART bereits auf dem Chip ist. Gruß Anja
Hallo zusammen. @Peter Dannegger: ich hab da eine Frage: Hast du Informationen zur Aufmodulation von CAN auf die VCC? Wäre echt super. Danke Michael
Christian schrieb: > Ich möchte mehrere Knoten (ATmega oder so) an einem Bus anschließen, ein > Master holt sich dann regelmäßig Daten von denen ab. Geschwindigkeit ist > zweitrangig, es sind nur ein paar Byte alle paar Minuten. > Topologie ist eine Stern- bzw. Baumstruktur, die Kabellänge beträgt > maximal 5 Meter. > Wichtig ist, dass man im laufenden Betrieb Knoten anschließen oder > entfernen kann, ohne dass was kaputt geht. Wenn dadurch ein Datenpaket > zerschossen wird ist nicht schlimm, solange ich das erkennen kann. [...] > Als Medium habe ich an Ethernetkabel gedacht, da muss ich nicht selber > basteln. An den Master ein paar RJ45-Buchsen und fertig. Außerdem kann > ich dann übrige Adern für die Stromversorgung verwenden. Dazu vielleicht > noch eine Leitung für einen Interrupt, um die Slaves aufzuwecken. Dann nimm doch direkt Ethernet. Klingt zwar blöd, ist es aber nicht. Du willst unbedingt eine Sterntopologie. Die bekommst Du bei CAN und RS485 nur beschränkt wegen der notwendigen Terminierung. Ich habe einen Ethernet-Knoten auf Basis eines PIC18F67J60 gebaut. Das ist EIN Chip, in dem alles drin ist. Du musst nur noch die Ethernet-Buchse mit integriertem Übertrager anschließen. Ein paar passive Bauteile gibts da auch noch. Den IP-Stack gibts von Microchip fix&fertig. Mußt Du einfach nur benutzen. Der PIC braucht 3.3V. Problem ist der relativ hohe Stromverbrauch von 180mA, der fast ausschließlich von Ethernet-PHY verursacht wird. Das geht halt nicht anders. Dann brauchst Du nur noch einen ganz normalen Ethernet-Switch Power-Over-Ethernet gemäß 802.3af ist auch erfunden. Ansonsten: keinen Bus, sondern eine RS232-punkt-Punkt Verbindung zu einem RS232 Verteiler. Dieser übernimmt die Funktion eines Ethernet-Hubs, d.h. er hat n Ports, wobei die RX-Leitungen auf ein großes Und-Gatter geführt werden, dessen Ausgang die TX-Leitungen des Verteilers steuert. Wenn ein Knoten sendet, empfangen dies alle Knoten - auch der Sender, der so Kollisionen und Störungen anhand seines Echos erkennen kann. Wahlweise kann der Verteiler auch die Stromversorgung übernehmen. Dann komme aber besser nicht auf die Idee, 3.3V darüber zu verteilen. Den entstehenden Spannungsabfall darfst Du sonst selber zusammenkehren. Üblicherweise werden dort 48V übertragen die dann per DC-DC-Wandler auf die lokal benötigten Spannungen heruntergesetzt werden. Unter 12V würde ich da eigentlich nicht gehen wollen, aber das kannst Du ja selber ausprobieren. Bei 5m mag das wohl noch gehen. fchk
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.