Schnittstelle I2C oder besser was anderes?

Hallo,

ich hoffe, der Beitrag passt hier hin.

Ich suche nach einer Möglichkeit möglichst einfach Mikrocontroller untereinander kommunizieren zu lassen.

Ich habe folgendes Szenario:
Ich habe in meinem Auto einen Computer eingebaut, der nach Möglichkeit einige Steuerungen übernehmen soll.
Dazu möchte ich mir einzelne Module anfertigen, die unabhängig von einander
Aufgabe ausführen.
Ein Modul, was mittels Schrittmotoren meine Lüftung steuert.
Zwei Module, die über einen Temperatursensor die aktuelle Temperatur zum Computer und zum Modul für die Lüftersterung schicken.
Und noch ein paar andere Module.
Die Module besitzen natürlich alle einen eigenen Atmel.
Zu erst hatte ich die Idee, 2 Leitungen durch mein Auto zu ziehen und alle Module parallel per I2C zu verbinden.
Diese Daten werden dann von den Mikrocontroller behandelt und über den Master zusätzlich an meinen PC geschickt, damit ich diese Visualisieren kann.
Das Problem was ich habe ist, es müssen alle senden und empfangen können. Da ich auch die Module über den PC verwalten möchte. Sprich ein und ausschalten, sowie Debuggen.

Kann man das so einfach umsetzen?
Kennt ihr eine bessere Methode?

Grüße
Maurice

Hallo,

Möglich ist das natürlich, aber (vor allem in so einer störreichen Umgebung) nicht trivial. I²C ist da eher eine schlechtere Wahl, in KFZ hat sich der CAN-Bus durchgesetzt.

Vielleicht hilfts ja trotzdem, genau so eine Kommunikation (einfach, TWI / UART, Übertragungssicherung, ...) habe ich vor kurzem hier vorgestellt: https://www.roboternetz.de/phpBB2/viewtopic.php?t=54923

mfg

CAN-BUS möchte ich eher nicht verwenden.
Der scheint mir auf den ersten blick ziemlich aufwendig.

Aber dein Netzwerk scheint recht gut zu sein.
Ich werde mir das mal ansehen.

Es gibt I2c-Bus Extender ( P82B715 ) die zusammen mit niedrigen Pull-Up Widerständen (zB 330 Ohm) die Störanfälligkeit drastisch reduzieren und auch längere Leitungen ermöglichen. Hatte ich früher problemlos als Feldbus bis zu 50m verwendet.

Im Kfz solltest du trotzdem darauf achten, wo und wie du die Leitungen verlegst.

Für noch größere Störsicherheit oder noch längere Leitungen kann man I2C auch mit CAN-Treiber-ICs physikalisch auf die CAN-Übertragung übersetzen, ist jedoch deutlich aufwendiger. Hab ich auch schon mal gemacht, ist aber schon länger her.

Zur I2C Übertragung über CAN-Physik hab ich gerade gefunden:

http://cctools.hs-control.de/ext_index.php?artikel=1823

Für CAN bietet sich der MCP2515 an. Das ist ein CAN-BUS Controller. Der Chip wird über SPI angesprochen und kümmert sich um fast alles (vor allem um die "hässlichen" Sachen). Damit kann man ganz einfach und bequem Nachrichten verschicken und empfangen.
Ich würde auf jeden Fall ein Bussystem benutzen, das differenzielle Leitungen verwendet (Störanfälligkeit).

MfG

Einfacher ist es die in der Industrie verwendete RS422 zu verwenden. Diese ist aber nur das Vehikel, welches Protokoll Du benutzt ist Deine Sache. Für kleine Sensor-Aktor-Netze, meiner Meinung nach, erste Wahl.

http://de.wikipedia.org/wiki/EIA-422

Der CAN-Bus ist auch ein differenzieller Bus. Im Gegensatz zu RS 422 und RS485 arbeitet er aber wie auch I2C nach dem Open-Collektor (bzw Open-Drain) Prinzip. So wie bei I2C jeder Teilnehmer das Signal auf GND ziehen kann bei CAN jeder (zugleich) das CAN_L-Signal auf Low und das CAN_H-Signal auf High ziehen. Statt der Pull-Up Widerstände wirken die
Abschlußwiderstände zwischen beiden Leitungen. Siehe Datenblatt des PCA82C250 :

http://www.semiconductors.philips.co...CA82C250_5.pdf

Aufgrund dieser Verwandschaft ist der I2C-Bus leichter auf CAN-Physik zu übersetzen als auf RS 422 oder RS 485. Wie steht hier drin:

http://www.semiconductors.philips.co...es/AN460_1.pdf

Das schöne ist, dass das I2C-Protokoll bleiben kann über das gesamte System. Mit dem MCP2515 Controller geht zwar eine CAN-Verbindung
von einem MC zum andern, aber auf andere I2C Bausteine kann man damit nicht zugreifen.

Hi R4Y,


ich benutze z.B. das SPI Protokoll zur Anbindung von entfernten Sensoren/mC das bei den meisten ATMegas integriert ist.
Um den Übertragungskanal robuster zu gestalten benutze ich die LTC1485 IC's die für hohe Frequenzen geeignet sind.

Die selben IC's benutze ich des Weiteren, um Absolut-Drehgeber von Heidenhain auszulesen, was fehlerfrei funktioniert.

Du brauchst für SPI jedoch bedingt einen Mastercontroller der die Kommunikation anstösst. Aber mit Anbindung des SPI-SS Kanals wäre selbst das frei wählbar.

siehe mein Fräsmaschinenprojekt

Gruss,

O.

Sorry, aber SPI ist kein Protokoll, sondern die Schnittstelle in Hardware.
Ist schnell, aber nicht für lange Datenleitungen und störbehaftete Umgebung gedacht. Wenn SPI im Auto als Bus, dann die Transceiver für 485 davorschalten und mit der doppelten Anzahl Datenleitungen differentiell übertragen. Brauchts aber mächtig viele Drähte und für die Geschichte
deutlich overkill ... eher 422 oder 485 meine Empfehlung.