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?
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.
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.
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.
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)
Ich habe mir mal den MCP25050 angesehen. Vom Datenblatt her gesehen wirkt das Teil wie ein von Microchip vorprogrammierter PIC-Controller mit CAN-Modul.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.