CAN-Bus Universaladapter HW Diskussionsthread

[Artur]

So wie es aussieht besteht Bedarf an einem universal CAN Bus Adapter der verschiedene Aufgaben übernehmen könnte.

 

Sie es die Bordsteinautomatik, der RNS-E oder die Drehzalsimulation oder ein Schaltplus für ISO Radios ohne CAN Anschluss.

 

Die Möglichkeiten sind sehr vielfältig. So könnte man auch ohne weiteres eine Software-basierte Reifendruck Kontrolle umsetzen. Die Ergebnisse ließen sich im FIS darstellen usw, usf.

 

In diesem Thread geht es nur um die Hardware auf die sich die Softwareentwickler (und solche die es werden wollen ) hier im Forum einigen sollten. Die Hauptarbeit liegt in der Entwicklung der Firmware, das ist klar.

 

Als Vorschlag wurden u.a. der Arduino Due und der Conrad AVR32 C Control Pro genannt. Beide haben 2x CAN und haben Ihre Vor- und Nachteile.

 

Ich persönlich habe nur sehr wenig Erfahrung mit solchen Boards. Deswegen sind jetzt die Experten gefragt.

Bearbeitet 21. November 2014 von Artur

[KugelwiderWillen]

So extrem viel mag ich jetzt nicht schreiben, denn mit der Programmierung vom Conrad Board hatte ich nicht so viel zu tun, aber wenn der Jenige eine andere Entwicklungsumgebung als für Conrad vorgesehen nutzen möchte, z.B. Eclipse ,der sollte meiner Meinung nach( kein Experte) Abstand davon nehmen.

Da muss man viel Ummodeln, um den Bootloader ansprechen zu können.

Der AVR 32 Chip allgemein, scheint mir aber mit das Beste zu sein, was man so als Privatperson bekommen kann.

Man müsste sich aber mal überlegen, was man wirklich braucht, nicht das man mit Kanonen auf Spatzen schiesst.

Vermutlich reicht auchn 8 Biter aus.....

Dazu müsste man sich wie gesagt sich erst einmal Gedanken machen, was man wirklich braucht.

Z.B an Baudrate/Geschwindigkeit.

Eine JTAG Schnittstelle zum Debuggen nötig?

Für den Entwickler durchaus Sinnvoll...

Das ConradBoard kann eben fast alles...

Nur ob das Nötig ist....

Mit der Haus eigenen Conrad Software habe ich noch nicht gearbeitet.

Wer Spaß an so etwas hat( gibts hier bestimmt ein paar;) )und auch bissl Zeit und Erfahrungen hat,der kann sich das Board ja einfach holen und bissl Üben.

 

Prinzipiell ist ein 8 Biter aber etwas kleiner.kann weniger, aber meist etwas einfacher zu programmieren.Hab bis dato aber nur 8051er MC programmiert, für den AVR32 sind 2 andere zuständig!

 

Wäre nicht auch die Frage, ob wir ein fertiges Entwickler Board wollen oder das ganze nicht selber planen und bauen möchten...

Eigenes kleines Gehäuse, Platine etc.etc.

Würde das natürlich etwas komplizierter machen.

Der Aufwand ist schon nicht ohne!

Bei der Leiterplatine könnte ich unter Umständen helfen, wenn ich denn mal Zeit finde.Wir haben aktuell auch eine Platine in Auftrag gegeben...

 

Bei einer eigenen Entwicklung, würde ich z.B. eine galvanische Trennung vorsehen bei der Spannungsversorgung, bei den DIs und DOs , etc.

Bearbeitet 24. November 2014 von Ingo
Doppelpost

[ra9na]

Ich wäre für eine möglichst offene Entwicklungsumgebung. Die HW von Conrad scheint ja ganz gut zu sein, aber wenn die SW dazu mau ist, macht das auch nur Ärger. Lieber etwas wie Ecplise mit offenem Compiler und am besten JTAG zum Debuggen. Die Platine routen könnte ich ja machen. Hab ein bisschen professionelle Erfahrung drin. Coden könnte ich auch ein wenig.

[Artur]

Wäre nicht auch die Frage, ob wir ein fertiges Entwickler Board wollen oder das ganze nicht selber planen und bauen möchten...

Eigentlich hätten wir da schon was mit 1xCAN, I²C, RS232 und A/D IO von Mankmil:

 

 

So als Basis zum ausbauen. Der erste SW Quellcode liegt auch schon vor. Meinungen?

 

Quelle: A2 Forum - Einzelnen Beitrag anzeigen - Nachrüstung RNS-E 2010 mit MEDIA-Taste

 

Magst du was dazu erzählen Michael?

Bearbeitet 23. November 2014 von Artur

[KugelwiderWillen]

Mitm Schaltplan könnte man sicher noch mehr dazu sagen.

Die 10 polige Buchse könnte ein JTAG sein.wenn ja,wäre das sicherlich gut für den Entwickler.

Für den Anwender ist es nicht so relevant.

Vielleicht ist es auch die RS232 Schnittstelle.

 

Der Aufbau scheint mir persöhnlich etwas zu einfach zu sein .

Ich mag dem Entwickler da aber sicher nicht zu nahe treten, denn mein Fundus ist sicherlich arg begrenzt!

 

Allerdings wäre mir schon ein Dorn im Auge, das die Ein sowie Ausgänge nicht galvanisch getrennt sind.

Wo sind die Optokoppler?

Die Spannungsversorgung ist anscheinend auch nicht galvanisch getrennt.

Ich persönlich würde einfach nix ins Auto einbauen, wenn die DIs und DOs inklusive Schnittstellen nicht galvanisch getrennt sind.

Da würde ich einfach auf Nummer sicher gehen.

 

Der Entwickler kann sicherlich mehr drüber sagen, wieso er es so gebaut hat und warum er auf dieses oder jenes verzichtet hat.

 

Ich wäre für eine möglichst offene Entwicklungsumgebung. Die HW von Conrad scheint ja ganz gut zu sein, aber wenn die SW dazu mau ist, macht das auch nur Ärger. Lieber etwas wie Ecplise mit offenem Compiler und am besten JTAG zum Debuggen. Die Platine routen könnte ich ja machen. Hab ein bisschen professionelle Erfahrung drin. Coden könnte ich auch ein wenig.

Zur Conrad Software kann ich nix sagen, da von Anfang an auf Eclipse gesetzt wurde.Nur das war eben nicht einfach zu realisieren.

Ich könnte die Infos sicherlich bekommen, wie man das ConradBoard mit Eclipse nutzen kann.

 

Hab ein bisschen professionelle Erfahrung drin. Coden könnte ich auch ein wenig.

Schön, dass es hier Leute gibt, die dort Erfahrung drin haben.

Hab letzte Woche eine Platine geroutet, wo man knapp 900 Verbindungen ziehen musste.

War echt schon geschockt am Anfang....

Wie man die ganzen Bauteile sinnvoll platziert um sie unterzubekommen und man sich keine Störungen einfängt....

Dann hab ich die ganzen Linien gesehen hat, für die man dann die ganzen Leiterbahnen ziehen musste....

Bearbeitet 24. November 2014 von Ingo
tripplepost

[seinelektriker]

Moin,

 

ein paar Gedanken zu diesem Projekt Anfang.

 

Die Wahl einer IDE ist natgürlich wichtig. Zumindestens sollte sie nichts oder nur minimal etwas Kosten.

Aber, eine Abhängig sehe ich auch zu den vorhandenen und nutzbaren Software Resourcen.

Wir werden auf einen Standart uC setzten und ggf. Applikation Note und davon abgeleitete Resourcen nutzen. Auch die Grundlagen aus vorhandenen Projekten sollten wir uns sowei als möglich nutzbar machen.

