Hallo Forum! Es gibt unendlich viel über CAN zu lesen. Aber wo fange ich an? Ich möchte gerne irgendwann einen AVR (mit CAN oder ohne?) an den CANbus bekommen. Gibt es vielleicht ein Tutorial, Buch oder was auch immer, dass das anhand eines Mikrocontrollers erklärt? Und zwar so, dass das auch ein nicht Wissenschaftler versteht. Bin jetzt gleich erstmal weg, aber freue mich auf eure Beiträge. Und bitte, nicht wie in jedem Beitrag darüber, diese Beiträge "Lass die Finger davon, wenn du noch nichts damit gemacht hast!", die bitte sein lassen. Irgendwann haben auch die CAN Cracks einmal angefangen. Was muss man wissen, welches CAN für Nutzfahrzeuge. Also CANopen ist schon einmal Pflicht für mich. Lieben Dank! Liebe Grüße Frank
F. F. schrieb: > Es gibt unendlich viel über CAN zu lesen. Aber wo fange ich an? z.B. mit den Suchbegriffen "CAN"+"tutorial"
Beitrag #5527913 wurde von einem Moderator gelöscht.
CAN selber ist ganz einfach, Baudratengenerator initialisieren, ein MOB (Message Object) als Empfänger, ein MOB als Sender konfigurieren, fertig. Dafür gibt es für den konkreten MC Beispielcode vom Hersteller. Für darauf aufsetzende Protokolle muß man dann den jeweiligen Protokollstandard lesen und die sind oft recht ausufernd. Der konkrete MC spielt dabei keine Rolle mehr. Diese Protokolle rufen dann nur noch CAN-Senden bzw. CAN-Empfang auf.
Das ist zwar nicht am praktischen Beispiel von einem Microcontroller, aber falls du was zum CAN als Bus lernen willst, hat die Firma Vector auch ein kostenloses e-Tutorial dazu.
Besorg dir unbedingt eine gegenstelle die SICHER funktioniert. Wenn du deinen avr und die gegenstelle debuggen musst drehst du bald am rad. Muss ja kein teures produkt sein. Mit 40€ bist du gut dabei Die cia pdfs sind öffentlich. Ran an den feind. Da kann nichts kaputt gehen... Sg
Clemens S. schrieb: > Besorg dir unbedingt eine gegenstelle die SICHER funktioniert. Ganz wichtiger Tip. 30€ tun es auch: https://www.antratek.de/usb-can-v7-00-analyzer?gclid=EAIaIQobChMIvK-Hje753AIVROd3Ch2CMwCAEAYYASABEgLsF_D_BwE Meistens benutze ich aber die von PEAK, die sind bei mir seit über 10 Jahren über jeden Zweifel erhaben. Nicht mehr ganz zeitgemäss (ein Riesenchip, meist zu gross), aber dennoch ganz gut zum Einarbeiten: der MCP2515 + die gut dokumentierte Software von http://www.kreatives-chaos.com/ Die SPI-Schnittstelle ist kein Problem und funktioniert auch bei hohen Datenraten. Hat den Vorteil, dass man damit den CAN mehr oder weniger an jeden MC anstricken kann. AVRs mit integriertem CAN finde ich zu teuer und setze ich auch nirgenwo in Serie ein. Bei ST und NXP (natürlich auch anderen) wirst du fündig. Besonders witzig: LPC11 mit integriertem CAN-Transceiver, also eine echte Einchip-Lösung.
F. F. schrieb: > Es gibt unendlich viel über CAN zu lesen. Sprut hatte sich mal die Muehe gemacht,etwas Informationen darueber zu verbreiten: http://sprut.de/electronic/interfaces/can/can.htm Desweiteren habe ich 2 Dateien upgeloaded - in Englisch. Der eine Anhang ist besteht aus 5 Elektorartikeln, der andere ist ein minimalistischer "Vortrag" - gedacht als Unterrichtsstoff fuer Studenten.Hatte ich irgendwann mal gefunden als Teil einer groesseren "Schulbuchlektuere" - eine die mir heute noch gute Dienste leistet wenn es um Grundlagen geht....
So, bin wieder zu Hause. Danke für die vielen Tipps. Werde nächste Woche von oben abarbeiten. Der MCP2515 ist mir auch schon ins Auge gestochen und dass du gute Erfahrungen gemacht hast, hilft mir in der Beurteilung weiter. Wenn ich das was ich bisher las richtig verstanden habe, machen die tranceiver den Busverkehr selbstständig. Das was das gesendet wird muss dem entsprechenden Protokoll entsprechen. Ist das so im Ansatz schon einmal richtig?
F. F. schrieb: > Wenn ich das was ich bisher las richtig verstanden habe, machen die > tranceiver den Busverkehr selbstständig. Das was das gesendet wird muss > dem entsprechenden Protokoll entsprechen. > Ist das so im Ansatz schon einmal richtig? Nicht ganz: Der Controller kümmert sich um den Empfang und Versand der CAN-Botschaften. CAN-Controller sind z.B der externe MCP2515, oder bereits im Mikrocontroller integriert wie beim AT90CAN oder dann die größeren 32-Bitter (STM32, ATSAM, LPC). Der Transceiver wie z.B. MCP2551 ist lediglich ein Leistungsverstärker um die einzelnen Bits über die CAN-Busleitungen zu schubsen. Die Intelligenz dagegen sitzt im Controller.
H.Joachim S. schrieb: > Ganz wichtiger Tip. > > 30€ tun es auch: > > https://www.antratek.de/usb-can-v7-00-analyzer?gclid=EAIaIQobChMIvK-Hje753AIVROd3Ch2CMwCAEAYYASABEgLsF_D_BwE Der scheint auch direkt bei den Chinesen erhältlich zu sein (ebay, ...). Gibt es dafür auch eine SW, die unter Linux läuft?
F. F. schrieb: > Der MCP2515 ist mir auch schon ins Auge gestochen... Würde ich nicht machen. Für das Geld für den, bekommst du bestimmt auch schon einen Controller mit CAN Modul. z.B. den PIC18F25K83. Bei Mouser gerade sogar günstiger wie der MCP2551. Von anderen Herstellern gibt es da vermutlich auch was, aber da kenne ich mich nicht aus. Mit dem MCP2515 bräuchtest du ja drei Chips. - einen Controller mit Hard- oder Software SPI - den MCP2551 (nenen wir ihn SPI <-> CAN Wandler) - einen Transceiver, z.b. MCP2551 (ganz grob so was wie ein MAX232 für CAN) Beim PIC18F25K83 brauchst du auch einen Transceiver. (von On-Board Sonderlösungen wie der Siemens AP2921 mal abgesehen). Es gibt auch Controller die ALLES beinhalten, auch den Transceiver. Da kann ich dir aber keinen nennen ;-)
F. F. schrieb: > Irgendwann haben auch die CAN Cracks einmal angefangen. CAN an sich ist auch relativ simpel. Da reicht schon der Wikipedia-Artikel. F. F. schrieb: > Also CANopen ist > schon einmal Pflicht für mich. CANopen hingegen ist ziemlich kompliziert. Das passt ggf. nichtmal auf die kleinen AVR's. Da gibt es ein paar Bücher zu, die braucht man da der Standard kaum lesbar ist... Es gibt auch fertige Software-Pakete dafür - als Open-Source und auch kommerziell - dann muss man nicht alles selber machen. Es ist aber möglich ein normales, nicht-CANopen-Gerät, in eine CANopen-Netz einzubinden, indem man dessen fixe Nachrichten bei den anderen Nodes als PDO's konfiguriert. Ist nicht sehr sauber, aber bei fixen Systemen kommt man so schneller ans Ziel. Ich würde auch dringend zu einem Mikrocontroller mit integriertem CAN-Controller raten, das macht vieles einfacher. Ich mag das "Olimexino-STM32" Board gerne, das hat CAN schon fix und fertig aufgebaut - wenn es nicht unbedingt AVR sein muss, ggf. eine Option.
F. F. schrieb: > Was muss man wissen, welches CAN für Nutzfahrzeuge. Also CANopen ist > schon einmal Pflicht für mich. Warum CANopen? Ich kenne das als Protokoll für die (Industrie-) Automatisierungstechnik. Wird das in Nutzfahrzeugen tatsächlich auch verwendet?
Dr. Sommer schrieb: > CANopen hingegen ist ziemlich kompliziert. https://www.can-cia.org/can-knowledge/canopen/canopen-history/ "Now, CiA’s secretaries have to maintain more than 20 000 pages of CANopen specifications."
mmm schrieb: > F. F. schrieb: >> Was muss man wissen, welches CAN für Nutzfahrzeuge. Also CANopen ist >> schon einmal Pflicht für mich. > > Warum CANopen? > Ich kenne das als Protokoll für die (Industrie-) > Automatisierungstechnik. Wird das in Nutzfahrzeugen tatsächlich auch > verwendet? CiA447
CANopen überwiegend für Aufbauer, sonst kaum zu finden. SAE J1939 mit allen Substandards ist im LKW Geschäft der Kommunikationsstandard. So long vom Tier1
F. F. schrieb: > So, bin wieder zu Hause. > Danke für die vielen Tipps. Werde nächste Woche von oben abarbeiten. > Der MCP2515 ist mir auch schon ins Auge gestochen und dass du gute Ja wer auf Oldtimer steht nimmt den MCP2515. Teslafahrer nehmen den MCP2517FD (2,2€) ;-)
Besorg Dir zwei "Arduino Due".Der hat schon einen Can-Bus (Arm PROZ). Die Beispiele enthalten auch die Initialisierung. .
Lexa schrieb: > CANopen überwiegend für Aufbauer, sonst kaum zu finden. Vielen Dank, wieder was gelernt... > SAE J1939 Den hab' ich schon mal gehört. Wobei ich meine, gelesen zu haben (Elektronik Automotive?), dass die Nfz-Hersteller inzwischen auch in Richtung AUTOSAR schielen (wegen ReUse und Kostenerspanis - wer's glaubt...)
mmm schrieb: > Lexa schrieb: >> CANopen überwiegend für Aufbauer, sonst kaum zu finden. > > Vielen Dank, wieder was gelernt... Blöde Frage nebenbei: Was sind eigentlich Aufbauer? Kenne CANopen von Motorsteuerungen. Man muss ja CANopen nicht komplett implementieren um einen solchen Motor oder auch einen Sensor zu benutzen. Für eigene Projekte, kann man sich meiner Meinung nach auch super an CANopen orientieren und sich nur die Sachen raus picken, die man wirklich brauchen kann.
AUTOSAR ist eine SW Architektur und im Grunde schon länger auch im Nfz Bereich etabliert. Ein Blick in AR 4.x zeigt, dass ein J1939 Modul dort vorhanden ist, um z.B. die Interaktion zwischen Fehlerspeicher DEM und diagnostic messages (DM1, DM4,...) zu ermöglichen. In der Tat ist der tatsächliche Ausbau des J1939 AR Moduls unterschiedlich zwischen den verschiedenen großen AR Anbietern. Nfz Markt << Pkw Markt Aufbauer: Installieren einen Kran auf einem Lkw Bieten Anzeigen im Bus Machen aus einem normalen Lkw ein Feuerwehrfahrzeug. J1939-DA Das Konzept, mittels OD in CANopen Dinge in DS zu vereinheitlichen und so für schnellen Austausch defekter Komponenten zu sorgen, wird im J1939-DA verfolgt. Anders, als die Pkw Kollegen herrscht bei den wichtigsten Funktionen die Normung vor eigener proprietärer Nutzung.
F. F. schrieb: > Der MCP2515 ist mir auch schon ins Auge gestochen und dass du gute > Erfahrungen gemacht hast, hilft mir in der Beurteilung weiter. Das ist aber eine eher suboptiomale Lösung. Der SPI-Bus ist hier der Flaschenhals, und bei hoher Buslast und hoher Geschwindigkeit wirst Du mitunter Pakete verlieren. Besser sind Prozessoren mit eingebautem CAN Controller. Da gibt es mehr als genügend ÄRMchen und MIPSe. Wenn Du unter allen Umständen an AVR klebst wie die Fliege an der Falle, dann bliebe Dir der 90CAN128 oder der Mega16M1. Da liegt der CAN Controller im Adressraum des Prozessors, der viel schneller reagieren kann. fchk
fchk schrieb: > Das ist aber eine eher suboptiomale Lösung. Der SPI-Bus ist hier der > Flaschenhals, und bei hoher Buslast und hoher Geschwindigkeit wirst Du > mitunter Pakete verlieren. Hörensagen oder selbst erlebt?? Eine CAN-Message besteht schon mal aus z.T. deutlich mehr Bits als die Daten, die über die SPI transportiert werden müssen. Allerdings muss man auch ein paar Registeradressdaten senden, kommt am Ende etwa 1:1 raus. Die SPI kann man aber mit 8MHz betreiben - da verliert man gar nichts, es sei denn man stellt sich blöd an bei der Programmierung, also Luft genug. Dazu kommen Sende- und Empfangsbuffer auf seiten des CAN-Controllers, man muss also auch nicht sofort abholen. Dazu die Filterfunktionen, nicht alles muss im MC landen, was auf dem CAN reinflattert. Und das Gerede der hohen Buslast - ja, soll man niemals aus den Augen verlieren. Praktisch sind aber Fälle mit >50% schon ziemlich selten. Und hier gehts nicht um einen am Limit gefluteten 1MHz-Bus, sondern um erste Grundlagen, und genau dafür finde ich den durchaus geeignet. Jahrelang habe ich auschliesslich den 2515 für alle CAN-Sachen benutzt, niemals gab es einen SPI-Engpass. Inzwischen gibts genug Auswahl an MCs mit internem CAN-Controller, und für neue Sachen benutze ich auch ausschliesslich solche. PS: 1MBaud sind nicht nur die theoretische Höchstgrenze, sondern auch praktisch nur selten anzutreffen. Sehr oft 500kBit, gerne auch weniger. Und dann steht die SPI-Sache schon sehr entspannt da. Hat den netten Nebeneffekt, dass man die slew-rate runterfahren kann und so weniger EMV-Probleme hat, keine abgeschirmten Kabel braucht usw.
:
Bearbeitet durch User
CANopen ist für mich besonders interessant, weil unsere Fahrzeuge damit ausgerüstet sind.
Dann lies z.B. mal: https://www.amazon.com/CANopen-Implementation-Applications-Industrial-Communications/dp/0863802478
H.Joachim S. schrieb: > Und hier gehts nicht um einen am Limit gefluteten 1MHz-Bus, sondern um > erste Grundlagen, und genau dafür finde ich den durchaus geeignet. Ich weniger. Ich finde es nämlich sehr praktisch, wenn beim Debuggen die CAN-Register wie alle anderen auch im Adressraum liegen, wo ich sie mir im Debugger einfach anschauen kann. Und der ECAN im PIC18F25K80 hat ein paar Features mehr und ein paar Bugs weniger, und es entfällt ein Quarz und ein Chip - ja warum soll ich dann zu was schlechterem greifen? fchk
Frank K. schrieb: > Ich finde es nämlich sehr praktisch, wenn beim Debuggen die > CAN-Register wie alle anderen auch im Adressraum liegen, Wie oft interessiert man sich denn für die CAN-Register? Nach der Initialisierung schmeisst man seine Objekte da rein oder holt sie raus, auf welchem Weg das dann genau passiert ist doch egal, interessiert nicht mehr wenn die low-level-Funktionen fertig sind. Dann gibts noch die Fälle, wo man nachträglich ein bestehendes System um CAN erweitern will. Das ist mit ner SPI-Schnittstelle ganz schnell erledigt (statt einen neuen Prozessor zu verwenden und mehr oder weniger die gesamte Platine und die gesamte Software anzupacken). Oder Raspberry z.B. Ich will ja auch gar nicht behaupten dass das der ultimative Einstieg sei (benutze ihn ja selbst kaum noch). Aber ein möglicher und schnell zu realisierender Weg mit bereits vorhandenen Mitteln um mal reinzuschnuppern ist er allemal. Und das vielzitierte SPI-Flaschenhalsproblem existiert nicht wirklich.
Da findest Du einen guten Einstieg. Du wirst sicher das Rad nicht neu erfinden wollen? http://www.kreatives-chaos.com/artikel/universelle-can-bibliothek
F. F. schrieb: > CANopen ist für mich besonders interessant, weil unsere Fahrzeuge damit > ausgerüstet sind. Dann solltest Du einiges an Zeit mitbringen, gegebenenfalls auch einiges an Geld. Hier mal ein paar Links: https://www.can-cia.org/canopen/ https://www.canopenbook.com/ http://www.esacademy.com
Dr. Sommer schrieb: > Dann lies z.B. mal: > > https://www.amazon.com/CANopen-Implementation-Applications-Industrial-Communications/dp/0863802478 Gerne, aber nicht für $2,793.83.
guest schrieb: > Hier mal ein paar Links: > https://www.can-cia.org/canopen/ > https://www.canopenbook.com/ > http://www.esacademy.com Danke! Das Buch gab es als PDF.
H.Joachim S. schrieb: > Ich will ja auch gar nicht behaupten dass das der ultimative Einstieg > sei (benutze ihn ja selbst kaum noch). Aber ein möglicher und schnell zu > realisierender Weg mit bereits vorhandenen Mitteln um mal > reinzuschnuppern ist er allemal. Und das vielzitierte > SPI-Flaschenhalsproblem existiert nicht wirklich. Natürlich wird das nicht der Weisheit letzter Schluss bleiben, aber dann kann man das an "seinen" Controller dran stricken und zum schauen, ob es klappt, finde ich das gar nicht so übel.
F. F. schrieb: > Gerne, aber nicht für $2,793.83. Das gibt's bestimmt auch billiger. z.B. in Uni-Bibliotheken.
H.Joachim S. schrieb: > PS: 1MBaud sind nicht nur die theoretische Höchstgrenze, sondern auch > praktisch nur selten anzutreffen. Sehr oft 500kBit, gerne auch weniger. > Und dann steht die SPI-Sache schon sehr entspannt da. Kann ich bestätigen. Viele Lastenheften der Kunden nennen sogar 5MBaud (weil z.B. TCAN330 das mit FDR angibt), nutzen in ihren Produkten dann aber nur deutlich weniger. Spätestens wenn man die EMV in den Griff kriegen muß, fängt der Aufwand an :) Heutige SPI bei modernen µC und µP auf dem Board ist aber auch da kein Engpaß, eher die EM Abstrahlung.
F. F. schrieb: > Natürlich wird das nicht der Weisheit letzter Schluss bleiben, aber dann > kann man das an "seinen" Controller dran stricken und zum schauen, ob es > klappt, finde ich das gar nicht so übel. Ist sicher ein gutes Argument sich zusätzlich noch in einen neuen Controller einarbeiten zu müssen. Weil ich hauptsächlich (8-Bit)PICs benutze, ist das Umstiegs-Problem für mich möglicherweise etwas kleiner. Eigentlich sind ja alle mehr oder weniger gleich, nur haben einige eben USB, CAN, WHATEVER zusätzlich. Da kann man leicht wechseln. Wenn das nicht so wäre, dann könnte ich mir vorstellen auch diesen Weg zu gehen. Hatte sogar irgendwann mal ein MCP2515-BM Kit gekauft, aber nie genutzt, weil ich dann doch zu faul war mich in diese einzuarbeiten ;-)
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.