-         

Ergebnis 1 bis 10 von 10

Thema: Schnittstelle I2C oder besser was anderes?

  1. #1

    Schnittstelle I2C oder besser was anderes?

    Anzeige

    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

  2. #2
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    15.08.2004
    Ort
    Graz
    Beiträge
    342
    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: http://www.roboternetz.de/phpBB2/viewtopic.php?t=54923

    mfg

  3. #3
    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.

  4. #4
    Neuer Benutzer Öfters hier
    Registriert seit
    24.01.2011
    Beiträge
    7

    I2C-Bus stabilisieren

    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.

  5. #5
    Neuer Benutzer Öfters hier
    Registriert seit
    24.01.2011
    Beiträge
    7
    Zur I2C Übertragung über CAN-Physik hab ich gerade gefunden:

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

  6. #6
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    19.05.2005
    Ort
    Berlin
    Beiträge
    316
    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

  7. #7
    Erfahrener Benutzer Roboter Genie Avatar von Hessibaby
    Registriert seit
    20.11.2003
    Ort
    Gelsenkirchen
    Alter
    65
    Beiträge
    1.597
    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

    Planung ersetzt Zufall durch Irrtum

    Gruß aus dem Ruhrgebiet Hartmut

  8. #8
    Neuer Benutzer Öfters hier
    Registriert seit
    24.01.2011
    Beiträge
    7
    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.
    Der schlimmste Glaube ist der Glaube zu wissen

  9. #9
    Erfahrener Benutzer Begeisterter Techniker Avatar von Osser
    Registriert seit
    31.10.2006
    Ort
    Köln
    Alter
    47
    Beiträge
    387
    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.

  10. #10
    Erfahrener Benutzer Robotik Einstein Avatar von Vitis
    Registriert seit
    06.01.2005
    Ort
    Südpfalz
    Alter
    43
    Beiträge
    2.240
    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.
    Vor den Erfolg haben die Götter den Schweiß gesetzt

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •