Forum: Mikrocontroller und Digitale Elektronik CAN-Interface mit galvanischer Trennung für Pandaboard (OMAP4)

Schau mal hier:

http://www.kreatives-chaos.com/images/206.png

Dort wurde das auch per DC/DC-Wandler von Reichelt gelöst und die 
Schaltung funktioniert definitiv sehr gut. Der Typ müsste in der 
Beschreibung stehen, aber ich meine, das wäre sogar Dein Vorschlag 
gewesen.

Chris D.

Chris D. schrieb:
> Schau mal hier:
>
> http://www.kreatives-chaos.com/images/206.png
>
> Dort wurde das auch per DC/DC-Wandler von Reichelt gelöst und die
> Schaltung funktioniert definitiv sehr gut. Der Typ müsste in der
> Beschreibung stehen, aber ich meine, das wäre sogar Dein Vorschlag
> gewesen.
>
> Chris D.

Du hast recht, das ist genau der AM1S-0505SZ. Allerdings wird dort noch 
eine Filterschaltung an den Wandler gehangen. Ich hatte bisher nur einen 
300 Ohm Widerstand an der Ausgangsseite, um den Wandler zu belasten. Ist 
das Ausganssignal des Wandlers so schlecht, dass der Filter gebraucht 
wird?

Was ich vielleicht noch erwähnen sollte: Die Schaltung sollte so robust 
sein, dass man auch gefahrlos einen realen Fahrzeug-CAN-Bus anklemmen 
könnte. Vielleicht kennt ja jemand die typischen Standard-Bausteine, die 
im Automotive-Bereich eingesetzt werden.

Außerdem überlege ich grade, wie sinnvoll die LEDs an den 
RX-/TX-Leitungen sind. Dank Bit-Stuffing dürften die LEDs auch wenn 
nichts gesendet wird mit etwa 1/6 Helligkeit leuchten (zumindest fürs 
Auge). Ob sich dann noch

Josef Raschen schrieb:

> Um den OMAP4 zu schützen soll außerdem eine galvanische Trennung
> integriert werden. Die Trennung der Datenleitungen wollte ich mit einem
> ADUM1402 realisieren, die der Spannungsversorgung mit einem
> DC/DC-Wandler.

http://www.ti.com/ww/de/analog/iso1050/index.shtml?DCMP=hpa_intf_iso1050&HQS=Other+PR+iso1050-prde

fchk

Frank K. schrieb:
> Josef Raschen schrieb:
>
>> Um den OMAP4 zu schützen soll außerdem eine galvanische Trennung
>> integriert werden. Die Trennung der Datenleitungen wollte ich mit einem
>> ADUM1402 realisieren, die der Spannungsversorgung mit einem
>> DC/DC-Wandler.
>
> 
http://www.ti.com/ww/de/analog/iso1050/index.shtml?DCMP=hpa_intf_iso1050&HQS=Other+PR+iso1050-prde
>
> fchk

Danke für den Tipp. Damit lässt sich die Schaltung deutlich 
vereinfachen. Ich hoffe ich bekomme von TI 2 Stück davon als Sample, 
denn die allgemeine Lieferbarkeit scheint ja noch nicht so gut zu sein. 
Der einzige Grund warum der Transceiver offiziell nicht für für 
Automotive-Anwendungen gedacht ist, wird wohl der Temperaturbereich 
sein?

Josef Raschen schrieb:

> Der einzige Grund warum der Transceiver offiziell nicht für für
> Automotive-Anwendungen gedacht ist, wird wohl der Temperaturbereich
> sein?

Wahrscheinlich hat das Teil noch keine AEC100-Zertifizierung.

fchk

Da TI mir den ISO1050 möglicherweise Ende des Monats als Sample 
zuschickt habe ich die Schaltung etwas umgebaut. Sollte doch so 
funktionieren?

nowayback schrieb:
> Welchen DC-Wandler verwendest Du denn für die galvanische Trennung? Ich
> tendiere zu einem geregelten 2W-Traco-Wandler.

