Hi! Hat irgendjemand schon Erfahrungen mit CAN-Bus gemacht? Ich hab irgendwo schon µCs gefunden die sowas integriert haben aber ich bin noch von dem LCD-Treiber im Mega169 bedient. Gibt es da was, was man an den seriellen Port des µCs anhängen kann?
Hallo, der CAN-Bus ist eine sehr gute Möglichkeit uC miteinander zu vernetzen. Durch seine Multi-Master-Fähigkeit spart man sich richtig viel Code im uC. Trotzdem hat der CAN einige Fallstricke die es zu beachten gilt. Das Preis-Leistungsverhältnis stimmt dabei auch, es ist unwesentlich teurer als ein RS485-Netzwerk. Eine Umsetzung auf eine serielle Schnittstelle ist nur bedingt möglich. Der CAN definiert Baudraten bis 1 MBit ein 08/15-PC kommt damit nicht richtig gut zurecht. Es gibt zwar ein paar Möglichkeiten über die sogenannte Aktzeptanz-Filterung das zu verbessern, eine professionelle Möglichkeit ist dies aber nicht. Alternativ stehen als die CAN-Paralellport-Adapter zur Verfügung, die das zumindest im Low-Cost Bereich vernünftig können. Eine Selbstbauvariante ist dabei das CAN200-Projekt aus dem Linux-Umfeld -> http://private.addcom.de/horo/can200/ für das es jedoch auch Windows-Treiber gibt. Gruss, Peter
Danke! Die Beiden Seiten sind schon mal nicht schlecht. Ich hatte mit dem Gedanken gespielt die Übertragungsrate zu reduzieren, um die 6.2km Leitungslänge ausnutzen zu können. (Habe ich irgendwo im Internet gefunden). Im Moment sehe ich da noch nicht so ganz durch. Ich hatte mir das einfacher vorgestellt als ich gelesen habe, dass die Blinker im Daimler inzwischen auch nur noch per CAN-Bus bedient werden. Nach dem was ich bisher habe steckt da aber ein irrsinniger Programmieraufwand für die Serielle Schnittstelle dahinter?
Nimm einen Microchip-Controller, die kannst Du einfach per SPI an Deinen MC hängen. Gab schon etliche Beiträge dazu hier im Forum. Suche benutzen.
@Michael Super Idee! Welches der 0 Suchergebnisse nach CAN im Forum hälts Du für das Aussagekräftigste? Ich würde mir Deinen Vorschlag je gerne mal anschauen wenn ich dazu was finden würde.
Hallo tex, der Blinker vom Daimler ist ein gutes Beispiel : Stell dir mal vor Blinker-Schlalter, Bremslicht-Schalter, Bremslicht-Lampe, Blinker-Lampe sind miteinander vernetzt mit zwei Drähten (CAN). Du drückst auf die Bremse deines SL500 und auf die uS zeitgleich setzt du den Blinker. Bei einem selbstprogrammierten RS485-Netzwerk müsstest du richtig viel Code investieren, um diese Kollisionen zu detektieren oder zu verhindern. In dem Blinkerschalter(z.B. von Hella) müsste zusätzlich noch das gleiche Protokoll laufen wie in der Rücklicht-Einheit (z.B. von OSRAM). Die CAN-Controller sorgen automatisch dafür, dass die wichtigere Botschaft (Bremslicht) sofort ohne Kollisionen durchkommt, aber die 2. Botschaft (Blinker) anschliessend gesendet wird ohne dass die Übertragung ein zweites mal angestossen werden muss. Gleichzeitig hören alle anderen Teilnehmer am Bus diese Boschaften auch mit. Dein Instrument weiss somit auch gleich dass es die Kontrolllämpchen für den Blinker blinken lassen muss. CAN ist für mich die optimale Möglichkeit mehrere uC auf einfachstem und gleichzeitig sicheren Weg zu vernetzen. Hast du nur zwei uC die Punkt-zu-Punkt miteinander reden, reicht die serielle Schnittstelle aus, werden es mehr bist du mit CAN allemal besser bedient als mit RS485-Low-Level. Bei Kosten von 8-12.- Euro für einen PIC18F258 ist das auch noch für die Märklin-Eisenbahn im Keller noch tragbar. Eine Möglichkeit, die die wenigsten realisert haben, ist die Low-Speed Vernetzung der CAN-Controller. Damit hast du die Möglichkeit über 3 Leitungen(+12V, Masse, CAN) deine Slaves zu versorgen und gleichzeitig den CAN zu betreiben. Dafür brauchst du lediglich Low-Speed-Transceiver anstatt den differentiellen Typen (... mit viel Erfahrung kannst du es auch diskret mit Widerständen aufbauen). Gruss, Peter
@Peter Die theoretischen Grundlagen, hier noch einmal sehr schön von Dir dargelegt, habe ich schon zusammen, darum die Entscheidung auf mein neues Bastelboard eine CAN - Bus draufzubringen .. ABER.... ich habe nichst praktisches. Woher kommt denn nun diese Prioritätsaufteilung? (Aus der Adresse, schon klar! und wo kommt die her?) Es muss doch irgendwo jemanden geben, dem ich sage "Du bist die Blinkleuchte". Das muss doch irgendwo rein. Irgend so ein kleiner schwarzer Tausendfüßer muss mit irgend etwas an mein Mega128 ran? Und der muss irgendwie Daten an das Ding verschicken. Es muss doch sowas wie Schaltungsbeispiele, Programmbeispiele und solches geben und ich will mir fast nicht vorstellen das in jedem Daimler-Blinker ein kompletter µC steckt. Ich gebe aber zu dass ich noch nicht geschafft habe zu schauen, was in diesem MCP2515 steckt. Daimler ist für mich übrigens, was das Steak für den Veganer. Ich würde sowas nicht fahren wenn man mich dafür bezahlen würde. Soviel zu "meinem" SL500 ;-)
CAN-Bus Controller ? Schau mal bei Motorola rein. Die haben reichlich Controller mit Can-Schnittstelle. Einige PIC's bieten ebenfalls Can an. Bei Atmel müßte ich jetzt nachsehen aber ich bin sicher das es auch hier was gibt.
Hoppla,zu schnell gesendet. @Tex Zu "Daimler" und "Steak für Veganer" : Es ist absiolut latte ob Daimler,BMW,Ford,Opel oder Volkswagen. Is überall der selbe Müll drinne ;-)
Nein nein! Bitte nicht CAN im µC wenn es sich vermeiden lässt. Ich bin noch bedient von LCD-Controller im µC! Und wenn der Zauber nicht so will wie ich, dann will ich die Chance haben noch mal meinen guten alten 80537 um Rat zu fragen.
Hi tex, nicht böse sein wegen dem SL :-) Doch es ist wirklich so dass in den Fahrzeugen für alles mögliche sogenannte Steuergeräte (...ein uC) verwendet wird. Es macht auch Sinn, der Aufwand zu verkabeln, z.B. Blinker links, Blinker rechts,Bremslicht, Rücklicht, Rückfahrleuchte, Nebelschlussleuchte,.... macht sehr viel Montage-Aufwand und Verkabelungskosten, usw. aus. Ein uC, für den Daimler keine 8-12.- Euro bezahlt sondern ein paar Cent ist dort besser angebracht und bietet zusätzlich noch (aufpreispflichtigen) Mehrwert wie z.B. Überwachung der Lampen o.ä. Zum Thema CAN-Controller am uC : Bei deinem Mega128 kannst du den 1000-Füssler auf 28 Pins mit einem SJA1000. Von den 28 Pins kannst du schon mal 11(AD ALE,RD,WR) direkt ohne weitere Beschaltung mit dem SJA verbinden. den 12ten (/CS) kannst bildest du dir aus deinen Adressleitungen. Der Rest ist CAN-Leitungen Versorgung, Mode, Clock,.... Schaltungen hierfür müsste es zu dutzenden in Netz geben. Sind dir die 12 Leitungen zu viel kannst du dir auch den besagten MCP2515 (SPI) gönnen der braucht ein paar Leitungen weniger, dafür ein paar Code-Zeilen mehr. zum Thema CAN-Controller im uC : Kann ich bei meinen bisherigen Erfahrungen 68HC12,ARM,... nur positives Berichten. Atmel baut den ATMega128 auch als AT90CAN (..oder so) pinkompatibel zum Mega128 auch mit CAN (schwer erhältlich) Gruss, Peter
...noch was vergessen. Die Priorisierung wird anhand der CAN-ID festgelegt. Diese vergibt wiederum der Hersteller an seine Zulieferer. Jedem ist dabei etwas anderes wichtig. Bei den Italienern kann z.B. die Fanfare wichtiger sein als so schnöde Sachen wie ein Bremslicht ;-)
"Bitte nicht CAN im µC wenn es sich vermeiden lässt." Kann ich nicht nachvollziehen. Ich nehme den AT89C51CC03, das ist ein voll kompatibler 8051 Core mit CAN. Als nächstes ist auch der LPC2119 (ARM + 2*CAN) geplant. Peter
Also das mit dem CAN auf dem "MEGA128" prüfe ich gerade. Gibt es dann so etwas wie ein Register in dem ich die ID per Software festlegen kann? Was passiert dann beim Reset. Es braucht doch dann jeder eine eigene ID, oder?
Ja es gibt so ein Register. Nach einem Reset wird hoffentlich zuerst wieder Initialisiert, genau wie nach jedem Einschalten??? Jede Nachricht bekommt eine ID. Jeder Empfänger wertet diese ID aus und entscheidet, ob die Nachricht für ihn gedacht ist. Schaltest Du in deinem SL das Licht an und setzt den Blinker, so wird der Controller z.B. eine Nachricht mit der ID 0x20 und dem Inhalt 0x01 und eine zweite mit ID 0x21 und Inhalt 01 senden. Die Blinkercontroller sind auf ID 0x20 eingestellt und sehen 0x01 für einschalten. 0x21 ist für die beiden Scheinwerfer und die Rücklichter. Die Lichter könnten dann mit den IDs 22-25 die korrekte Funktion bestätigen.
@Alle Erst mal vielen, vielen Dank für die Unterstützung. Ich baue jetzt mein Board noch mal neu auf mit 90CAN128. Ich werde mich jetzt erst mal auf die Suche nach Daten und Schaltungsbeispielen begeben. Ich denke, dass ich den 90CAN128 an den CAN - Ports noch mit einem PCA82C251 unterstützen muss oder gibt es da noch was besseres?
Hi Leute. Es gibt da noch ein Paar Fragen, die sich da nunmehr zu diesem Thema aufgetan haben. 1. Wieviele Teilnehmer darf der CAN-Bus denn haben? Ich habe mal was von 1023 gehört, wegen der Anzahl der max, verfügabren Adressen, nun habe ich gelesen dass es keine Adressse gibt und alles über die Identifier gelöst wird? Es muss aber eine Grenze geben, weil irgendwann kann der beste Treiber nix mehr treiben. 2. Ich habe mir einen SN65HVD230 als Treiber auserkohren. Ich habe aber nicht rausgefunden wofür ich Vref brauche oder ob ich es überhaupt brauche und wofür. 3. In den Beschreibungen lese ich immer dass ich 3 Leitungen für den CAN - Bus brauche, CAN H , CAN L und Ground, aber in den Treiberbeschreibungen steht nix von GND. Da sind immer nur 2 Leitunegn im Spiel. Was stimmt denn nun? 4. Wenn ich GND tatsächlich brauche, ist es dan der GND meiner Stromversorgung? Das gibt doch höllische Störungen bei einer Leitungslänge von 6,3km?!
Hi tex, 1. Kommt auf die Version an: CAN-A od. CAN-B. Unterscheiden sich in der Bitzahl der 'Adresse': 11 od. 29. Empfehle sowieso grundsätzlich Datenblatt (Standard) von Bosch. Link ist hier ein paar Threads hoeher oder tiefer. 2. Bei Treibern musst Du grundsätzlich erst 'mal rausbekommen, welche CAN Variante es gibt. Persönlich kenne ich Low- und Highspeed Varianten, die sich in den Pegeln der Differenzleitungen unterscheiden. Dann gibt es wohl 12V und 24V Varianten. Danach kannst Du Deinen Treiber auswählen. Auch danach, ob er noch zusätzliche Ein-/Ausgänge haben soll z.B. für Error. 3. 3 Leitungen ist schon korrekt. GND ist gemeinsam. Im Auto: 2 Leitungen & Ground über Karosse oder von 'wo anders'. Aber bin kein Elektroniker sondern nur Programmierer. 4. Leitungslänge im CAN hängt von Übertragungsgeschwindigkeit ab. (Und von Lichtgeschindigkeit. Die soll aber konstant sein, sagt man ;) Generell ist ein bissl Umgewöhnung nötig, wenn man von Protokollen wie TCP/IP kommt, da dort die Kommunikation in der Regel zw. 2 Partnern stattfindet. Deswegen Senderadresse->Empfängeradresse. Im CAN ist die Adresse wohl eher als 'Nachrichtentyp' zu sehen, der an alle gerichtet ist, die sich dafür interessieren. Hat leider auch zur Folge, dass es nicht unaufwändig ist, in einem laufenden System 'von aussen' noch herauszufinden, welcher Teilnehmer welche Nachricht geschickt hat.
@4535 Danke. Den Text habe ich schon gelesen, aber ich kann damit die Fragen, die ich oben gestellt habe nicht lösen. Ich habe 1023 unterscheidliche identifier, aber das heißt doch nicht, dass ich nur 1023 Teilnehmer haben kann. Wenn jeder mit gleicher Priorität Daten versenden darf oder schicken, je nach dem, ist das Limit doch nicht die Anzahl der Adressen, sondern die Stromaufnahme der "Lauscher" ?! Das Datenblatt des Treibers habe ich ja, aber ich kann nicht finden, was Vref darin tut. Das geht in eie Blackbox und Schluss ist ... Ground im Auto als Karosse ist schon ok, aber ein Karosse von 6,3km Länge, die nur 0.6mm dick ist, ist im Automobilsektor selten. In den Schaltbildern der Treiber sind immer nur 2 Leitungen gezeichnet und wenn ich meine 1024 Boards über ein Strecke von 6.3km mit o,6mm Leitung verbinde dürften die Ergebnisse der AD-Wandler und so einiges mehr nicht mehr sehr brauchbar sein.
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.