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 MCP2515http://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
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
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