Ich überlege den AM1S-0505SZ einzusetzen da dieser bei Reichelt für 3,25 
Euro zu bekommen ist. Als bessere Alternativen hatte ich den DCP010505B 
(isoliert, nicht geregelt) oder den DCH010505S (isoliert, geregelt) von 
TI ins Auge gefasst. Die kosten jedoch so zwischen 10 und 15 Euro.


> Und wie verbindest du die Extension mit dem Pandaboard? Es gibt ja leider
> keine 28poligen Flachbandkonnektoren.

Ich werde einfach eine längere Buchsenleiste nehmen und diese etwas 
kürzen.

> Wäre schön wenn Du auch die eagle-files für die Erweiterung noch mit
> hochladen kannst.

Das kann ich gerne machen. Da unsere Schaltungen den gleichen Zweck 
haben können wir die daraus ja auch gleich ein Projekt machen und das 
ganze irgendwo auf einen svn-Server legen. Eventuell gibt es ja noch 
weitere Interessenten. Vielleicht lohnt es sich die Pandaboard 
Mailingliste einmal anzuschreiben.

Eventuell wollte ich auch noch einen Pegelwandler für UART und I2C sowie 
einen RS232 Transceiver hinzuzufügen um diese Schnittstellen auch nutzen 
zu können.

Josef Raschen schrieb:
> Ich überlege den AM1S-0505SZ einzusetzen da dieser bei Reichelt für 3,25
> Euro zu bekommen ist. Als bessere Alternativen hatte ich den DCP010505B
> (isoliert, nicht geregelt) oder den DCH010505S (isoliert, geregelt) von
> TI ins Auge gefasst. Die kosten jedoch so zwischen 10 und 15 Euro.

Sorry, kleiner Fehler: die sind beide nicht geregelt. Der DCR010505 (15 
Euro) ist geregelt. Das sind jeweils 1W Modelle. Da der ISO1050 laut 
Datenblatt maximal 73 mA zieht, sollten die 200 mA des Converters für 2 
Transceiver genügen.

nowayback schrieb:
> Hallo Josef,
>
> das SVN-Repository ist auf alle Fälle eine gute Idee. Ich muss zwar
> projektbedingt möglichst bald den Pandaboard-CAN-Adapter fertig stellen,
> aber auf dessen Grundlage könnten man anschließend auch weitere
> galvanisch getrennte Schnittstellen hinzufügen. Hast du einen
> SVN-Server/Mailingliste zur Verfügung?

Einen eigenen SVN-Server habe ich leider nicht zur Verfügung. Ich werde 
igendwann in den nächsten Tagen (hoffentlich noch diese Woche) ein 
Projekt bei Gitorious (also git und kein svn) aufsetzen und meine 
Dateien hochladen.

Aber zumindest den Schaltplan habe ich schonmal hier hochgeladen: 
http://www.raschen.org/Elektronik/omapcan/omapcan_iso1050.sch

Zuckerle schrieb im Beitrag #2247527:
> Also:
>
>  Der Terminator ist doch wohl Käse oder?
>  60R über 4n7 hängen immer an einer CAN-Leitung, damit
>  wirst du nicht glü+cklich.
>
>  Die Leds bringen auch nix. Sind ständig an und gehen
>  mit jedem Bit auf L. Was willst da den sehen?

Zunächst einmal vielen Dank für die Rückmeldung.