Ich habe in der letzten Zeit bei der Suche deshalb die Arduino Serie merhfach gefunden, weil mögliche Hardware Erweiterungen vielmals schon in Projekten mit vorhandenem Code benutzt werden. Deshalb mein Hinweis u.a. auf den DUE.

 

Es wäre also für uns zu klären, ist die Entwicklung eines uC-Boards besser oder z.B. ein Erweiterungsboard für eine Arduino bzw. anderen Entwicklungsboard.

 

Schnittstellen, eine Frage die Schwierig sein wird.

Der obige Vorschlag ist erst einmal o.K.

Aber, ich selber würde mindestens 2 CAN Bus Schnittstellen mit erweiterten Schutzmeachnismen benutzen wollen (also nicht den MCP 2515) aber scheint es dafür kaum fertige Libs zu geben. Also ist abzuwägen zwischen der Sicherheit, der Einfachheit und vorhandenen Applikationen dazu, usw.

Zwei deshalb, da ich mindestens den Antriebs-Can Lesen und den Info-Can Lesen und beschreiben würde.

Drei da bestimmt auch Steueraufkaben für den Comfort Anfallen werden.

Also optimal 3 CAN Busse (Zwei min. Full, einer nur Lesend - RX Betrieb)

Aber dieses sind nur gedanken zur Planung ...

 

RS232, min. eine Schnittstelle 115K Schnell zum Anschluß eines GPS Moduls.

(Ein GPS-Modul mit 10HZ Ausgabe ...)

eine Zweite RS232 für ein BT-Modul.

SD (Micro-SD) Schnittstelle für Dauerhaften Speichern von Daten.

Ein paar I/O Schnittstellen Digital sowie Analog für spezielle Errweiterungen.

 

Das würde bei einem eigenen uC Board dazu führen, das wir I/O Verbindungen auf Tochter-Board auslagern und eine I/O Schnittstelle definieren.

Denn unser Projekt soll Modular sein, benötigt dazu also auch Anpassungen.

Und Bereitstellung einer Spannunsversorgung für die I/O Hardware also, 5V 3.3V brauchen heute die meisten ICs.

 

Mindestens jedoch sollten wir uns die Frage stellen, ob die I/O Schnittstellen über eine I/O Schnittstelle erweiterbar ist.

Ob es Sinn macht, alle Schnittstellen des uC schon auf der Hauptplatine mit Transiver und / oder Anpass Elektronik auszustatten stelle ich zur Überprüfung. Den Weg der mit den uC-Board verfolgt wird, hat aus dieser Sicht durchaus in meiner Bewertung Vorteile, auch für dieses Projekt.

 

Galvanische Trennung?

Was muss den voreinander Geschützt werden?

Die CAN-Busse?

Warum die Spannungsversorgung?

 

Sicherlich ist eine Störung auf den CAN-Bussen als Kritisch einzustufen.

Ich übertreibe mal Gedanklich etwas,

Info-CAN, o.K. wenn der Gestört wird werden ich das Auto noch sicher stoppen können.

Antriebs-CAN, ja schon sehr Kritisch wenn hier etwas stört.

Deshalb auch meine Überlegung nur die RX-Signale eines CAN-Transivers quasi zu benutzen. Selbst wenn die Software ein Bug hat und etwas Schreiben möchte, geht nicht, da die Hardware fehlt.

Und beim Komfort-CAN gut, sicherlich können Türen verriegeln, ein Risiko zur Bewertung, aber wenn der BUS gestört wird, gehe ich von einer Lokalen Funktion der Tür-STG aus. (Eine unbestätigte Vermutung ... meine derzeitige Ausgangslage einer Bewertung) Und wenn des K-STG ausfällt hat der Hersteller es vorgesehen, das das Linke Fahrer Tür-STG die "Not" Funktion als K-STG übernimmt.

 

Gegen "Brumm" Einstreuungen über Kabel ist der CAN-Bus von sich aus ausgelegt und wird auch deshalb ja verwendet. Das ich selber keine Störungen mit dem Projekt verursache, ja dazu müste ich die I/O Leitungen sichern, also mit C's und L's abblocken, Durchführung-Kondensatoren nutzen, HF Büchsen zum Abblocken verwenden, HF-Sperrfilter einbauen usw.

