Hallo, ich habe seit kurzem ein Problem mit dem senden/empfangen von CAN Nachrichten mittels RaspebrryPi und MCP2515. Es lief wochenlang reibungslos, seit kurzem tritt folgender Fehler (nicht immer aber oft) auf: RPi bootet Oszi: CS PIN-Pegel --_-------- sudo ip link set up can0 type can bitrate 500000 Oszi: CS PIN-Pegel --_-_-_---- 1. cansend: xyz Oszi: CS PIN-Pegel --_-_-_---- 2. cansend: xyz Oszi: CS PIN-Pegel -------- d.h.: nach dem die erste Nachricht an den MCP raus ging (aber nicht auf dem CAN Bus gelangt!) und ich ein weiteres mal eine Nachricht senden möchte, bleibt CS komplett auf High. Es kommt mir so vor, als würde der MCP2515 nach der ersten Nachricht an meinen Pi etwas senden, sodass dieser die Arbeit einstellt und den MCP nicht mehr anspricht. Sind solche "Befehle" vom MCP2515 möglich? Was kann ihn dazu bewegen dies zu tun? mfg
Der MCP2515 sendet nichts an den PI, zumindest nicht von sich aus. Was meinst du mit erster Nachricht? Ein Byte über SPI oder eine CAN-Nachricht? Wenn die CAN-Nachricht nicht abgesetzt werden kann, blockiert der MCP2515 den Buffer soweit ich weiß. Vielleicht passiert ja das bei dir. Wobei dann der PI trotzdem am CS wackeln müsste. Hm...
Mit Nachricht meine ich ein Byte über SPI. Auf den CanBus gelangt nie ein Frame. Der Pi scheint beim ersten Sendeversuch den MCP anzusprechen, da CS wackelt, und bei allen weiteren Versuchen wackelt nix mehr an CS.
was sagt denn 'dmesg' und 'ip -s -d link show can0' ?
>d.h.: nach dem die erste Nachricht an den MCP raus ging (aber nicht auf >dem CAN Bus gelangt!) und ich ein weiteres mal eine Nachricht senden >möchte, bleibt CS komplett auf High. Das CS High bleibt liegt nicht am MCP2515. CS ist ein Eingang und den kann der MCP nicht selbstständig auf High legen. Dein Problem liegt in der Software die den MCP ansteuert.
holger schrieb: > Das CS High bleibt liegt nicht am MCP2515. > CS ist ein Eingang und den kann der MCP nicht > selbstständig auf High legen. Dein Problem liegt > in der Software die den MCP ansteuert. Ja das dachte ich mir auch schon. Komisch ist nur, dass der RPi beim ersten Versuch die CS Leitung auf Low ziehen kann. Anschließend aber nie wieder. Wenn ich eine andere Schaltung an den RPi hänge (andere Schaltung aber identische CAN Hardware und Verschaltung), dann funktioniert das Programm. Ich denke also, dass meine Hardware irgend einen Fehler am MCP verursacht, und dieser beim ersten Kontakt mit dem Pi mitteilt: "defekt" und der Pi ihn dann gar nicht mehr versucht anzusprechen. Gerd B. schrieb: > was sagt denn 'dmesg' und 'ip -s -d link show can0' ? Hab ich jetzt nicht im Kopf, ich probiere es heut Nachmittag aus und Poste das Ergebnis.
> Ich denke also, dass meine Hardware irgend einen Fehler am MCP > verursacht, und dieser beim ersten Kontakt mit dem Pi mitteilt: "defekt" > und der Pi ihn dann gar nicht mehr versucht anzusprechen Ist das möglich? Was kann den MCP2515 dazu bewegen sich so zu verhalten?
Kommt auf deine Routinen für den MCP2515 an. Eventuell meldet der MCP2515 ein BUSOFF und deine Routinen auf dem Pi merken sich das und versuchen es nichtmal mehr :-)
Okay - warum könnte der MCP einen Busoff melden? Im Pi nutze ich dieses Socket CAN, da kann man irgendwie schwer nachvollziehen was gemacht wird. Wie kann ich diesen Busstatus anzeigen lassen?
Ich sende übrigens mit einem CAN Case nachrichten an den MCP, dieser meldet natürlich ERROR: Fehler im Ack-Slot. D.h. der MCP schreibt kein Ack in den Ack-Slot. Das müsste er doch, unabhängig vom Abholen der Nachrichten durch den Pi, trotzdem immer machen, oder?
Hm... aber der ACK-Slot ist doch im CAN-Frame, ich dachte soweit kommt es gar nicht? Es hängt doch schon an der Kommunikation mit dem MCP?! Unterstützt dein CAN-Socket überhaupt den mcp?
> Hm... aber der ACK-Slot ist doch im CAN-Frame, ich dachte soweit > kommt es gar nicht? Ich kann ja mit dem CAN Case an die Schaltung senden. Das CAN Case merkt dann, dass kein Bus Teilnehmer in den Ack-Slot schreibt. > Es hängt doch schon an der Kommunikation mit dem MCP?! Die wird allem Anschein nach eingestellt, nach dem ersten Sendeversuch. > Unterstützt dein CAN-Socket überhaupt den mcp? Ja und es lief bereits Wochenlang und auch mit einer anderen Schaltung auf der der MCP sitzt.
Hm... achso ich wusste nicht was ein CAN Case ist. Hast du schonmal versucht den MCP zu tauschen?
tugtug schrieb: > Okay - warum könnte der MCP einen Busoff melden? > > Im Pi nutze ich dieses Socket CAN, da kann man irgendwie schwer > nachvollziehen was gemacht wird. Wie kann ich diesen Busstatus anzeigen > lassen? root@raspberrypi ~ # ip -s -d link show can0 3: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT qlen 10 link/can can state ERROR-ACTIVE restart-ms 0 bitrate 250000 sample-point 0.875 tq 250 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1 mcp251x: tseg1 3..16 tseg2 2..8 sjw 1..4 brp 1..64 brp-inc 1 clock 8000000 re-started bus-errors arbit-lost error-warn error-pass bus-off 0 0 0 0 0 0 RX: bytes packets errors dropped overrun mcast 0 0 0 0 0 0 TX: bytes packets errors dropped carrier collsns 0 0 0 0 0 0 Destewegen bitte "dmesg; ip -s -d link show can0". Für das Handling der Schnittstelle: Schau Dir mal libsocketcan an. Gruß Gerd
BTW: https://www.kernel.org/doc/Documentation/networking/can.txt 6.5.3 Starting and stopping the CAN network device A CAN network device is started or stopped as usual with the command "ifconfig canX up/down" or "ip link set canX up/down". Be aware that you must define proper bit-timing parameters for real CAN devices before you can start it to avoid error-prone default settings: $ ip link set canX up type can bitrate 125000 A device may enter the "bus-off" state if too much errors occurred on the CAN bus. Then no more messages are received or sent. An automatic bus-off recovery can be enabled by setting the "restart-ms" to a non-zero value, e.g.: $ ip link set canX type can restart-ms 100 Alternatively, the application may realize the "bus-off" condition by monitoring CAN error message frames and do a restart when appropriate with the command: $ ip link set canX type can restart Note that a restart will also create a CAN error message frame (see also chapter 3.4).
> ip -s -d link show can0
Schaltung welche nicht funktioniert:
4: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN
mode DEFAULT qlen 10
link/can
can state STOPPED restart-ms 0
bitrate 500000 sample-point 0.875
tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
mcp2515: tseg1 2..16 tseg2 2..8 sjw 1..4 brp 1..64 brp-inc 1
clock 8000000
re-started bus-errors arbit-lost error-warn error-pass bus-off
0 0 0 0 0 0
RX: bytes packets errors dropped overrun mcast
0 0 0 0 0 0
TX: bytes packets errors dropped carrier collsns
0 0 0 0 0 0
andere Schaltung,welche funktioniert:
4: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN
mode DEFAULT qlen 10
link/can
can state STOPPED restart-ms 0
bitrate 500000 sample-point 0.875
tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
mcp2515: tseg1 2..16 tseg2 2..8 sjw 1..4 brp 1..64 brp-inc 1
clock 8000000
re-started bus-errors arbit-lost error-warn error-pass bus-off
0 0 0 0 0 0
RX: bytes packets errors dropped overrun mcast
488 61 0 0 0 0
TX: bytes packets errors dropped carrier collsns
0 0 0 0 0 0
Beide male "can state STOPPED" - egal ob es funktioniert oder nicht. :/
~ $ ip link set can0 up RTNETLINK answers: Operation not permitted ~ $ ip -s -d link show can0 can state STOPPED restart-ms 0 Es zeigt keine Wirkung. Trotzdem arbeitet es!?
~ $ sudo ip link set can0 up ~ $ ip -s -d link show can0 can state STOPPED restart-ms 0 hatte sudo vergessen, geht aber dennoch nicht
Versuch mal : sudo ifconfig can0 up Eine Frage noch: Welche Raspbian und spi-bcm2708 bzw. mcp251x Version benutzt Du? Was passiert, wenn Du das Interface mit der Option 'restart-ms 100' konfigurierts ? Gib bitte mal auch den Auszug von 'dmesg | egrep -i "spi|can|mcp"' und 'cat /proc/interrupts'.
:
Bearbeitet durch User
sudo ip link set up can0 type can bitrate 500000 can state STOPPED restart-ms 0 > Welche Raspbian und spi-bcm2708 bzw. mcp251x Version benutzt Du? Wie finde ich das heraus? > dmesg | egrep -i "spi|can|mcp" BCM2708 mcp251x_init: got IRQ 195 for MCP2515 bcm2708_spi bcm2708_spi.0: master is unqueued, this is deprecated bcm2708_spi bcm2708_spi.0: SPI Controller at 0x20204000 (irq 80) can: controller area network core (rev 20120528 abi 9) CAN device driver interface can: raw protocol (rev 20120528) can: broadcast manager protocol (rev 20120528 t) mcp2515 spi0.0: can0: device registered (cs=0, irq=195) mcp2515 spi0.0: can0: bit-timing not yet defined mcp2515 spi0.0: can0: bit-timing not yet defined mcp2515 spi0.0: can0: bit-timing not yet defined . . viele male . mcp2515 spi0.0: can0: bit-timing not yet defined mcp2515 spi0.0: can0: bit-timing not yet defined mcp2515 spi0.0: can0: writing CNF: 0x00 0xb5 0x01 > cat /proc/interrupts CPU0 3: 35616 ARMCTRL BCM2708 Timer Tick 32: 1113668 ARMCTRL dwc_otg, dwc_otg_pcd, dwc_otg_hcd:usb1 52: 0 ARMCTRL BCM2708 GPIO catchall handler 65: 2 ARMCTRL ARM Mailbox IRQ 66: 1 ARMCTRL VCHIQ doorbell 75: 1 ARMCTRL 77: 14504 ARMCTRL bcm2708_sdhci (dma) 79: 0 ARMCTRL bcm2708_i2c.0, bcm2708_i2c.1 80: 716 ARMCTRL bcm2708_spi.0 83: 420 ARMCTRL uart-pl011 84: 19112 ARMCTRL mmc0 195: 0 GPIO can0 FIQ: usb_fiq Err: 0 > sudo ip link set can0 type can restart-ms 100 sudo: unable to resolve host pi RTNETLINK answers: Device or resource busy
tugtug schrieb: > sudo ip link set up can0 type can bitrate 500000 > can state STOPPED restart-ms 0 > Ist Der Status immer noch STOPPED wenn Du vorher 'ifconfig can0 up' gemacht hast ? >> Welche Raspbian und spi-bcm2708 bzw. mcp251x Version benutzt Du? > Wie finde ich das heraus? uname -a zcat /usr/share/doc/raspberrypi-bootloader/changelog.Debian.gz | tail -10 Woher stammt das mcp251x Modul ? Das ist nicht im Standardumfang von Raspbian ... > >> dmesg | egrep -i "spi|can|mcp" > BCM2708 mcp251x_init: got IRQ 195 for MCP2515 > bcm2708_spi bcm2708_spi.0: master is unqueued, this is deprecated > bcm2708_spi bcm2708_spi.0: SPI Controller at 0x20204000 (irq 80) > can: controller area network core (rev 20120528 abi 9) > CAN device driver interface > can: raw protocol (rev 20120528) > can: broadcast manager protocol (rev 20120528 t) > mcp2515 spi0.0: can0: device registered (cs=0, irq=195) > mcp2515 spi0.0: can0: bit-timing not yet defined > mcp2515 spi0.0: can0: bit-timing not yet defined > mcp2515 spi0.0: can0: bit-timing not yet defined > . > . viele male > . > mcp2515 spi0.0: can0: bit-timing not yet defined > mcp2515 spi0.0: can0: bit-timing not yet defined > mcp2515 spi0.0: can0: writing CNF: 0x00 0xb5 0x01 Das sieht soweit normal aus. > >> cat /proc/interrupts > CPU0 > 3: 35616 ARMCTRL BCM2708 Timer Tick > 32: 1113668 ARMCTRL dwc_otg, dwc_otg_pcd, dwc_otg_hcd:usb1 > 52: 0 ARMCTRL BCM2708 GPIO catchall handler > 65: 2 ARMCTRL ARM Mailbox IRQ > 66: 1 ARMCTRL VCHIQ doorbell > 75: 1 ARMCTRL > 77: 14504 ARMCTRL bcm2708_sdhci (dma) > 79: 0 ARMCTRL bcm2708_i2c.0, bcm2708_i2c.1 > 80: 716 ARMCTRL bcm2708_spi.0 > 83: 420 ARMCTRL uart-pl011 > 84: 19112 ARMCTRL mmc0 > 195: 0 GPIO can0 > FIQ: usb_fiq > Err: 0 Merkwürdig: IRQ 195 ist 0, obwohl 716 SPI IRQs aufgelaufen sind. Sendest Du mit diesem nur ? Ist die Verbindung zwischen /INT vom MCP2515 und GPIO25 vom RPi in Ordnung ? Welcher Pull-Up Widerstand wird verwendet (Schaltplan) ? > >> sudo ip link set can0 type can restart-ms 100 > sudo: unable to resolve host pi > RTNETLINK answers: Device or resource busy Du must vorher das Interface mittels 'ifconfig can0 down' runterfahren, und nach Einstellung wieder 'ifconfig can0 up' machen. Noch eine Frage: Woher stammt die CAN-Modul Hardware ? Ist es Eigenbau (Schaltplan) ? Nebenbei: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=44&t=7027&start=284 gibt ein paar wertvolle Tipps.
Linux pi 3.6.11-cutdown+ #2 PREEMPT Fri Jul 19 15:31:49 CEST 2013 armv6l GNU/Linux * firmware as of 1178c4db5 -- Alex Bradbury <asb@asbradbury.org> Thu, 14 Jun 2012 14:37:56 +0100 raspberrypi-firmware (1.0-1) unstable; urgency=low * Initial release of Debian packaging for the Raspberry Pi "firmware". * Based on upstream commit caf963d. -- Will Thompson <will.thompson@collabora.co.uk> Thu, 24 May 2012 12:20:30 +0100 > Woher stammt das mcp251x Modul ? Das ist nicht im Standardumfang von > Raspbian http://elinux.org/RPi_CANBus > Ist Der Status immer noch STOPPED wenn Du vorher 'ifconfig can0 up' > gemacht hast ? 'ifconfig can0 up/down' hat absolut keine Auswirkungen. Es steht immer da: can state STOPPED restart-ms 0 (auch wenn ich eine Funktionierende Schaltung nutze und den CAN Bus mit dem Pi nutzen kann) > Sendest Du mit diesem nur ? Wie meinst du das? > Ist die Verbindung zwischen /INT vom MCP2515 und GPIO25 vom RPi in Ordnung ? Durchgangsprüfer sagt ja. > Welcher Pull-Up Widerstand wird verwendet > (Schaltplan) ? 10k Schaltplan wurde schon oft verwendet und sollte stimmen. Hab das alles die letzten Tage schon 100 mal durchgeschaut :(
Angehängte Dateien:
-
Schaltung.png
6,3 KB
> Du must vorher das Interface mittels 'ifconfig can0 down' runterfahren, Glaub das Herunterfahren funktioniert nicht. > und nach Einstellung wieder 'ifconfig can0 up' machen. ~ $ sudo ifconfig can0 down sudo: unable to resolve host pi ~ $ sudo ip link set can0 type can restart-ms 100 sudo: unable to resolve host pi RTNETLINK answers: Device or resource busy > Noch eine Frage: Woher stammt die CAN-Modul Hardware ? okay - Schaltplan hängt an.
weiß nicht ob es bewusst geworden ist: Pi_System_1 an Can-Hardware_1 : o.g. Probleme Pi_System_1 an Can-Hardware_2 : keine Probleme => der MCP2515 von Can-Hardware_1 scheint also das Problem zu sein und ich will herausfinden woran es liegt.
tugtug schrieb: > $ sudo ifconfig can0 down > sudo: unable to resolve host pi Das irritiert. Siehe: http://www.wiefunztdas.com/2011/10/25/losung-fur-»sudo-unable-to-resolve-host-dein-computer«/ tugtug schrieb: > $ sudo ip link set can0 type can restart-ms 100 > sudo: unable to resolve host pi > RTNETLINK answers: Device or resource busy Dann musst Du das Modul einmal entladen und wieder laden. Bitrate nicht vergessen. Könntest Du ggf. auf die neue Raspbian schwenken und http://lnxpps.de/rpie/rpi_can_3611_spi_dma.tar.xz verwenden ?
tugtug schrieb: > weiß nicht ob es bewusst geworden ist: > > Pi_System_1 an Can-Hardware_1 : o.g. Probleme > > Pi_System_1 an Can-Hardware_2 : keine Probleme > > => der MCP2515 von Can-Hardware_1 scheint also das Problem zu sein und > ich will herausfinden woran es liegt. In der Schaltung finde ich 3k3 Ohm für MCP2551 RS merkwürdig bei 500k. Sollte RS nicht mit GND verbunden werden ?
:
Bearbeitet durch User
> In der Schaltung finde ich 3k3 Ohm für MCP2551 RS merkwürdig bei 500k. > Sollte RS nicht mit GND verbunden werden ? 500k ? Über RS wird die Flankensteilheit der Frames eingestellt. 3,3k sind i.O. > Dann musst Du das Modul einmal entladen und wieder laden. > Bitrate nicht vergessen. Wie genau mach ich das?
Es muss doch an der Hardware liegen, oder? Gleiches System funktioniert an einem anderen MCP reibungslos. Ist es möglich das der MCP irgend ein Problem hat und das an den Pi sendet, sodass er die Arbeit einstellt? Es ist zum verzweifeln...
tugtug schrieb: > Es muss doch an der Hardware liegen, oder? > Gleiches System funktioniert an einem anderen MCP reibungslos. Ja, aber normalerweise kann man anhand der Meldungen vom Linux Rechner auf die Ursache schließen. Bei Dir scheint einiges im Argen zu sein: - sudo Meldung (ist nicht die Ursache Deines Problems) - STOPPED - trotzdem kannst Du CAN Frames empfangen ? - ifconfig can0 up ändert nix - GPIO IRQ zählt nicht hoch > > Ist es möglich das der MCP irgend ein Problem hat und das an den Pi > sendet, sodass er die Arbeit einstellt? > Jein, der MCP2515 ist eher passiv: Er signalisiert über /INT eine Anforderung - der Host sendet ein SPI Sequenz zum Lesen/Schreiben Ich vermute eher ein Problem beim Tranceiver. Bei einem ähnlichen Fall (STOPPED) lag es an einer fehlerhaften Beschaltung des Tranceivers. BTW: Der Spannungsteiler für den Angleich zwischen Controller und Tranceiver ist IMO nicht in Ordnung - die Widerstände sind zu hoch (1k/1k8 wäre besser). BTW: Die Schaltung kommt mir seltsam vertraut vor ...
tugtug schrieb: >> In der Schaltung finde ich 3k3 Ohm für MCP2551 RS merkwürdig bei 500k. >> Sollte RS nicht mit GND verbunden werden ? > > 500k ? 500kbit > Über RS wird die Flankensteilheit der Frames eingestellt. > 3,3k sind i.O. > >> Dann musst Du das Modul einmal entladen und wieder laden. >> Bitrate nicht vergessen. > > Wie genau mach ich das? ifconfig can0 down rmmod mcp251x modprobe mcp251x ip link set ... ifconfig can0 up
:
Bearbeitet durch User
tugtug schrieb: > Es muss doch an der Hardware liegen, oder? > Gleiches System funktioniert an einem anderen MCP reibungslos. Dann hol dein Messgerät raus und hör auf uns und die Konsole zu belasten.
...okay dann teste ich mal eine andere Widerstandsbeschatung. Mich wundert es nur, dass es Wochenlang super lief. Dann trat der Fehler nach und nach auf, und letztendlich funktioniert es gar nicht mehr. > Bei Dir scheint einiges im Argen zu sein: > - sudo Meldung (ist nicht die Ursache Deines Problems) > - STOPPED - trotzdem kannst Du CAN Frames empfangen ? > - ifconfig can0 up ändert nix > - GPIO IRQ zählt nicht hoch Woran kann das alles liegen?
Bitte fixe erstmal das nervige sudo Problemchen. Und dann versuch nochmal mal mit 'ifconfig can0 down/up' aus dem Status STOPPED zu kommen.
Um ein Problem in der Kommunikation zum MCP251x auszuschließen, solltest Du den Loopback-Modus mal versuchen. Siehe: http://www.raspberrypi.org/phpBB3/viewtopic.php?p=433553#p433553 ohne die angesprochenen Module zu installieren. Es geht nur darum zu sehen, ob die Kommunikation zum CAN-Controller einwandfrei funktioniert.
Spannungsteiler 1.8 und 1k, sowie RS des Tranceivers direkt auf Masse
haben nichts geändert.
> Bitte fixe erstmal das nervige sudo Problemchen.
Geht irgendwie nicht. Aber sollte doch keinen Einfluss haben.
Hallo, ich wollte einmal nachfragen, ob sich bei der Lösung des Problems schon etwas ergeben hat - ich kämpfe hier mit exakt dem gleichen Fehler!
Ist die Geschichte wie der MCP2515 in den Raspberry eingebunden wurde eigentlich irgendwie Standard? ich kann mir vorstellen, wenn man dem ganzen noch einen PIC18F14K50 spendiert (so wie beim USBTin von Thomas Fischl), dann wird das wesentlich universeller. Vor allem kann man den Anwendungscode auch fast unverändert unter Windows, Mac und anderen Linux-Systemen verwenden. Da der MCP2515 ohnehin nur 2 Empfangsbuffer hat, würde ich auch nicht drauf Wetten, dass das Raspberry-Linux immer schnell genug eine Nachricht abholen kann. Wie sind da die einschlägigen Erfahrungen?
Jürgen Liegner schrieb: > Ist die Geschichte wie der MCP2515 in den Raspberry eingebunden wurde > eigentlich irgendwie Standard? Der MCP2515 hat nunmal SPI als Host-Schnittstellen. Insofern ist das Standard. > ich kann mir vorstellen, wenn man dem > ganzen noch einen PIC18F14K50 spendiert (so wie beim USBTin von Thomas > Fischl), dann wird das wesentlich universeller. Die Lösung von Thomas Fischl basiert letztendlich auf dem SLCAN Protokoll. Dazu kann man natürlich einen USB Controller verwenden. > Vor allem kann man den > Anwendungscode auch fast unverändert unter Windows, Mac und anderen > Linux-Systemen verwenden. Stimmt. Für SLCAN gibt es für Windows, Linux und MacOS > Da der MCP2515 ohnehin nur 2 Empfangsbuffer > hat, würde ich auch nicht drauf Wetten, dass das Raspberry-Linux immer > schnell genug eine Nachricht abholen kann. Wie sind da die einschlägigen > Erfahrungen? Stimmt. Das Problem ist die Latenz zwischen CAN Interrupt und den SPI Zugriffen. Nominell ist SPI schnell genug (10MHz also schneller als die höchste CAN Rate), aber Linux ist per se kein Betriebssystem, mit garantierten Antwortszeiten - genauso wenig wie Windows oder MacOS. Auch ein RT Linux scheitert letztendlich am fehlenden RT SPI Treiber. Ich habe hier den MCP2515 am RPi im Einsatz, mit den Problemen, das Pakete verschluckt oder in falscher Reihenfolge ankommen. Zudem wurde im Linux Kernel die Interrupt-Verarbeitung umgebaut. Wo das alte Raspbian mit 3.2 Kernel noch einigermaßen zuverlässig mit dem CAN- Controller funktioniert hat, so gibt es Probleme mit hoher CAN Last und 3.6er Kernel (Stichwort IRQ_ONESHOT), Im RPi Forum kann man Lesen, das an der Verbesserung des SPI-Treibers gearbeitet wird. Das wird mit Sicherheit eine deutliche Verbesserung bringen. Aber IMO wird ein voll ausgelasteter 1MBaud CAN Bus auch hier ein dickes Brett sein. Zumal SocktCAN an sich ziemlich Performance hungrig ist. Kurzum: RPi mit MCP2515 ist momentan noch nicht zu empfehlen. Wer einen gutes und schnelles CAN Interface sucht sollte sich das USB2CAN von 8devices.com anschauen (ca. 60€) . Es hat zudem galvanische Trennung. Für die Leute, die CAN am Auto ausprobieren möchten, der sollte sich bei ebay umschauen. Die Interfaces gibt es für unter 10 Euro incl. Blutooth Unterstützung. Ich kenne die Begeisterung um das RPi, aber das BeagleBone Black ist für CAN die eindeutig bessere Wahl: Es hat einen CAN-Controller integriert. Wenn man auf das Cape-Management verzichtet sogar deren zwei. Da braucht man nur noch einen bzw. zwei CAN-Tranceiver. Im Endeffekt günstiger als das RPi und mit deutlich mehr CPU Performance. Und noch zig andere Schnittstellen, 2x 200MHz Echzeitkerne … BTW: Das BeagleBone White gibt es momentan günstig bei TI zu kaufen: 45$ incl. Versand ! Wer unbedingt basteln möchte, der kann das usbtin nachbauen. Nachteil: Man braucht einen PIC Programmer. Eleganter ist IMHO folgendes: Billigst CP2102 USB Seriell Wandler mit RTS/DTS etc pp. http://www.ebay.de/itm/NEW-USB-To-TTL-COM-Converter-Module-buildin-in-CP2102-/170872574767?pt=LH_DefaultDomain_0&hash=item27c8cc932f plus z.B. PIC18F25K80 (incl. CAN) + Tranceiver Das CP2102 Board kann auch gleich als Programmer dienen: http://dev.kewl.org/k8048/Doc/ Da sollte man auch bei ca. 10 Euro liegen Oder Teensy 3.1, TI Stellaris Launchpad (2xCAN 12.99$ incl Versand) … Gruß Gerd
:
Bearbeitet durch User
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.