Für die Terminierung habe ich mich nur an die Empfehlung gehalten eine 
"Split Termination" (keine Ahnung wie die korrekte deutsche Bezeichnung 
ist) einzubauen. Sollte doch eigentlich so funktionieren? 
(http://ww1.microchip.com/downloads/en/AppNotes/00228a.pdf Seite 9-10)

Das Problem mit den LEDs hatte ich bereits erkannt und die LEDs an den 
RX0BF-Pin gehangen (siehe zweite Version des Schaltplans), dessen 
Zustand ich über SPI programmieren kann. Ich wollte mich aber noch 
einmal schlau machen, ob der Linux-Treiber des MCP2515 irgendetwas in 
der Richtung schon vorsieht und die Schaltung eventuell nochmal 
anpassen.

Bei Gitorious habe ich jetzt ein Projekt für die PandaBoard CAN-Bus 
Erweiterung erstellt: https://gitorious.org/pandaboard-can-expansion

Letzte Änderungen an der Schaltung:
- DC/DC Converter: Die günstige, ungeregelte Variante von Reichelt mit 
100nF Kondensatoren an Ein- und Ausgangsseite sowie einer Standardlast 
mit 300 Ohm.
- RS232 Interface mit TXS0102 für die Pegelwandlung von 1.8V auf 5V (und 
umgekehrt) sowie MAX3232 als Transceiver.

Sorry, die Softwareseite des Projektes habe ich mir noch nicht so genau 
angesehen. Ich war bisher davon ausgegangen, dass das Aktivieren der 
Treiber in der Kernel-Config genügt.

Ich hänge im Moment noch bei dem Layout des Boards fest. Um die 
Herstellungskosten gering zu halten versuche ich das Board auf einer 
zweiseitigen Platine mit je einem Layer pro Seite zu realisieren. Statt 
echten Durchkontaktierungen werden nur manuelle Lötverbindungen genutzt. 
Das hat sich aber als gar nicht so einfach erwiesen. Den letzten Stand 
habe einmal angehängt. Ich weiß nicht ob das so klug ist, aber ich 
versuche die Versorgungsleitungen (1.8V, 5V, GND) auf dem Bottom-Layer 
zu verlegen und die Signalleitungen auf dem Top-Layer, um mit den 
SPI-Signalen nicht das Layer wechseln zu müssen.
Stellt das eigentlich ein Problem für die SPI-Signale dar, wenn die 
Länge der Leitungen um wenige cm variiert? Der Einfluss auf die 
Signallaufzeit sollte doch bei 10 MHz (was wohl ca. 20 m Wellenlänge in 
Kupfer entspricht, sofern ich mich da jetzt nicht verrechnet habe) 
vernachlässigbar sein?

nowayback schrieb:
> Hallo Josef,
>
> hast du schon den CAN-Controller erfolgreich mit Linux auf dem
> Pandaboard anbinden können?
> Ich habe sowohl SPI und MCP2515-Support im Kernel aktiviert und die
> board-Datei um die SPI und MCP2515-Routinen erweitert. Jedoch schlägt
> das Kompilieren des Kernels fehl, weil Attribute wie ".model" im SPI
> struct nicht bekannt sind.
> Bisher fehlt mir das Wissen um Linux, deswegen habe ich die board-Datei
> nur anhand von Anleitungen umschreiben können
> 
(https://www.ridgerun.com/developer/wiki/index.php/How_to_configure_and_use_CAN_bus),
> womit ich bisher aber keinen Erfolg hatte. Wie bist du vorgegangen? Bin
> für Ratschläge sehr dankbar :)
> Meine bisherige board-Datei (/usr/src/linux/arm/mach-omap2/) habe ich in
> der Anlage beigefügt.

Hier gibt es eine Erweiterung für ein OMAP3-Board, welches ebenfalls den 
MCP2515 nutzt:
http://labs.igep.es/index.php/Category:IGEP0022
Da gibt es auch einen modifizierten Kernel, mit dem das Board 
funktionieren müsste:
http://git.igep.es/?p=pub/scm/linux-omap-2.6.git;a=summary
Hier sind noch ein paar Hinweise zu dem Kernel und dem Board zu finden:
http://labs.igep.es/index.php/Linux_Kernel_2.6.35.y

Vielleicht lässt sich da herausfinden, was zu tun ist, um den MCP2515 
ans Laufen zu bekommen.

Hi,

Josef Raschen schrieb:
> Hier gibt es eine Erweiterung für ein OMAP3-Board, welches ebenfalls den
> MCP2515 nutzt:
> http://labs.igep.es/index.php/Category:IGEP0022
> Da gibt es auch einen modifizierten Kernel, mit dem das Board
> funktionieren müsste:
> http://git.igep.es/?p=pub/scm/linux-omap-2.6.git;a=summary
> Hier sind noch ein paar Hinweise zu dem Kernel und dem Board zu finden:
> http://labs.igep.es/index.php/Linux_Kernel_2.6.35.y
>
> Vielleicht lässt sich da herausfinden, was zu tun ist, um den MCP2515
> ans Laufen zu bekommen.

Bei konkreten Fragen, zu dem mpc251x SocketCAN treiber hilft sicher auch 
die passende Liste weiter: linux-can@vger.kernel.org

Bei Problemen beim Kompilieren, einfach mal den letzten Stand aus dem 
SocketCAN Respository probieren:

http://svn.berlios.de/svnroot/repos/socketcan/trunk

und auftretende Fehler ggf. posten.

Achtung: Das Repository wird demnaechst umgezogen.

Wie ist der Stand des unter

https://gitorious.org/pandaboard-can-expansion

eingecheckten Boards? Ich komme eher von der Softwareseite und kann die 
Schaltung nicht beurteilen. Funktioniert das Board soweit, dass man es 
nachbauen kann, oder sind noch Aenderungen notwendig?

Danke und Gruss,

Felix

Felix O. schrieb:
> Wie ist der Stand des unter
>
> https://gitorious.org/pandaboard-can-expansion
>
> eingecheckten Boards? Ich komme eher von der Softwareseite und kann die
> Schaltung nicht beurteilen. Funktioniert das Board soweit, dass man es
> nachbauen kann, oder sind noch Aenderungen notwendig?

Danke für die Rückmeldung.

Da ich im Moment in den letzten Wochen meiner Diplomarbeit bin, hat sich 
an dem Board zuletzt nicht mehr viel getan. Fertig ist es also leider 
noch nicht. Ich hatte das Layout auch nochmals völlig ändern müssen. Die 
Erweiterungsplatine soll jetzt unter das Pandaboard. Dadurch habe ich 
mehr Platz. Mit der bisherigen Lösung würde ich mit einer zweiseitigen 
Platine wahrscheinlich nicht auskommen. Und eine Multilayer Platine 
würde mein Budget sprengen (zumal die die Gratis-Version von Eagle, die 
ich verwende, dies nicht unterstützt).

flavy schrieb:
> Meine Frage ist, ob es einen technischen Grund gibt warum der MCP2551
> und der ADUM1402 durch den ISO1050 ersetzt wurde oder ob Bauteile
> gespart werden sollten. Hier geht es mir vor allem um die
> Beschaffungsmöglichkeit via Reichelt.

Der Grund war tatsächlich die Vereinfachung der Schaltung (und die 
Tatsache, dass TI so nett war mir kostenlose Muster zu schicken). Der 
ISO1050 ist aber mittlerweile für 5 Euro auch bei hbe-shop.de zu 
bekommen.

> Zweite Frage: Für was ist der AT24C01 vorgesehen? Ist dieser für den CAN
> Betrieb notwendig?

Das EEPROM wird genutzt um das Board per Software identifizieren zu 
können, ist aber für prinzipiell nicht notwendig. Das wird aber für 
BeagleBoard/PandaBoard Erweiterungen so empfohlen: 
http://elinux.org/BeagleBoardPinMux#Expansion_boards

> Wenn im Schaltplan jetzt nichts mehr fehlt, würde ich auf dieser Basis
> ein Board für mich entwerfen.

Dass der Schaltplan funktioniert kann ich leider noch nicht garantieren, 
da ich meinen Prototypen noch nicht gebaut habe. In den letzten Tagen 
habe ich das Board-Layout noch ein wenig überarbeitet und werde als 
nächstes mit einem 1:1 Ausdruck die mechanische Kompatibilität zum 
PandaBoard noch einmal überprüfen. Danach lasse ich die Platine 
fertigen. Ich hoffe nur, dass ich dann nicht am Löten der SMD-Teile 
scheitere.

Die aktuelle Version von Schaltplan und Board gibt es in meinem 
Gitorious-Projekt: 
http://gitorious.org/pandaboard-can-expansion/pandaboard-can-expansion/trees/master/board

Grüße
Josef

flavy schrieb:
> Müssen die beiden Controller synchron laufen oder ist dies auch auf eine
> Vereinfachung zurückzuführen. Ich würde gerne aus Modularitätsgründen
> die beiden Takte getrennt generieren, deshalb wollte ich nachfragen ob
> dem technisch etwas im Weg steht.


Ich habe das aus Platzgründen gemacht. Für eine separate Takterzeugung 
jedes Controllers sehe ich eigentlich keine Hindernisse.

Mein Board ist übrigens mittlerweile so weit, dass es zum PCB-Fertiger 
gehen kann (siehe Anhang). Ich hoffe nur, dass ich alle Fehler gefunden 
habe, und keinen teuren Elektro-Schrott produziere.

flavy schrieb:

> Bei den Abschlusswiderständen ist mir aufgefallen, dass es keine 60Ohm
> Widerstände (E12 E24) gibt.

Aber 62er. Übertreib es dabei nicht, deine Verkabelung wird auch keinen 
auf 1% genauen Wellenwiderstand haben.

Ausserdem ist der C inmitten der beiden 60er nicht unbedingt zwingend. 
Erst recht nicht, wenn dessen GND möglicherweise Schmutz einkoppelt.

59 Ohm Widerstände mit 1% Toleranz müssten es eigentlich auch tun. Aber 
du hast schon recht, über dieses Detail hatte ich nicht nachgedacht. 
Alternativ kannst du statt den beiden Widerständen einfach einen mit 120 
Ohm nehmen und den Kondensator weglassen. Wenn ich ein Oszilloskop hätte 
würde ich mit den verschiedenen Varianten dann einmal experimentieren. 
Der Einfluss auf das Signal würde mich schon einmal interessieren.

Die Kondensatoren am DC/DC-Wandler könnten tatsächlich etwas größer 
gewählt werden. Aber man kann ja mittlerweile problemlos auch 0805er 
Kondensatoren mit mehreren µA bekommen, so dass ich da nichts mehr 
ändern brauche und nur etwas anderes Auflöten.

Vielen Dank für die Hinweise.

Ein kurzes Statusupdate:

Das PCB ist gefertigt worden und schaut gut aus. Bei einem Bauteil (IC9) 
fehlte in meinem brd-File noch das Lötstopplayer. Der aufmerksame 
Mitarbeiter von M&V Leiterplatten hatte das aber noch rechtzeitig 
bemerkt und nach Rücksprache behoben. Im git-Repository werde ich die 
Änderung auch noch einpflegen.

Ich kaufe im Moment die letzten Bauteile zusammen und werde hoffentlich 
nächsten Samstag mit dem Löten beginnen.

Josef Raschen schrieb:

> Ich kaufe im Moment die letzten Bauteile zusammen und werde hoffentlich
> nächsten Samstag mit dem Löten beginnen.

Ich mache es immer umgekehrt - zuerst die Bauteile beschaffen, dann noch 
einmal die Footprints überprüfen, und dann erst das Layout rausgeben.
Schlechte Erfahrungen...

fchk

Wenn Du das SPI nicht schneller bekommst, ersetze doch den MCP2515 durch 
einen PIC18F26K80 (8 Bit) oder PIC24HJ128GP502 (16 Bit) (beides 
28-Pinner). Das ist im Prinzip der gleiche CAN-Controller, nur noch mit 
einem PIC mit drin. Mit dem kannst Du dann einen Ringpuffer 
implementieren, so dass der PIC die empfangenen Pakete in seinem RAM 
puffert, von wo Du sie aus abholen kannst. Die SPI-Kommunikation kannst 
Du ja so gestalten, dass Du möglichst wenig im Linux-Treiber ändern 
musst.

fchk