Forum: Mikrocontroller und Digitale Elektronik I2C vs CAN vs Ethernet


von Be B. (bebo)


Lesenswert?

Hallo,

I2C, CAN und LAN sind ja alles Bussysteme (im weitesten Sinne).

I2C benötigt keine weitere Hardware, wenn die MCU ihn unterstützt. I2C 
geht von einigen kBits bis >1MBit und kann glaube ich bis ca. 1m lang 
sein.

CAN ist in einigen Controllern zwar auch schon integriert, kann 
ebenfalls bis ein 1MBit, benötigt aber in jedem Fall noch einen 
Transcieiver, der den Bus treibt. Strecken von 40m bis 500m werden 
angegeben.

Ethernet ist ähnlich wie CAN nicht ohne externen Schaltungsaufwand 
möglich. Zumindest ist die Anbindung an das Netzwerk teuer (Übertrager 
in der Netzwerkbuchse) und auch das Netzwerk selber (z.B. Router) kosten 
so einiges. Dafür ist die Distanz quasi unbegrenzt (Internet). Die 
Übertragungsraten schwanken stark.

So weit so gut.

Einen I2C Bus habe ich schon einmal programmiert. Der Aufwand hielt sich 
in grenzen. Hat glaube ich alles in allem bei mir so 2 Wochen gebraucht.

Nun frage ich mich, wie aufwändig CAN und Ethernet sind? Der 
Ethernetstack von Microchip sieht schon recht komplex aus. Wie sieht es 
da mit CAN aus. Ist das eher wie I2C oder doch eher wie LAN?

Gibt's bei CAN eigentlich Peripheriechips ähnlich wie beim I2C Bus, so 
daß man AD-Wander oder I/Os direkt an den CAN Bus anschließen kann?

Gibt es noch andere, einfachere, Lösungen als LAN und CAN, wenn man ein 
paar MCUs mehr oder weniger in sagen wir mal 50m Umkreis miteinander 
Kommunizieren lassen will? Die Übertragungsrate von einigen kBits/s 
sollte reichen.

Für welche Anwendungen verwendet Ihr CAN? Und macht LAN auch zwischen 
MCUs Sinn, oder doch eher nur, um vom PC aus auf den Controller 
zuzugreifen?

von Gast (Gast)


Lesenswert?

Can Bausteine gibts direkt glaub ich nicht, eher Baugruppen oder Module 
(z.B. in der Automatisierung) die eine CAN-Schnittstelle haben und dann 
CAN Packete senden (z.B. Temperaturen die mit Sensoren ermittelt wurden 
oder sowas).

LAN mit µC ist machbar einfach ist es aber nicht(gibt ja viele Beispiele 
im Netz) hingegen CAN lässt sich denk ich ne gute Ecke einfacher 
implementieren, vorallem wenns um die ersten Schritte geht.

von Gast (Gast)


Lesenswert?

Zumindest I/Os gibts für CAN soweit ich weiß als Bausteine

von (prx) A. K. (prx)


Lesenswert?

Be Bo schrieb:

> Wie sieht es
> da mit CAN aus. Ist das eher wie I2C oder doch eher wie LAN?

Wenn man nicht grad CANopen anstrebt und der CAN Controller vom BasicCAN 
Typ ist, dann ist das eher einfacher zu implementieren als RS485 und im 
Aufwand vergleichbar mit I2C. Steckt halt mehr zu lesende Doku drin.

> Gibt's bei CAN eigentlich Peripheriechips ähnlich wie beim I2C Bus, so
> daß man AD-Wander oder I/Os direkt an den CAN Bus anschließen kann?

Ja, Microchip MCP25050. Pin/AD drin. Haken: Muss programmiert werden (ID 
und mehr), was ein eigenes Programmierinterface erfordert.

> Gibt es noch andere, einfachere, Lösungen als LAN und CAN, wenn man ein
> paar MCUs mehr oder weniger in sagen wir mal 50m Umkreis miteinander
> Kommunizieren lassen will?

Wenn es nur einen Master gibt: RS485. Evtl. LIN-Bus, aber da habe ich 
die Distanz grad nicht parat.

> Für welche Anwendungen verwendet Ihr CAN?

Hausbus für Datenerfassung, Anzeige, Protokollierung.

