mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Welchen Bus?


Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Lehrmann Michael (ubimbo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Yaro (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
I2C über mehr als 4 Meter würde ich wegen der Störanfälligkeit auf 
keinen Fall empfehlen.

Gruß, Yaro

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Anja (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.