Hallo. Ich habe bereits erfolgreich mit RS232, I2C und SPI gearbeitet. Als nächstes würde ich mich gerne mit CAN beschäftigen. Als Hardware habe ich an 2 PICs mit CAN Modul gedacht, die sich einfach nur Daten schicken sollen. Programmieren würde ich diese entweder mit MikroC (sofern die Demo reicht) oder ansonsten mit MPLABX und XC8. CAN-Transceiver habe ich auch, sodass es eigentlich losgehen kann, aber ich weiß nicht wie genau. Es scheint einiges komplizierter als SPI zu sein, auch wegen der Kollisionenerkennung usw. Also wie funktioniert es genau und was muss ich beachten? Was ist CANopen und wozu brauche ich das? Ich stelle es mir so vor, dass CANopen dafür sorgt, dass ein gewisser RAM/ROM Bereich bei allen Teilnehmern gleich sind. Quasi wie globale Variablen. Wenn ich mit der Materie einigermaßen sicher umgehen kann, würde ich es in Richtung Haus-Automation verwenden wollen. Gibt es da speziell noch etwas zu beachten? Hilft mir da CANopen weiter oder gibt es etwas passenderes? Reicht es da nicht einfach Nachrichten zu verschicken und die angesprochenen Partner reagieren dann? Ein Lichtschalter braucht ja z.B. nicht die Temperaturen aller Räume zu wissen. Ich würde mich zwar freuen, wenn jemand ein Teil oder sogar alle Fragen beantwortet, meine eigentliche Frage ist aber, ob es eine gute Hilfequelle gibt oder vielleicht sogar eine Art Tutorial (Video oder Text). Irgendwas, womit ich mir die Antworten auf meine Fragen selber erarbeiten kann. Also erstmal Grundlagen und Allgemeines über CAN und dann idealer Weise noch CAN in Richtung Haus-Automation. Vielen Dank
ich schrieb: > Was ist CANopen und wozu brauche ich das? Also, CAN alleine kannst Du am ehesten mit einer nackten Ethernet-Netzwerkkarte vergleichen: CAN kann nur Datenpakete verschicken und Empfangen. Dabei ist keinerlei Protokoll definiert. CANopen ist nun alles andere. Wieder verglichen mit Internet: CANopen ist wie ARP, IP, DNS, TCP und HTTP, SMTP etc. mit Remote-Konfiguration. D.h. CANopen geht von ganz unten, wie die einzelnen CAN-Nachrichten aufgebaut sind, bis ganz oben, mit Device-Profiles die bestimmte Geräte beschreiben, einschließlich den Zwischenschichten. ich schrieb: > CANopen dafür sorgt, dass ein gewisser RAM/ROM Bereich bei allen > Teilnehmern gleich sind. Quasi wie globale Variablen. Naja, so könnte man es in etwa sehen, sobald alle Knoten konfiguriert wurden.
We CAN schrieb: > ich schrieb: >> Was ist CANopen und wozu brauche ich das? > > Also, CAN alleine kannst Du am ehesten mit einer nackten > Ethernet-Netzwerkkarte vergleichen: CAN kann nur Datenpakete verschicken > und Empfangen. Dabei ist keinerlei Protokoll definiert. Ist ja i.d.R. bei SPI oder I2C auch der Fall. Reicht ja für banale Sachen aus. Kennt denn jemand eine Quelle oder Tutorial um sich CAN näher zu führen? Finde da irgendwie nichts gescheites. Meist nur so ganz oberflächlich.
CAN ist so einfach, da braucht's kein Tutorial. Man lese sich auf WIkipedia durch wie es funktioniert, lese sich die Dokumentation des CAN Controllers durch, nehme einen Beispiel Code für diesen und passe ihn an. Warum du dir das Leben mit einem externen CAN Controller, für den man sich noch mit SPI rumschlagen muss, schwer machst, ist Nicht ganz klar. Nimm doch einfach einen Mikrocontroller mit integriertem CAN Controller, dann hat der Hersteller auch Beispielcodes die du direkt einbauen kannst.Bestimmt gibt's auch PIC's die das haben, ansonsten halt ARM oder AVR. Und CANopen ist sehr komplex, das "brauchst" du nur wenn du dein Produkt mit "CANopen kompatibel" bewerben oder über CANopen Konfigurationstools konfigurieren können willst. Zum Ansprechen fremder CANopen-Geräte musst du CANopen nicht implementieren. Wenn du gar keine fremden CANopen-Geräte einbauen willst (und daher auch kein CANopen Konfigurationstool verwenden) ist CANopen vollkommen überflüssig.
Ich glaube, ich habe deinen Text falsch gelesen. Wenn du das so meintest dass du eine PIC mit integriertem CAN-Controller nimmst, ignoriere meinen Text dazu, sorry.
ich schrieb: > Es scheint einiges komplizierter als SPI zu > sein, auch wegen der Kollisionenerkennung usw. Das Handling auf dem Bus regelt Dein CAN-Controller weitgehend für Dich. Message-Box konfigurieren, mit Daten füllen, Senden auslösen. Die Message-Box wird dann automatisch versuchen die Botschaft auf dem Bus loszuwerden. Hat man zum Beispiel nur einen Teilnehmer, die Botschaft geht also nicht durch weil das Acknowledge fehlt, dann fängt die Message-Box wieder und wieder an das zu senden und wird nie fertig. Sendet gleichzeitg ein anderer Teilnehmer mit einer niedrigeren ID, also höherer Prio dann wird die Übertragung automatisch gestopt und nochmal versucht die Botschaft auf den Bus zu legen wenn dieser frei ist. Gibt halt so ein paar Fehler die man abfangen kann, wie zum Beispiel das eine Botschaft die reinkommt nicht die richtige Länge hat.
Genau, der PIC hat ein CAN-Modul, dessen Pins mit CAN_RX & CAN_TX beschriftet sind. Diese kommen dann an den Transceiver, der daraus dann CANH &CANL "macht". SPI ist ja eigentlich nur ein Buffer füllen und dann mit dme Clock bit für bit zu schreiben und gleichzeitig zu lesen. Recht Simpel. I2C hat zusätzlich noch eine Zieladresse. Da wird dann nicht hleichzeitig gelesen und geschrieben, da nur eine Datenleitung. Ein Slave kann die als Ack auf 0 ziehen. Ok. Aber wie geht das mit der Datenkollision bei CAN? Bei Wikipedia steht, dass beim senden beprüft wird, ob wer anderes sendet. Wenn nun aber ein Teilnehmer sendet und mit dem ersten Bit anfängt (laut Wiki ist das eine 0), woher weiß er dann, dass die 0, die am Bus ist, seine eigene ist und nicht z.B. das Bit 5 des Identifiers eines anderen Teilnehmers, der bereits sendet? Oder schalten alle Teilnehmer auf "Busy" sobald ein Teilnehmer eine 0 liefert? Oder auch: Wie geht das mit dem Ack? Die ID sagt ja, von wem die Nachricht ist. Was ist nun, wenn darauf niemand reagiert? Oder was ist, wenn darauf 2 Teilnehmer reagieren? Wodurch stellt man sicher, dass das Ack von beiden kommt und nicht nur von einem? Ich denke, ich werde mir das einfach mal aufbauen und testen. Ich will bloß nicht, dass ich mir das irgendwie "falsch" beibringe. Je komplizierter/komplexer etwas ist, desto mehr kann man falsch bzw. unschön machen. Es soll z.B. nicht so kommen, dass ich das iwie zum laufen kriege, doch wenn ich dann aber meinen Code zeige, jemand sagen kann: "Wieso vergewaltigst du den Bus denn so, nimm doch xy oder mach es so und so". Lieber gleich richtig lernen. Genauso wie programmieren. Wenn sich das jemand selbst beibringt, kann es dazu führen, dass andere, die das gelehrt bekommen haben, die Hände über den Kopf zusammenschlagen und Augenkrebs bekommen.
Das ist ja der Trick beim CAN - es wird nicht nur stumpf gesendet, sondern simulatan auch empfangen, was gerade auf dem Bus passiert. Und so kann ein Sender feststellen, dass er von einem anderen Sender "platt gemacht" wurde (höhere Priorität), also dass, was er versucht zu senden klapt oder eben auch nicht. Das unschöne an der Sache - es wird mit dominantem und rezessivem Pegel gearbeitet. Ermöglicht erst obige Vorgehensweise, begrenzt dadurch aber Datenrate und Bandbreite. Von wem und von wievielen das ACK kommt, hat nichts zu bedeuten - Hauptsache, eines kommt (in der Realität sendet jeder Knoten ein ACK). Das heisst aber nur, dass die Botschaft formal richtig war. Nicht mehr, nicht weniger. Ob sich überhaupt jemand dafür interessiert oder ob der Empfänger, den es interessieren sollte, diese auch korrekt empfangen hat, erfährt der Sender damit nicht. Heisst nur: Paket war korrekt, Bus ist in Ordnung, es gibt mindestens einen anderen Teilnehmer. Gibt aber wirklich genug Literatur zu den grundlegenden CAN-Themen.
ich schrieb: > woher weiß er dann, dass die 0, die am Bus ist, seine eigene ist und > nicht z.B. das Bit 5 des Identifiers eines anderen Teilnehmers, der > bereits sendet? Jeder CAN-Knoten hört ständig mit, und weiß deshalb, was gerade auf dem Bus los ist, also welches Bit da gerade gesendet wird. Daher weiß ein Knoten auch, wann er überhaupt probieren darf, sein eigenes Paket zu senden. Und wenn ein CAN-Knoten sendet, liest er Bit für Bit ständig vom Bus zurück, und überprüft, ob jedes Bit korrekt auf dem Bus steht. Sobald ein andere CAN-Knoten das eigene, "schwache" Bit überstimmt hat, beendet der CAN-Knoten mit dem schwachen Bit die Sendung, und versucht es später wieder.
Es müssen immer alle Ack senden. Ist das nich der Fall sendet der nack Teilnehmer ein Errorframe und zerstört damit die Nachricht.
We CAN schrieb: > Daher weiß ein > Knoten auch, wann er überhaupt probieren darf, sein eigenes Paket zu senden. Das habe ich mir gedacht. Auf der anderen Seite heißt es aber auch, dass bei einer Kollision der Teilnehmer mit der höheren Priorität (kleineren ID) Vorrang bekommt. Gilt das nur bei exakt gleichem Start? Denn sonst: Wenn jemand mit der ID 3 sendet und ein Teilnehmer mit ID 2 zwischenfunkt, müsste doch der 2. Teilnehmer senden dürfen, da bei einer Kollision die Priorität entscheidet. Der 1. Teilnehmer wird aber nie erfahren, welche ID der andere hat, da die Kollision ja schon am Anfang auftritt und die Übertragung abgebrochen wird. Die vom 1. Tn. gesendete Nachricht könnte durch die Kollision aber verfälscht sein, weshalb er ja auch nochmal senden müsste. Wenn die Kollision auftritt, bevor der 1. Tn. die erste 1 seiner ID gesendet hat, weiß also kein Teilnehmer, wer denn die höhere Priorität hat und somit, wer nun senden darf. Wenn es nicht so ist und alle Teilnehmer nicht senden, sobald einer den Bus belegt, ist das bei schnellen Reaktionen (z.B. Airbag) doch kontraproduktiv, oder?
Ist nicht kontraproduktiv, da man die worst case Zeit, die ein Knoten zum senden brauch offline berechnen kann. Man weiß ja, dass im ungünstigsten Fall man ein Bit nach dem der Störer den Bus belegt den Airbag auslösen will, dann kennt man die maximale Länge der Nachricht, die der Störer sendet und daher weiß man vorher schon, ob der Airbag rechtzeitig auslöst.
ich schrieb: > We CAN schrieb: >> Daher weiß ein >> Knoten auch, wann er überhaupt probieren darf, sein eigenes Paket zu senden. > > Das habe ich mir gedacht. Auf der anderen Seite heißt es aber auch, dass > bei einer Kollision der Teilnehmer mit der höheren Priorität (kleineren > ID) Vorrang bekommt. Gilt das nur bei exakt gleichem Start? Ja. Es gibt aber auch keinen anderen Fall, da ein Teilnehmer nur beginnen darf, wenn kein anderer Teilnehmer gerade am Senden ist. > Denn sonst: Wenn jemand mit der ID 3 sendet und ein Teilnehmer mit ID 2 > zwischenfunkt, müsste doch der 2. Teilnehmer senden dürfen, da bei einer > Kollision die Priorität entscheidet. Der 1. Teilnehmer wird aber nie > erfahren, welche ID der andere hat, da die Kollision ja schon am Anfang > auftritt und die Übertragung abgebrochen wird. Die vom 1. Tn. gesendete > Nachricht könnte durch die Kollision aber verfälscht sein, weshalb er ja > auch nochmal senden müsste. Wenn die Kollision auftritt, bevor der 1. > Tn. die erste 1 seiner ID gesendet hat, weiß also kein Teilnehmer, wer > denn die höhere Priorität hat und somit, wer nun senden darf. Es gibt keine Kollision im Ethernetsinne. Die Erklärung beschreibt nur, was hinten rauskommt. Der Gewinn der niedrigen ID ergibt sich dadurch, dass die höhere ID verfälscht wird. Und diese hört auf. Die Nachricht des Gewinners wird nicht verfälscht. > Wenn es nicht so ist und alle Teilnehmer nicht senden, sobald einer den > Bus belegt, ist das bei schnellen Reaktionen (z.B. Airbag) doch > kontraproduktiv, oder? Es gibt im Auto nicht nur einen großen CAN Bus mit allen Teilnehmern gemeinsam. Sondern viele verschiedene. Du hast insofern aber recht, dass man die Übertragunszeiten der anderen Teilnehmer bei seinen Überlegungen berücksichtigen muss, wenn man in den zeitkritischen Bereich kommt.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.