Hallo zusammen, Zur Zeit versuche ich für das Pandaboard (TI OMAP4430) eine kleine Erweiterungsplatine für zwei CAN-Bus Schnittstellen zu entwerfen. Aufgrund der Verfügbarkeit eines Linux-Treibers habe ich als Controller den MCP2515 ausgewählt. Dieser wird per SPI an den OMAP4 angebunden. Als Transceiver wollte ich den MCP2551 einsetzen. 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. Ich würde mich freuen, wenn hier im Forum einer oder mehrere erfahrene Bastler/Profis/Profi-Bastler einen Blick auf die Schaltung werfen könnten, bevor ich mich an das Platinenlayout mache. Bei der Auswahl des DC/DC-Wandlers bin ich mir außerdem noch nicht sicher welches Modell ich da nehmen soll. Ich hatte den AM1S-0505SZ (siehe http://www.reichelt.de/Wandler-Module-DC-DC/SIM1-0505-SIL4/index.html?ACTION=3&GROUPID=4956&ARTICLE=35024&SHOW=1&START=0&OFFSET=500&;PROVID=2402) in Auge gefasst. Ich bin mir jedoch nicht sicher, ob dieser Wandler geeignet ist. Vielleicht kann mir jemand ein besseres Bauteil nennen, das nicht viel mehr als 5 Euro kostet und zumindest bei Farnell lieferbar ist. Danke schonmal, Josef
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?
Hallo Josef, auch ich entwickle gerade eine CAN-Erweiterung für das Pandaboard auf Grundlage des MCP2515 und ISO1050. Dein Schaltplan sieht für mich stimmig aus. Zumindest mein Schaltplan ist Deinem ganz ähnlich aufgebaut (bis auf den CAN-Connector und dass ich nur einen CAN-Bus implementiere). Welchen DC-Wandler verwendest Du denn für die galvanische Trennung? Ich tendiere zu einem geregelten 2W-Traco-Wandler. Und wie verbindest du die Extension mit dem Pandaboard? Es gibt ja leider keine 28poligen Flachbandkonnektoren. Wäre schön wenn Du auch die eagle-files für die Erweiterung noch mit hochladen kannst. Ansonsten gutes Gelingen!
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.
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?
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.
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.
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).
Hallo, ich bin auf der Suche nach einem CAN Board, dass ich an ein PandaBoard anschließen, aber auch mal mit anderen µCs verwenden kann. Dadurch bin ich hier gelandet. 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. Zweite Frage: Für was ist der AT24C01 vorgesehen? Ist dieser für den CAN Betrieb notwendig? Wenn im Schaltplan jetzt nichts mehr fehlt, würde ich auf dieser Basis ein Board für mich entwerfen. Viele Grüße flavy
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
Hi ich bins nochmal, ich hätte noch eine Frage zur Beschaltung des MCP2515. Es geht um den Clock der beiden CAN Controller. Der wird in deinem Schaltplan einmal erzeugt und für beide Controller verwendet. 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. Leider findet man zu Dual-Schaltungen sehr wenig Informationen. Dennoch viele Grüße und ein schönes Wochenende flavy
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.
Hi Josef, mir sind noch ein paar Sachen aufgefallen bei deinem Schaltplan, vielleicht sind die für dich interessant bevor du die Platine fertigen lässt. Bei den Abschlusswiderständen ist mir aufgefallen, dass es keine 60Ohm Widerstände (E12 E24) gibt. Mir fallen da zwei Möglichkeiten ein um dieses Problem zu lösen. Entweder man kauft einen Haufen 5%tige 62Ohm Widerstände misst diese aus oder man schaltet zwei 120Ohm Widerstände parallel (hab ich so in meinem Schaltplan gemacht). Und das Andere was mir aufgefallen ist, ist die Beschaltung des DCDC Wandlers das Datenblatt schlägt 4.7µF am Vin und 10µF am Vout vor um den Ripple zu reduzieren. Eher eine Schönheitsentscheidung ;-) Ansonsten ist mir nix weiter aufgefallen und ich hab den Schaltplan bis auf die angesprochenen Punkte 1:1 übernommen. Viele Grüße flavy
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
Hallo zusammen, ich habe es vor einigen Monaten erfolgreich geschafft, meinen CAN-Adapter mit dem Pandaboard zu verbinden. Leider habe ich diesen Thread aus den Augen verloren, möchte aber noch von meinen Ergebnissen erzählen - vielleicht helfen sie euch weiter. Nachdem ich meinen CAN-Adapter (mit nur einem Controller) ätzen liess, habe ich versucht den Kernel zu konfigurieren. Das habe ich mit den Links, die ich oben bereits erwähnt habe, einigermaßen gut durchführen kann. Nervig war, dass bei meinem gentoo-Pandaboard-Kernel nicht einmal die SPI-Konfiguration/Initialisierung enthalten war. Also habe ich neben CAN auch noch ein paar Zeilen für SPI in die omap4panda.c schreiben müssen. Ich habe keine Patches verwendet sondern die Änderungen direkt in die Kernel-Sources geschrieben, das ist natürlich keine schöne, aber durchaus funktionierende Lösung. Im Anschluss habe ich auch softwareseitig die ip-Tools installiert. Ich hatte dann noch länger das Problem, dass ip dann nicht das Timing berechnen konnte, obwohl ich den Support dafür explizit im Kernel aktiviert habe. Letztendlich hat sich einfach der Compiler an den kernel-Änderungen verschluckt, ein "make clean" half weiter. Mithilfe der SocketCAN-Tools konnte ich dann letztendlich super auf die CAN-Schnittstelle zugreifen und das komplette System funktioniert seit Monaten einwandfrei, bis auf eine nervige Ausnahme: Die SPI-Geschwindigkeit des OMAP-Prozessors lässt sich nur auf Zweierpotenzen von 48 MHz teilen. Da der MCP2515 nur 10 MHz unterstützt, kann man also nur 6 MHz verwenden. Diese reichen aber leider nicht, um den CAN-Bus auf 1 MHz zu betreiben: wenn mehrere Pakete direkt nacheinander (ab 4 Stück) eintreffen, kommt das Pandaboard mit dem Auslesen des MCPs nicht mehr nach, der MCP-Puffer überläuft und lässt Pakete aus. Das kommt vor allem daher, weil der SocketCAN-Treiber stets vorher noch das Statusbyte auslesen muss um zu erfahren in welchem Puffer das Paket liegt (die RX-Interrupt-Leitungen werden ja leider meines Wissens nicht unterstützt). Unterm Strich kann man mit dem Pandaboard keine 1MHz fahren, es sei denn - die Anwendung toleriert verlorene Pakete - Bursts, dh. mehrere Pakete direkt nacheinander, sind ausgeschlossen - man übertaktet die SPI-Geschwindigkeit auf 12 MHz. Mit dem letzteren Punkt habe ich mich noch nicht beschäftigt. Ich könnte mir gut vorstellen dass der MCP auch diese Geschwindigkeit noch tolerieren könnte, aber letztlich kommt das auf die internen Timings an. Ich habe keine Experimente diesbezüglich gemacht. In meiner Anwendung treten nur gelegentlich Bursts auf, und diese Bursts sind nicht kritisch. Leider kann man natürlich nicht ausschließen, dass auch kritische Pakete in Bursts verloren gehen - ich suche noch nach einer Lösung.
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
Hallo nowayback Könntest du mir vielleicht den Gefallen tun, dein omap4panda.c file zu posten. Ich bin auch daran den Linux Kernel zu konfigurieren und bei mir ist die SPI Schnittstelle auch nicht konfiguriert. Besten Dank Andreas Ziegler
Leider hatte ich erst letzte Woche wieder Zugriff auf das Pandaboard, und kann dir daher erst jetzt antworten. Du findest meine provisorische, aber voll funktionstüchtige Version der omap4panda.c im Anhang. Ich kenne leider nicht mehr alle Stellen, die ich manuell geändert habe, aber ein diff hilft im Zweifelsfall sicher weiter :) Viel Erfolg damit!
Bitte 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.