Das wäre notwendig, auch in der Spannungsversorgung, jedoch ist dieses nicht eine Galvanische Trennung.

Zumindestens für meinen Begriff.

 

Der zur Zeit im Forum dringend gesuchte RNS-E CAN Adapter benötigt mind. zwei CAN-Schnittstellen (Full-TX-RX).

Zwar stellen beide Seiten / Busse Signale des Info-CAN bereit, jedoch auf der Seite zum RNS-E in einem anderen CAN - Dialekt, also eine CAN - Bridge zwischen den Signalen.

Ob ein einziger Info-CAN Port reicht, kann ich im Moment nicht bewerten, sicherlich würden die von RNS-E benötigten CAN-Nachrichten nicht stören, den CAN-IDs die für die STG unbekannt sind, werden vom CAN-ID-Filter verworfen. Ich kenne die HW-Module bislang nicht und konnte deshalb noch keine Rückschlüsse dazu ziehen.

Also es kann mit einem Port funktionieren, mit zwei geht es ganz sicher, ist meine Bewertung mit den mir vorliegenden Informationen dazu.

 

Ein Board von uns könnte auch das Mutter-Board für ein uC-Board sein.

 

z.B. ein Teensy 3.1

ist in D bei "watterott" oder bei "exp-tech" für unter 20€ zu bekommen.

Gut, nur eine möglichkeit, die ich mir auch mal angesehen habe.

Die zwei Händler habe ich mal als Beispiel aufgeführt, es gibt sicherlich noch mehr.

 

Den Ansatz eines bereits vorhandenen uC-Board hatte ich für mich aufgegriffen, um die Entwicklung auf den von uns benötigten Bereich der I/O Schnittstellen zu beschränken.

Deshalb die Suche nach einem so gut wie möglich passenden uC-Board. Eine 100% Lösung wird es sicherlich nicht fertig geben, o.K. wenn wir selber die 100% erreichen, wäre dieses zu verfolgen, aber wenn wir nicht allzu viel besser sind wie vorhandene Resourcen würde ich dieses einsparen und auf vorhandene Module setzten und diese für unsere Projekte adaptieren.

 

Gut, ein Teil meiner Persönlichen Bewertung

[Mankmil]

Eigentlich hätten wir da schon was mit 1xCAN, I²C, RS232 und A/D IO von Mankmil:

 

 

Die 10 polige Buchse könnte ein JTAG sein.wenn ja,wäre das sicherlich gut für den Entwickler.

Die 10polige Buchse ist der PORTB des µC (8bit) und gleichzeitig Anschlussmöglichkeit für ein alphanumerisches LCD-Display.

 

Oben links befindet sich die ICSP-Schnittstelle, über die programmiert und debugged werden kann.

 

Für den Anwender ist es nicht so relevant.

Vielleicht ist es auch die RS232 Schnittstelle.

Diese befindet sich unten dort kann ebenfalls SPI bzw. I2C abgegriffen werden.

 

Der Aufbau scheint mir persöhnlich etwas zu einfach zu sein .

Ich mag dem Entwickler da aber sicher nicht zu nahe treten, denn mein Fundus ist sicherlich arg begrenzt!

 

Allerdings wäre mir schon ein Dorn im Auge, das die Ein sowie Ausgänge nicht galvanisch getrennt sind.

Die Platine ist hauptsächlich ein Eval-Board, daher sind alle Ein- und Ausgänge ungefiltert herausgeführt. Ein direkter Anschluss externer Perepherie scheidet schon auf Grund der Spannungspegel (5V) aus.

 

Wo sind die Optokoppler?

Die dürfen auf einer zusätzlichen I/O Platine ergänzt werden.

 

Die Spannungsversorgung ist anscheinend auch nicht galvanisch getrennt.