> Und macht LAN auch zwischen MCUs Sinn

Für grosse Datenmengen in begrenzter Zeit allemal.

von Ephraim H. (ephi)


Lesenswert?

du hast die beiden pull-ups für I2C vergessen ;-)

von Be B. (bebo)


Lesenswert?

Es ging mir eigentlich darum, mal den Aufwand abzuschätzen ohne mich 
komplett einarbeiten zu müssen.

Sind die Transceiver eigenlich sehr leistungshungrig? Wundert mich, daß 
die in den CAN-MCUs nicht gleich mit drin sind. Sonst wird doch alles 
integriert.

von Joachim P. (yes_i_can)


Angehängte Dateien:

Lesenswert?

Hallo Be Bo,

CAN-Transceiver sind deshalb eigene Bausteine, weil sie (oft) in 
KFZ-Bus-Systemen eingesetzt werden. Dort kann es dann die 
unterschiedlichsten Störungen geben (ESD, Kurzschlüsse gegen Batterie, 
...). Gegen diese Pegel können die "normalen" Prozessoren mit ihren 
feinen Strukturen nicht geschützt werden. Deshalb die CAN-Treiber. Der 
Bus selbst ist differentiell und MUSS an zwei Enden mit jeweils 120 Ohm 
abgeschlossen werden. Geeignete Treiber gibt es im 8-poligen (z.B. 
82C250) oder auch 16-poligem (z.B. TJA1041)Gehäuse.
CAN ist ein sehr robustes, fehlertolerantes System und generell 
multimaster-fähig. Das heisst, (nahezu) beliebig viele Sender können 
ihre Botschaften auf den Bus legen und die Nachricht mit der höchsten 
Priorität (= kleinste CAN-ID) "gewinnt". Die Nachrichten können dann von 
allen Teilnehmern gleichzeitig gelesen werden.
Die Kabellänge ist abhängig von der Übertragungsrate. Das Kabel selbst 
sollte "twisted pair" (z.B. Netzwerkkabel CAT5) sein. Musst mal im Netz 
etwas recherchieren.

Viel Spass bei der Umsetzung,

yes, i CAN.

(Joachim)

von Be B. (bebo)


Lesenswert?

Ich habe mir mal den MCP25050 angesehen. Vom Datenblatt her gesehen 
wirkt das Teil wie ein von Microchip vorprogrammierter PIC-Controller 
mit CAN-Modul.

von tuppes (Gast)


Lesenswert?

CAN:
====

Bei CAN muss man zuerst mal einiges lesen, um zu wissen, wie es 
funktioniert. Wenn man das geschnallt hat, ist die Programmierung sehr 
einfach.

Einmal einen Satz Register einstellen, und dann ist zum Versenden bzw. 
Abholen eines ganzen Telegramms nur eine einzige Software-Aktion nötig 
(und nicht, wie bei I2C oder UART, nach jedem einzelnen Byte ein 
Eingriff).

Der Hardware-Aufwand ist gering: Ein CAN-Transceiver-IC von der Stange, 
evtl. Optokoppler, falls die Knoten auf unterschiedlichen Potentialen 
liegen.

Wenn du mit der CAN-Paketgröße (8 Bytes Nutzdaten) gut leben kannst, ist 
das insgesamt die einfachste Realisierung.

LAN:
====

Der Software-Aufwand hängt stark davon ab, was das Ganze werden soll.

Wird das eine Insellösung (paar Controller unter sich, ohne Verbindung 
zur Außenwelt, auch kein PC als zentrale Steuereinheit), dann reicht es, 
die Controller sternförmig über einen Switch zu verkabeln und 
Ethernet-Frames durch die Gegend zu schicken. Das ist vom 
Programmieraufwand her mit CAN vergleichbar.

Der Vorteil gegenüber CAN wäre, dass größere Pakete verschickt werden 
können (bis 1.5 KB) - wenn deine Applikation das braucht.

Nachteil: Ethernet erfordert einen hohen Hardware-Aufwand (außer bei 
Prozessoren, die MAC und PHY on-chip haben).

Sollen sich die Knoten mit einem PC, einem Router oder ähnlichem 
unterhalten, dann kommt TCP/IP ins Spiel, und du bist in einer ganz 
anderen Liga.

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
Noch kein Account? Hier anmelden.