Wozu sollte sie? Die wenigstens Steuergeräte im Auto sind galvanisch entkoppelt.

 

Kurz nochmal zusammengefasst:

 

Das gezeigte Eval-Board sollte in erster Linie der Entwicklung eines CAN-Moduls dienen. Daher befindet sich neben der CAN-Hardware und einem LCD-Display keine weitere Beschaltung auf dem Bord. Alle Schnittstellen des Controllers sind nach außen geführt und können für beliebige eigene Anwendungen extern beschaltet werden.

 

Möglich sind:

RS232, I2C, SPI, A/D-Wandlung, digital I/O und 1xCAN

 

Damit spricht für mich bei einer korrekten Erweiterung des Eval-Boards auch nichts gegen eine Anwendung im Auto.

 

Die Firmware des Controllers ist in C geschrieben und basiert weitestgehend auf den Beispielen von Microchip - ist also open-source.

Bearbeitet 24. November 2014 von Mankmil

[jopo010]

Galvanische Trennung ist für solche Anwendungen eher unüblich.

Die Entstörung einer isol. Spannungsversorgung ist i. d. R. aufwendiger, da Koppelpfade dazu kommen, die man sonst nicht hätte.

 

Zu den IOs: Optokoppler sind im Fzg. nicht so gern gesehen, Stichworte: Temperatur, Drift über Lebensdauer. Als Ausnahme fallen mir div. Avago-Koppler ein, die automotive Zulassung haben. Bei der Anzahl der IOs, die hier im Raum stehen, könnte das alleine das budget sprengen. :-D

 

Um das ganze störungssicher zu bekommen, gibt es andere Wege, hierzu sollte man aber die Störquellen und Mechanismen im Fzg. kennen. Wenn ihr den Weg gehen wollt, kann ich gerne helfen.

 

Grüße...

Bearbeitet 24. November 2014 von jopo010

[Artur]

Im Elektro-A2 gibt es mehrere Anwendungsfälle die zumindest einen galvanisch getrennten CAN-Anschluss erfordern.

 

Der Motor Controller läuft mit 96V und dessen CAN Bus ist leider nicht galvanisch entkoppelt.

 

Aber ich denke dass das zur Not auch mit einer Zusatzplatine im Einzellfall nachgerüstet werden könnte. Oder irre ich mich da?

[Mankmil]

Der auf dem Board verbaute Transceiver (MCP2551) verfügt über keine galvanische Trennung. Google sagt aber, dass es hierfür spezielle CAN Transceiver für den Automotive-Bereich gibt. Dieser ließe sich dann (extern) 'nachrüsten'.

 

Ein geeigneter Kandidat wäre bspw. der TJA1052i...

Bearbeitet 24. November 2014 von Mankmil

[ra9na]

Sollte machbar sein... eine Art aktives Adapter, welches die Signale entkoppelt sollte relativ einfach zu realisieren sein.

 

Vielleicht etwas uebertriebene Rechenleistung, aber die zwei hier haben je vier CAN I/Os:

MPC5121e

MPC8309

 

Damit duerfte so ziemlich alles abzudecken sein !

Vermutlich gibt es geeignetere fuer unser Vorhaben, aber hab keine Herstellerseite gefunden, bei der man die Anzahl der CAN I/Os filtern kann. Nur CAN ja/nein... Schwach!

Bearbeitet 24. November 2014 von ra9na

[jopo010]

Im Elektro-A2 gibt es mehrere Anwendungsfälle die zumindest einen galvanisch getrennten CAN-Anschluss erfordern.

 

Das ist klar, sinnvoller Weise sollte man aber dann die Isolationsstrecke nah oder innerhalb der HV-Insel bauen, sonst müsste man ja die HV-Seite weit ins Fahrzeug ziehen, in dem Fall hier bis an das besagte Modul.

Dann nicht direkt die CAN-Leitungen trennen, sondern die TxD und RxD zwischen Tranceiver und uC. Es muss auch kein Optokoppler sein, dafür gibt es gute Magnetkoppler, hier ein schönes appnote dazu:

 

http://www.analog.com/static/imported-files/application_notes/AN-770.pdf

Bearbeitet 24. November 2014 von jopo010

[Artur]

Schaut euch mal die Produktpalette der MRS Electronic an. Damit könnte man fast die gesamte Hardwareanforderung erschlagen.

 

Meinungen?

[ra9na]

Die haben alle nur ein CAN Interface. Sprich man braucht fuer jeden Bus eine separate Box. Die Frage ist, wie teuer ist so eins?

Man kann auch noch ein Gateway nehmen, aber das kostet ja auch nochmal...

[Mankmil]

Mir wäre die Entwicklungsumgebung viel wichtiger als die eigentliche Hardware. Das liegt aber auch daran, dass ich meine Hardware gern selbst entwickle.

Um Synergien zu erzeugen, wäre für mich ideal wenn es eine Entwicklungsumgebung in C wird. Die eigentlichen Funktionen lassen sich dann ohne große Schwierigkeiten auf verschiedenste Hardware portieren.

 

Arthurs Beispiel wäre damit durchaus geeignet - wem's gefällt.

[Artur]

Die können alle auch in C programmiert werden. Wahlweise auch mit deren Software. Diese wiederum generiert ein C Programm welches bei Bedarf ergänzt werden kann.

 

Grafische Programmierung mit dem Softwaretool CANgraph und passendes Flash-Programmiertool oder Programmierung mit einem C-Entwicklungssystem.

 

Die haben alle nur ein CAN Interface.

Dieses hier hat 3xCAN und mehrere A/D IO. Bearbeitet 2. Dezember 2014 von Artur

[Mankmil]

Die können alle auch in C programmiert werden.

 

Eine Runde weiter!

 

Wahlweise auch mit deren Software. Diese wiederum generiert ein C Programm welches bei Bedarf ergänzt werden kann.

Das kann ganz schnell zur Sackgasse werden. Wenn es ein open-source Projekt werden soll, dann würde ich mich ungern von einer Entwicklungssoftware abhängig machen. Den C-Code den der Compiler ausspuckt kann man höchstwahrscheinlich nur noch schwer lesen bzw. modifizieren.

 

Im besten Fall wird im 0815-Texteditor programmiert und durch den C-Compiler gejagt. Das bekommt man auf Windows, Mac und Linux zum Laufen...

 

 

Dieses hier hat 3xCAN und mehrere A/D IO.

 

Für das was da einer kostet kann man schon eine Kleinserie einer Eigenentwicklung auflegen.

[Artur]

Den C-Code den der Compiler ausspuckt kann man höchstwahrscheinlich nur noch schwer lesen bzw. modifizieren.

Vermutlich.

 

Für das was da einer kostet kann man schon eine Kleinserie einer Eigenentwicklung auflegen.

Hängt stark von den Stückzahlen ab. Die haben Staffelpreise. Geht bei einem Stück los, dann fünf, zehn, 25, 50 usw.

 

Wir müssen das hier nicht weiter verfolgen. Konzentrieren wir uns lieber auf die Eigenentwicklung.

 

Hey, ich bin gerne Idealist. 'Unser' Board wird vermutlich billiger und vermutlich auch mehr leisten. Und es wird alle Wünsche berücksichtigen können. D.h. es es spricht 4xCAN, einer davon entkoppelt, mehr I/O als wir jemals realisieren können, viele viele Schnittstellen usw. usf. Leider kann ich zur HW Entwicklung nichts beitragen.

 

Ich freue mich dennoch drauf!

Bearbeitet 2. Dezember 2014 von Artur

[ra9na]

Also ich bin auch dafür, dass wir ein eigenes Board basteln. Dann sind wir bei de Entwicklungsumgebung maximal flexibel, was auf jeden Fall hilfreich ist, falls wir aus irgendwelchen Gründen diese mal wechseln wollen oder anfangs mehrere parallel probieren.