Bei meinem HomePi ist der CAN-Bus über einen IC vom Typ MCP2515 direkt an einen Raspberry Pi angebunden. In diesem Beitrage zeige ich, wie der CAN-Bus hard- und softwaremäßig an den Raspberry Pi angebunden wird.
Hardware
Für die Hardware werden der CAN-Controller MCP2515 und der CAN-Transceiver MCP2562 eingesetzt. Der MCP2515 kümmert sich dabei um das Senden und Empfangen der Nachrichten im CAN-Protokoll. Der MCP2562 ist ein Treiber, welcher (einfach ausgedrückt) die Signale des MCP2515 für die Übertragung verstärkt.
Unter Verwendung dieser beiden ICs sind Datenraten von bis zu 1 Mb/s auf dem CAN-Bus möglich.
Die Beschaltung erfolgt gemäß dem folgenden Schaltplan:

Der CAN-Controller MCP2515 wird mit +3,3 V als Betriebsspannung versorgt. Somit ist eine direkte Verbindung der Datenleitungen des SPI-Bus zum Raspberry Pi möglich.
Der Treiber MCP2562 wird mit +5 V als Betriebsspannung versorgt. Zusätzlich wird er mit +3,3 V versorgt, welche er als Basis für seine RXD und TXD Leitungen verwendet. Hier erfolgt somit automatisch durch den IC die Pegelanpassung zwischen +5 V und den +3,3 V, die für den Raspberry Pi erforderlich sind.
Als Taktquelle für den MCP2515 dient ein 16 MHz Quarz. Alternativ kann hier auch ein 8 MHz Quarz verwendet werden.
Der Widerstand R2 dient als Abschlusswiderstand zur Terminierung des CAN-Bus. Dieser sollte nur jeweils einmal am Anfang und am Ende des gesamten CAN-Bus vorhanden sein. Bei Busteilnehmern “in der Mitte” darf dieser Widerstand nicht vorhanden sein!
Installation der Software
Als Basissystem dient hier ein normales Raspbian Buster (oder neuer).
Die nötige Software ist in den Standard-Repositories von Raspbian bereits enthalten und muss nur noch installiert werden.
sudo apt update
sudo apt install can-utils
Aktivieren der Hardware
Damit die Hardware verwendet wird, müssen die entsprechenden Overlays in der Datei /boot/config.txt
konfiguriert werden. Hierfür werden am Ende der Datei die folgenden Zeilen hinzugefügt:
dtoverlay=mcp2515-can0,oscillator=16000000,interrupt=6
dtoverlay=spi-bcm2835-overlay
Die 16000000 steht in dem Fall dafür, dass der MCP2515 mit einem Takt von 16 MHz arbeitet. Dies ist abhängig von dem verwendeten Quarz und muss gegebenenfalls angepasst werden.
Die 6 steht für den GPIO-Pin (BCM), an dem die Interrupt-Leitung des MCP2515 angeschlossen ist und muss ebenfalls an die eigene Hardware angepasst werden.
Zum Übernehmen der Änderungen ist ein Neustart das Raspberry Pis erforderlich.
Prüfen ob die Hardware erkannt wurde
Ob die Hardware korrekt erkannt wurde kann wie folgt überprüft werden:
pi@raspberrypi:~ $ ls /sys/bus/spi/devices/spi0.0
driver modalias net of_node power statistics subsystem uevent
pi@raspberrypi:~ $ ls /sys/bus/spi/devices/spi0.0/net
can0
pi@raspberrypi:~ $ ls /sys/bus/spi/devices/spi0.0/net/can0
addr_assign_type carrier_up_count gro_flush_timeout netdev_group queues
address device ifalias operstate speed
addr_len dev_id ifindex phys_port_id statistics
broadcast dev_port iflink phys_port_name subsystem
carrier dormant link_mode phys_switch_id tx_queue_len
carrier_changes duplex mtu power type
carrier_down_count flags name_assign_type proto_down uevent
pi@raspberrypi:~ $ ls /sys/class/net
can0 eth0 lo
Sieht die Ausgabe so aus, wie hier dargestellt, dann ist alles in Ordnung und der Raspberry Pi kann mit dem MCP2515 kommunizieren. Sollte ein Problem vorliegen, dann liefert mindestens einer der Befehle einen Fehler zurück.
Einrichtung des CAN-Interfaces
Der CAN-Bus erscheint auf dem Raspberry Pi als Netzwerkinterface. Ein Aufruf von ip addr
sollte das Interface can0
anzeigen, wobei es jedoch noch als DOWN
markiert ist.
...
3: can0: <NOARP,ECHO> mtu 16 qdisc pfifo_fast state DOWN group default qlen 10
link/can
Über den folgenden Befehl kann das Interface manuell aktiviert werden:
sudo ip link set can0 up type can bitrate 500000
Hierbei wird eine Bitrate von 500 kb/s verwendet. Diese Bitrate kann bei Bedarf natürlich angepasst werden und sollte bei allen Busteilnehmern gleich sein.
Ein erneuter Aufruf von ip addr
zeigt nun, dass das Interface aktiv ist.
...
3: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN group default qlen 10
link/can
Automatisches Aktivieren des Interfaces beim Systemstart
Damit das can0 Interface beim Systemstart automatisch aktiviert wird, müssen die folgenden Einträge in der Datei /etc/network/interfaces
hinzugefügt werden. Dies funktioniert auch dann, wenn die “normalen” Netzwerkinterfaces vom dhcpcd verwaltet werden.
# CAN-Bus
auto can0
iface can0 can static
bitrate 500000
Die 500000 ist hierbei wieder die zu verwendende Bitrate.
Testen des CAN-Bus
Zum Testen des CAN-Bus können nun über ein Terminal Nachrichten gesendet oder empfangen werden.
Senden von CAN-Nachrichten
Zum Senden von Nachrichten kann das Tool cansend
verwendet werden, wobei Standard Frames mit 11-Bit Nachrichten-IDs und Extended Frames mit 29-Bit Nachrichten-IDs unterstützt werden.
Für Standard Frames sieht der Aufruf wie folgt aus:
cansend can0 123#42ff
123 ist in diesem Fall die ID der Nachricht in Hex-Schreibweise und muss immer 3 Zeichen lang sein. 42ff sind die Daten, wiederum in Hex, mit einer Länge von 0 bis 8 Byte.
Bei Extended Frames besteht die ID aus 8 Zeichen. Der Rest verhält sich analog zu den Standard Frames.
cansend can0 012EA567#42ff
Eine kurze Hilfe zu cansend
erhält man über die Befehle cansend --help
oder man cansend
.
Empfangen von CAN-Nachrichten
Über den Befehl candump
könne empfange Nachrichten angezeigt werden.
pi@raspberrypi:~ $ candump can0
can0 123 [2] 42 FF
can0 012EA567 [2] 42 FF
can0 1FFFFFFF [8] 00 11 22 33 44 55 66 77
can0 001 [0]
can0 00001337 [4] DE AD BE EF
26. Dez. 2019 um 11:59
Hi Peter,
was realisierst du mit der CAN Schnittstelle? Hast du dafür Projekte oder wolltest du nur zeigen/demonstrieren das es funktiniert mit dem PI?
Gruß,
Lars
26. Dez. 2019 um 18:27
Hallo Lars,
aktuell habe ich lediglich zwei RasPis mit jeweils einem zusätzlichen ATMega Mikrocontroller über den CAN-Bus verbunden. Also insgesamt 4 Teilnehmer. Durch die Mikrocontroller kann ich mittels CAN-Nachrichten den jeweils zugehörigen RasPi direkt hardwaremäßig aus- und einschalten bzw. resetten.
Geplant habe ich noch einige Sensoren und Aktoren auf Basis von Mikrocontrollern für meine Hausautomatisierung, die dann über den CAN-Bus angebunden werden sollen.
21. Jan. 2020 um 15:05
Hallo, allerseits. Ich bin zur Zeit dabei eine Heimautomatisierung auf CAN bus Basis zu bauen.
Bin da schon relativ weit denke ich wobei der PI so eine Art Zentrale sein soll.
Stand ich habe Knoten die auf einen Arduino Nano basieren und dazu einen Platine die in eine 55mm Unterputzdose passt, die ersten 15 Platinen sind da 1 aufgebaut getestet OK. dazu gibt es eine Huckepack Platine die 4 Taster hat, und 4 2 farbige LED’s steuern kann. Zusätzlich existiert als Option Anschluss für eine 2/4 zeiliges LCD Display einen DHT22 oder BME80 oder DS18B20, 10 Platinen sind da funktionieren mit kleinen Änderungen, neue werden die Tage bestellt.
Dann existiert Protyp Zentrale, wieder mit Arduino Nano, 1 Echzeituhrmodul und 4 Portextender, PCF8574,d.h. ich kann damit neben den nicht aktuell nicht benutzten Arduino Ports bis zu 32 Relais etc. schalten. grundsätzlich erweiterbar bis zu 64. Zusätzlich Pegelwand zu PI für das CAN Interface.
Alle Knoten und die Zentrale werden mit 12V versorgt und haben jeweisl einen DC-DC Step Down Regler der fix auf 5V eingestellt ist.
Verkabelung geht Sternförmig zu Zentrale, durch CAN Hin- und Rückleitung ist es trotzdem ein Bus. Von der Zentrale gehen Leitungen zu einem Relaisfeld an dem alle Leitungen von Lampen, elektrischen Rolladen etc. ankommen und geschaltet werden können.
Software weitgehend, d.h. funktioniert kann/muss aber noch verbessert und optimiert werden, fertig, alle Knoten haben die selbe Software, wobei Funktionen, sowie Peripherie über eine Tabelle im EEPROM gesteuert werden. Somit ein Funktionstausch via neue Tabelle über den Bus (dafür später der PI) gemacht werden. Softwaretausch über Bootloader ist für später angedacht.
So das in kürze, werde das ganze demnächst auf meinen Webseite oder auch GitHub veröffentlichen. Falls hier jemand Interesse an dem Projekt hat, gerne melden.
21. Jan. 2020 um 17:51
Hallo, habe entsprechend Deiner Anleitung den PI aufgesetzt, aktuelles Buster, alle Updates etc. Hardware wird korrekt erkannt, soweit so gut. allerdings ist sobald der MCP initialisiert ist mein BUS tot d.h. scheinbar blockiert, den sobald ich den MCP vom Strom nehme ist alles wieder gut. candump zeigt nichts, cansend na ja wie soll ich über einen blockierten Bus senden.
Hardware x mal gecheckt, sollte ja da der MCP scheinbar richtig initialisiert wird OK sein. Habe das alles nochmal mit einem 2ten PI gemacht, gleiches Ergebnis.Any Idea
Gruß
Rainer
22. Jan. 2020 um 9:33
Hallo Rainer,
ein ähnliches Problem hatte ich auch mal, als ich beim dtoverlay einen falschen Pin für den Interrupt angegeben hatte. Ich hatte da die BCM und WiringPi Pinnummern durcheinander gebracht. Das führte dazu, dass die Software dachte, dass der Interrupt ständig getriggert wird und den MCP permanent ausgelesen hat, was den Bus blockiert und den Load auf dem Pi in die Höhe getrieben hat.
Beim dtoverlay muss die BCM Pin-Nummer angegeben werden.
22. Jan. 2020 um 13:42
Hallo Peter, erst mal Danke für die schnelle Antwort.
Habe das soeben nochmal überprüft. Ich habe wie in Deiner Anleitung interrupt=6 angegeben. Das ist nach https://de.pinout.xyz/ pin 31 auf der Anschlussleiste, die anderen Anschlüsse SI,SO etc. sind ja fix. Auch die Hardwareerkennung nach Deiner Anleitung klappt.
Wie sprichst Du die CAN Schnittstelle per Software an, cansend auf Commandline kann ja nur zum testen sein.
Gruß Rainer
22. Jan. 2020 um 17:00
Dann sollte das eigentlich passen.
Tauchen irgendwelche Fehlermeldungen oder ähnliches in den Meldungen vom Kernel (`dmesg`) auf?
Softwareseitig verwende ich das Node.js Modul socketcan um CAN-Nachrichten zu empfangen und zu senden.
26. Jan. 2020 um 16:58
Hallo Peter, ja das dmesg hat mich auf die Spur geführt. Nach Stunden suchen die Lösung hier https://www.raspberrypi.org/forums/viewtopic.php?t=190868
dtparam=spi=on
dtoverlay=mcp2515-can0,oscillator=16000000,interrupt=25,spimaxfrequency=500000
dtoverlay=spi0-hw-cs
wobei das “spimaxfrequency” schließlich zum Erfolg führte.
In Deiner Beschreibung fehlt denke ich das “dtparam=spi=on”
das “dtoverlay=spi0-hw-cs” braucht man wohl ab kernel +4.4.x
Das eigentliche Problem scheint ein Timing Problem zu sein. Im dmesg kommt erst ein MCP erfolgreich initialisiert aber danach “mcp251x spi0.0: MCP251x didn’t enter in normal mode”.
Gruß
Rainer
31. Jan. 2020 um 17:58
Hmm… ich habe bei mir einen 4.19er Kernel laufen und das ohne `dtoverlay=spi0-hw-cs`. Auch `dtparam=spi=on` ist bei mir nicht nötig. Schaden kann beides aber denke ich auch nicht.
Was `spimaxfrequency` angeht, so deutet das auf ein Timingproblem hin, wodurch die hohen SPI-Frequenzen zu Problemen führen. Eventuell bekommt der MCP2515 keinen sauberen Takt von seinem Quarz?
1. Feb. 2020 um 0:15
Hallo, wollte nur darauf hinweisen. Beim dtparam=spi=on bin ich mir auch nicht sicher ob das nötig ist, da sind auch andere unterschiedlicher Meinung. Der Takt sollte sauber sein, ist ein fertiges Board. Immerhin so tut es 1A, das ist das wichtigste. Trotzdem hat mir dein Tutorial sehr geholfen, Danke dafür.
7. Feb. 2020 um 11:38
Hallo Peter,
erstmal vielen Dank für deinen sehr guten Beitrag.
Ich nutze zur Zeit das PiCAN Duo Board der Firma skpang um die CAN-Kommunikation zweier Steuergeräte auszulesen und es funktioniert ohne Probleme. Jetzt habe ich mir gedacht ich könnte das ganze auch über ein MATLAB/Simulink Modell betreiben. (Passende Bibliotheken existieren seitens Mathworks für den Raspi 3b+ mit MCP2515)
Sobald ich aber mit “dtoverlay=mcp2515-can0,oscillator=16000000,interrupt=24” das CAN-Shield aktiviere, verschwindet das dev/spidev0.0 File und Simulink kann nicht mehr auf den Raspi zugreifen, da vermutlich beides über den gleichen SPI läuft. Hast du eine Idee wie man das umgehen könnte?
Viele Grüße,
Tim
7. Feb. 2020 um 11:56
Schau mal da http://www.netzmafia.de/skripten/hardware/RasPi/RasPi_SPI.html
eventuell hilft das weiter, Hintergrund es gibt zwei CS für 2 SPI Schnittstellen, habe leider keine Ahnung wie/wo man das bein CAN Bus einstellen kann.
Gruß
Rainer
7. Feb. 2020 um 12:27
Die beiden standardmäßigen CS0 und CS1 auf GPIO 8 und 7 gehören beide zur gemeinsamen SPI Schnittstelle `spi0`. Durch das PiCAN Duo Board sind diese aber beide schon belegt und eine dritter CS am gleichen SPI wird nicht unterstützt.
Ab dem Pi2 gibt es noch eine zweite Hardware SPI Schnittstelle mit einem eigenen CS.
7. Feb. 2020 um 12:19
Hallo Tim,
ab dem Pi2 und dem Kernel 4.4 kannst du einen zweiten SPI Port (spi1) über `dtoverlay=spi1-3cs` und evtl. noch `dtparam=spi=on` aktivieren. Das Device dafür ist dann `/dev/spi1.0`.
Die hardwareseitige GPIO Zuordnung dafür sieht dann so aus:
SPI1 CS0 – GPIO 16
SPI1 MISO – GPIO 19
SPI1 MOSI – GPIO 20
SPI1 SCLK – GPIO 21
Mehr Infos dazu
Soweit ich weiß, muss bei der Nutzung des zweiten Hardware-SPI aber das serielle Terminal an RX/TX deaktiviert werden. Hierfür musst in der Datei `/boot/cmdline.txt` den Parameter `console=serial0,115200` entfernen.
21. Apr. 2020 um 13:21
Hallo Peter,
danke für diese gute Erklärung!
Bis zum aktivieren des CAN Moduls funktioniert bei mir noch alles super!
Ich kann mit einem IXXAT-CAN-USB Modul eine Meldung los schicken und der MCP2515 am CAN0 sendet das Acknowledge.
Allerdings kann ich mit dem candump keine Meldungen empfangen (also es wird keine Meldung angezeigt).
Sobald ich vom Raspberry aus versuche eine Medlung mit dem Befehl “cansend” los zu schicken geht der MCP2515 in den BUS-OFF state. (dmesg Zeile: “mcp251x spi0.0 can0: bus-off”
Ich habe auch schon versucht den Interrupt Pin von 25 auf 4 zu ändern. Das hat aber keine Änderung gebracht.
Getestet mit 500kBaud und 125kBaud.
Mein System ist das aktuelle “Raspbian Buster Lite”
Version: February 2020
Release date: 2020-02-13
Kernel version: 4.19
Die HW ist ein Pi 1 (revision weiß ich leider nicht)
Nachdem die Konfiguration des MCP2515 soweit funktioniert, dass ein Standard CAN-USB interface Meldungen senden kann, weiß ich nicht inwiefern die HW ein Problem haben könnte.
lg
Andreas
Weißt du da irgend einen Rat dazu woran es liegen könnte?
21. Apr. 2020 um 13:34
Hallo Peter,
ich habe jetzt das Problem bereits entdeckt.
Ich habe das CAN-Board mit 3.3V betrieben und das scheint zu wenig zu sein.
Wenn ich das Board nun mit 5V betreibe funktioniert auch senden und empfangen einwandfrei.
lg
Andreas
22. Apr. 2020 um 13:19
Hallo Andreas,
also der CAN-Controller MCP2515 läuft grundsätzlich mit 3,3 V. Deshalb hat wahrscheinlich auch die Initialisierung geklappt.
Der CAN-Treiber MACP2562 hat extra zwei Spannungsversorgungen VDD (Pin 3) und VIO (Pin 5). Als VDD benötigt der Treiber 5 V. Über VIO kann eine niedrigere Spannung angelegt werden, die der Treiber dann für die Kommunikation mit dem CAN-Controller nutzt. Damit ist es dann z.B. möglich die gesamte Kommunikation zum RasPi auf 3,3 V laufen zu lassen und der Treiber erledigt dann intern die nötige Pegelwandlung.
Achtung bei 5 V am CAN-Controller MCP2515: Da damit die Leitungen des SPI-Bus auch 5 V Signale erhalten kann es zu Beschädigungen am RasPi kommen. Hier müsste dann ein Levelshifter dazwischen, der die Pegelanpassung zwischen 5 V und 3,3 V macht.
14. Mai. 2020 um 17:35
sudo apt update
sudo apt install can-utils
dtoverlay=mcp2515-can0,oscillator=16000000,interrupt=6
dtoverlay=spi-bcm2835-overlay
Hallo,
ich habe die ersten beiden o.g. Installationsschritte so ausgeführt.
Finden beim prüfen dann aber nicht das Verzeichnisse
/sys/bus/spi/devices/spi0.0/net
can0
15. Mai. 2020 um 20:13
Hast du nach den Eintägen in die Datei `/boot/config.txt` den Pi neu gestartet? Das ist notwendig, um die Änderungen anzuwenden.
Ansonsten mal mittels `dmesg` die Kernelmeldungen anschauen und da nach `mcp251x` suchen. Wenn alles funktioniert sollte dort diese Meldung zu finden sein:
`mcp251x spi0.0 can0: MCP2515 successfully initialized.`
3. Aug. 2020 um 19:36
Hallo Peter,
vielleicht kannst Du mir helfen?
Ich habe einen PI als kleine Fileserver und Hausautomation am laufen.
Nun habe ich eine PCB entwickelt, auf der ein mcp2515 Can-Bus Controller sowie ein TJA1050 Treiber drauf sind.
Da ein SPI TFT Screen ebenfalls drauf ist und dieser CE0 für TFT_CS und CE1 für TP_CS benutz, habe ich dem CAN Controller GPIO15 als CS gegeben. Als IRQ dient GPIO 6.
Wie kann ich auf der 2. SPI Schnittstelle den Controller aktivieren?
in meiner Config.txt steht folgendes:
dtoverlay=mcp2515-can1,oscillator=8000000,interrupt=6,spimaxfrequency=500000
dtoverlay=spi1-3cs,cs0_pin=15
dtoverlay=spi-bcm2835-overlay
# CAN-Bus Controller-CE auf High setzen
gpio=15=op,dh
# Brüller beim booten auf High setzen, sonst quietscht er während des bootens!
gpio=4=op,dl
# Klemme1, Klemme2 und Klemme3 Pullups einschalten und als Eingänge definieren
gpio=16,12,25=pu
gpio=16,12,25=ip
Wobei “Brüller” ein piezoSummer ist.
nach Eingabe von ip addr oder ifconfig ist kein CAN vorhanden.
DMESG sagt:
[ 10.197402] mcp251x spi0.1: MCP251x didn’t enter in conf mode after reset
[ 10.197474] mcp251x spi0.1: Probe failed, err=16
[ 10.197589] mcp251x: probe of spi0.1 failed with error -16
Kannst Du mir da weiterhelfen?
Gruß,
Wolfram
5. Aug. 2020 um 13:52
Hallo Wolfram,
die SPI-Schnittstellen sind in den Overlays fest einprogrammiert. Dabei nutzt `mcp2515-can0` den `spi0.0` und `mcp2515-can1` den `spi0.1`.
Um den `spi1.0` und/oder `spi1.1` dafür nutzen zu können, musst du leicht modifizierte Overlays verwenden. Eine Anleitung dazu findest du z.B. hier.
26. Aug. 2020 um 14:10
Super Anleitung.. nur eine kleine Verständnis-Frage hätte ich dazu, da CAN ein neues Thema für mich ist: Werden die Anschlüsse RXCAN und TXCAN von IC1 und IC2 jeweils miteinander verbunden?
Danke 🙂
28. Aug. 2020 um 13:44
Ja genau, die werden verbunden. IC1 (MCP2515) ist der CAN-Controller, der einfach gesagt das Protokoll macht und dies entsprechend an TXCAN/RXCAN raus gibt. IC2 (MCP2562) ist dann der CAN-Treiber, der diese Signale für die Übertagung über größere Entfernungen auf CANH/CANL umsetzt.
30. Aug. 2020 um 12:55
Hallo Peter,
wir hatten schon mal kurz Kontakt wegen der RASPI CAN Schnittstelle. Danke Deiner super Beschreibung funktioniert das 1a. Ich habe mir diverse Tools im Python geschrieben und kann damit meine Smarthome Installation steuern. Noch nicht fertige Beschreibung siehe hier https://zen-works.de/index.php?id=13
Erste Knoten laufen, Licht ein/aus, Rollo rauf runter auch zeitegsteuert ok.
Aktuell bin ich an einem CAN Bootloader und plage mich schon seit Tagen damit http://www.kreatives-chaos.com/artikel/can-bootloader rum. Die Seite atmega328p habe ich, die PC Seite ist leider in Python 2 und natürlich nicht um direkt auf die CAN Schnittstelle am PI gedacht. Habe nun versucht das umzuschreiben und bin dabei auf der Google Suche nach einer Fehlermeldung auf Deinen CAN Bootloader gestoßen. Die App wird wohl direkt auf dem PI laufen und die dortige CAN Schnittstelle unterstützen, vermute ich. leider habe ich mit der von Dir verwendeten IDE keine Erfahrung, arbeite bisher nur mit der Arduino IDE, bzw. der AVR GCC Umgebung am MAC. Was mit noch unklar ist wie ich zum HEX File des Bootloaders komme. Na ja erst mal einlesen. jedenfalls erst mal Danke für Deine Arbeit. U.U. hast Du Interesse an meine Knoten, die in ein 55er Unterputzdose passen. Bilder gibt es im obigen URL.
Schönen Sonntag
Gruß
Rauiner
30. Aug. 2020 um 18:34
Hallo Peter,
CAN Bootloader. Hab mich da mal etwas eingelesen und auch im Plattform IO komplieren können. Die wesentlich Anpassungen werden in der config.h gemacht. Das ist sehr schön gelöst. Aber eines fehlt mir, wo stell ich den CS Port ein?
Ansonsten super Arbeit, gut dokumentierter Code, übersichtlich.
Gruß
Rainer
30. Aug. 2020 um 19:35
Hallo Peter,
nochmal ich wegen des CS. In der Config.h verwendest Du einen SPI_SS, der wohl für den du wohl für den Chip Select verwendest. Das geht grundsätzlich. Allerdings ist der SPI_SS Pin eigentlich der Eingang für die Master/Slave Steuerung. Ist dieser als Eingang geschaltet kann darüber gesteuert werden ob der atMega Master oder Slave ist. Was zu unschönen Effekten führen kann wenn dieser Port nicht initialisiert wird, da er offen je nach zufälligen Pegel den atMega in Slave Mode schaltet und so alle blockiert. Solange der aus Ausgang für den Chip Select geschaltet ist ist das egal. meine Hardware verwendet aber den BP0 für den Chip Select, d.h. somit wird der SS nicht initialisiert und steht default auf Input. Grundsätzlich wird empfohlen den SPI_SS so nicht für seinen Funktion benötigt auf Output zu initialisieren oder zumindest mit einem Pullup zu versehen. Insofern finde ich die Bzeichnung SPI_SS etwas irreführend. Ich würde den ehr SPI_CS nennen. Als Ausgang für den CS kann ja jeder freie Digitale Port verwendet werden.
Gruß
Rainer
31. Aug. 2020 um 8:51
Hallo Rainer,
freut mich zu lesen, dass dein Projekt voranschreitet und dir meine Arbeit helfen konnte. 🙂
Mit dem CAN-Bootloader von Kreatives Chaos hatte ich auch anfangs experimentiert, wobei dieser jedoch bei neueren Controllern zu Problemen führte. U.a. wird da der Watchdog nicht richtig initialisiert, wie ich später beim erstellen meines MCP-CAN-Boot gelernt habe. Deshalb (und weil ich über den RasPi flashen wollte) habe ich dann meinen eigenen Bootloader geschrieben, der inzwischen sehr zuverlässig seine Arbeit in meinem kleinen Netzwerk verrichtet.
Zum MCP-CAN-Boot:
Die Bezeichnung `SPI_SS` ist bewusst so gewählt, da hier der gleichnamige Pin aus dem Datenblatt verwendet wird. Der Pin wird bei dem Bootloader auch immer als Output initialisiert. Dieser war eigentlich auch nicht anpassbar vorgesehen, aber ich stimme dir zu, dass das je nach Hardware durchaus Sinn machen kann.
In der aktuellen Version vom MCP-CAN-Boot musst du beim Ändern des `SPI_SS` darauf achten, dass der Pin weiterhin zu Port B gehören muss. Andernfalls würde er nicht richtig initialisiert und geschaltet werden.
18. Mrz. 2021 um 8:15
Könnt ihr mir einen Tipp geben, wie ich am besten ein Script erstelle um zyklisch CAN Nachrichten zu senden?
Ich würde gern alle 100ms eine CAN Botschaft mit “cansend can0 …” senden.
18. Mrz. 2021 um 9:14
Der einfachste Weg (wenn du `cansend` nutzen willst) wäre das ganze in einer Bash mit `watch` zu triggern:
`watch -n 0.1 -t -p -x cansend can0 …`
Nachteil ist aber, dass alle 0,1 Sekunden ein neuer Prozess (`cansend`) gestartet wird. Eventuell ist `cansend` dafür auch nicht schnell genug, um das so abarbeiten zu können.
Ich denke besser wäre hier ein kleines Programm oder Node.js Script, welches ein mal gestartet wird und dann die Nachrichten direkt sendet. Ein Beispiel für Node.js habe ich dir hier erstellt: https://gist.github.com/crycode-de/4d924b5234d1cf3b37a1386aef308059
18. Mrz. 2021 um 9:36
danke.
18. Mrz. 2021 um 14:00
Hallo Peter,
also das läuft inzwischen alles prima. Ich habe das jetzt mit meinem Home Assistant gekoppelt. D.h. auf dem PI laufen zwei in Python geschriebene Dienste die ein CAN to MOSQUITTO Gateway darstellen, der eine mosquitto publisher monitored den Bus und wenn etwas (Licht) geschaltet wird meldet es dies an den Broker des Home Assistant und es wird der Status der Lampe angezeigt. Der zweite Dienst mosquito subscriber empfängt Befehle von Home Assistant und sendet dan CAN Befehle um Licht zu schalten. Ausserdem leitet er die Befehle zu automatischen Öffnen und Schliesen der Rolläden abhängig von der Zeit des Sonnen auf- bzw. Untergangs an den CAN Bus. läuft seit Monaten stabil. Doku des Projekt auf http://www.zen-works.de
Gruß Rainer
@x1e wozu brauchst du alle 100ms einen Befehl?
Rainer
29. Apr. 2021 um 11:08
Ist es in dieser Konfigurationszeile hier: dtoverlay=spi-bcm2835-overlay möglich das UART Interface auszuwählen für die Kommunikation?
29. Apr. 2021 um 18:50
Wohl kaum, da `dtoverlay=spi-bcm2835-overlay` die SPI-Schnittstelle aktiviert und der hier verwendete MCP2515 IC eben SPI benötigt.
Wenn du den UART verwenden möchtest, dann brauchst du auf jeden Fall einen anderen IC und eine andere Initialisierung (sofern es überhaupt passende ICs dafür gibt).
29. Apr. 2021 um 19:01
Hallo Timo, was willst Du überhaupt erreichen. Über die serielle als den UART geht kein CAN Protokoll. Bei CAN wird das meiste des Protokolls von den MCP bearbeitet. Ähnlich wie beim UART der die Anzahl der Bit, der Start und Stopbits und Parity sowie Baudrate handelt aber das ist ein komplett anderes Protokoll. Sag was Du erreichen willst, dann können wir Dir u.U. Tips geben.
5. Mai. 2021 um 15:43
Hallo zusammen, vielen Dank für die schnelle Antwort. Wir haben dieses CAN Erweiterungsboard für den Raspberry Pi gekauft (https://libstock.mikroe.com/projects/view/4026/can-isolator-click). Dabei wird vom Raspberry über UART der CAN Tranceiver auf dem Board angesteuert. Wir schauen uns jetzt die CAN Treiber von Mikroe an.
5. Mai. 2021 um 16:37
Soweit ich das grad sehe, ist der dort verbaute ADM3053 Chip ein reiner CAN-Transceiver (ähnlich dem oben beschriebenen MCP2562). Du brauchst also zusätzlich noch einen CAN-Controller, wie beispielsweise den MCP2515.
Die RxD und TxD Anschlüsse des ADM3053 kannst du nicht einfach direkt mit dem Raspi verbinden, da hier bereits das CAN-Protokoll erwartet wird.
5. Mai. 2021 um 18:11
wenn das ein spezielles Board für den Raspi ist sollte es auch entsprechende Treibersoftware dazu geben mit Beispielen. Die Soaftware von Peter ist für die Kommunikation mit dem MCP via SPI gedacht, nicht via UART. Und dann brauchst Du noch wie peter schon sagt die Bustteibei
22. Mai. 2021 um 14:05
Hallo zusammen,
ich versuche zur Zeit einen Can-Bus mit zwei MCP2515 zum Laufen zu bringen. Einzeln funktionieren sie einwandfrei. Ich glaube bei meiner /boot/config.txt ist noch ein Fehler enthalten. Der zweite Can Controller wird nicht erkannt. Weiß jemand was ich noch umstellen muss damit es am spi0.1 erkannt wird?
dtoverlay=mcp2515-can0,oscillator=8000000,interrupt=6
dtoverlay=mcp2515-can1,oscillator=8000000,interrupt=13
dtoverlay=spi-bcm2835-overlay
Danke und Grüße!
25. Mai. 2021 um 17:42
Eventuell musst du noch den spi0 mit 2 Chip-Selects aktivieren. (nur eine Idee)
Dazu noch diesen Eintrag hinzufügen:
`dtoverlay=spi0-2cs,cs0_pin=6,cs1_pin=13`
1. Jun. 2021 um 15:49
Hallo Peter,
erst mal Daumen hoch für Deine Seite, da hat sich ja viel getan seit ich das letzte mal da war. Einfach, übersichtlich ohne großen Schnickschnack und Super information. Find ich einfach toll!
mein CAN Home Projekt kennst Du ja im großen und ganzen, es läuft oder besser lief nun seit Anfang des Jahres stabil ohne Reboot etc. Seit gut 3 Monaten auch mit der Anbindung des Home Assistant, Da für laufen 2 Python Dienste auf dem PI ein Publisher und ein Subscriber die ein MQTT CAN Gateway darstellen. Habe das seit dem nicht mehr hingefasst, weder neue Software noch Updates (automatische sind am PI deaktiviert) auch kein wissentlich Neustart oder Stromausfall. Seit etwa einer Woche ist die Kommunikation zwischen Home Assistant gestört, d.h. ich kann vom Home Assistant nichts mehr schalten. Neustart des Systems, alles geht wieder, ein paar Stunden. Nun habe ich festgestellt, das es am PI liegt, das CAN System läuft ja autark. Die weitere Suche ergab, dass es an der CAN Schnittstelle, das heisst am SPI liegen muss, denn die Kommunikation vom Home Assistant zu PI, als auch die Dienst laufen. Wenn ich aber den CAN Bus Monitor auch ein Python Programm starte kommt nichts, egal ob ich am CAN System oder am Home Assistant einen Befehl auslöse, Das alles wieder geht sobald ich den PI neu starte, dabei aber am CAN System nichts passiert, kann es auch nicht der MCP sein.
In den log am PI kann ich keinen Grund finden. Hats Du irgend eine Idee wo ich noch suchen kann.
RAM und Platz auf der SD Karte sind genug auch im Fehlerfall. Wieso fällt ein System, das ohne Änderung über Monate 24*7 durchgelaufen ist, plötzlich nach wenigen Stunden aus?
Danke für jeden Tip
Gruß
Rainer
1. Jun. 2021 um 16:30
Danke für das positive Feedback 🙂
Hast du mal in den Kernel-Meldungen (mit `dmesg`) geschaut, ob dort etwas geloggt wird?
Deiner Beschreibung nach könnte ich mir vorstellen, dass der MCP2515 sich wegen zu vieler Fehler vom Bus trennt (wieso auch immer). Das würde dann in den Kernel-Meldungen einen entsprechenden Eintrag erzeugen.
Eventuell verursacht irgendein neues Gerät in deiner Umgebung Störungen auf den Bus-Leitungen?
2. Dez. 2021 um 15:57
Hallo, meine Schaltung ist recht ähnlich und Ich renne permanent in ein bus-off.
Ich nutze einen mcp2515 mit mcp2551 und habe an beiden Leitungen zwischen den ICs LEDs die über Widerstände nach +5V gehen als Kontroll-Leuchten.
Ich nutze nun also SPI0, mit CS0 und ebenfalls GPIO6 als INT.
Das Ganze lässt sich initialisieren aber nach dem ersten Senden geht’s in ein bus-off
Seltsam ist, dass mir hier eine clock von 8MHz gezeigt wird. Soll das so? Ich nutze ein 16MHz-Quartz
# ip -details -statistics link show can0
4: can0: mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
link/can promiscuity 0 minmtu 0 maxmtu 0
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 1 1 1 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
RX: bytes packets errors dropped overrun mcast
0 0 0 0 0 0
TX: bytes packets errors dropped carrier collsns
0 0 1 1 0 0
Auf der Gegenseite ist ein MCP2551 an einem STM32-Controller.. Auch der fällt ständig in einen BUS-OFF..
Gibts irgendwelche Möglichkeiten, da den Fehler zu finden? Die Schaltung muss ich mal in ein Bild klopfen..
3. Dez. 2021 um 17:44
Die Anzeige `clock 8000000` habe ich bei mir auch, obwohl ich auch einen 16 MHz Quarz nutze und das in `/boot/config.txt` entsprechend eingetragen ist.
Wenn beide Seiten in einen Bus-Off gehen, dann haut irgendwas mit der Übertragung nicht hin. Nach zu vielen Fehlern koppelt sich dann ein Busteilnehmer aus, um weitere (von ihm ausgehende) Fehler zu meiden.
Hast du es mal ohne deine Kontroll-LEDs versucht?
Ist an jedem Ende der Bus-Leitung eine Terminierung mit 120 Ohm drin?
Kommen überhaupt gesendete Nachrichten auf der Gegenseite an?
3. Dez. 2021 um 20:38
ich habe mich jetzt mal in Unkosten gestürzt und mir einen CAN-Debugger gekauft. Dann ist zumindest ein gerät nicht selbst konstruiert und sollte definitiv funktionieren.. Eventuell bringt das schon mal was beim Debuggen.
Die Kontroll-LEDs auf der STM32-Seite habe ich jetzt abgeklemmt. am Raspi bin ich noch nicht dazu gekommen. Terminatorwiderstände habe ich auch. Allerdings bin ich mir beim Raspi gerade nicht sicher, wie groß der ist. Könnte sein, dass der 150Ohm hat weil gerae nix anderes rum lag damals…
3. Dez. 2021 um 21:22
Laut Oszi sendet der STEM32 zwar, das Signal hat allerdings nur eine Spannungsdifferenz (H/L) von 0.6V. Sollte es nicht eigentlich das Doppelte sein?
Vielleicht ist ja der Treiber kaputt?
4. Dez. 2021 um 20:16
Normal solltest du im dominanten Zustand eine Spannungsdifferenz von etwa 2 V zwischen CAN H und CAN L haben.
Prüfe mal deine Widerstände zur Terminierung. Wenn die viel zu klein sind, dann könnte das die niedrige Differenz erklären.
9. Okt. 2022 um 12:34
Hallo zusammen,
alles nach Anleitung gebaut – und es funktioniert (immer noch)!
Sehr hervorragende Arbeit & ein dickes Danke!
11. Okt. 2022 um 12:12
Ich bin am verzweifeln – ich habe einen Raspi4 sowie den CAN-HAT, hab die entsprechenden Eintragungen vorgenommen, bekomme aber das System nicht ans Laufen.
CANDUMP zeigt nix an, bei CANSEND passiert auch nix.
Woran könnte es liegen? Ich bin überfragt…
11. Okt. 2022 um 13:49
Für den CAN HAT musst du in der Datei
/boot/config.txt
je nach Variante diese Einstellungen drin haben:dtoverlay=mcp2515-can0,oscillator=8000000,interrupt=25,spimaxfrequency=1000000
oder
dtoverlay=mcp2515-can0,oscillator=12000000,interrupt=25,spimaxfrequency=2000000
Ansonsten mal im Kernellog (
sudo dmesg
) schauen, ob da irgendwelche Fehler im Zusammenhang mit dem mcp2515 oder can0 geloggt werden.11. Okt. 2022 um 18:38
pi@raspberrypi:~ $ ls /sys/bus/spi/devices/spi0.0
driver modalias of_node statistics supplier:platform:fe200000.gpio
driver_override net power subsystem uevent
pi@raspberrypi:~ $ ls /sys/bus/spi/devices/spi0.0/net
can0
pi@raspberrypi:~ $ ls /sys/bus/spi/devices/spi0.0/net/can0
addr_assign_type dev_port name_assign_type speed
address dormant napi_defer_hard_irqs statistics
addr_len duplex netdev_group subsystem
broadcast flags operstate testing
carrier gro_flush_timeout phys_port_id threaded
carrier_changes ifalias phys_port_name tx_queue_len
carrier_down_count ifindex phys_switch_id type
carrier_up_count iflink power uevent
device link_mode proto_down
dev_id mtu queues
11. Okt. 2022 um 18:43
Hab mal sudo dmesg ausgeführt und nach mcp2515 gesucht:
[ 8.086152] mcp251x spi0.0 can0: MCP2515 successfully initialized.
11. Okt. 2022 um 13:40
Hallo Andre, soweit ich das sehe hast Du einen anderen Adapter als CryCode. Das kann heißen, das die Beschreibung von CryCode nicht passt. Ausserdem hast Du einen 2.ten CAN-Knoten. Bei nur einem brauchst Du, soweit ich das noch in Erinnerung habe den LoopBack Mode, Etwas mehr Information über Deinen Aufbau wäre nützlich um zu helfen.
11. Okt. 2022 um 18:42
Ich hab ganz normal den Pi mit dem CAN-HAT verbunden – hab einen 12000 Quarz und hab entsprechend diesen Eintrag genommen..
toverlay=mcp2515-can0,oscillator=12000000,interrupt=25,spimaxfrequency=2000000
Cansend und candump funktioniert nicht.
Hab das ganze System auch nochmal neu aufgesetzt – ebenfalls ohne Ergebnis
11. Okt. 2022 um 18:46
pi@raspberrypi:~ $ ip addr
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether e4:5f:01:e2:db:84 brd ff:ff:ff:ff:ff:ff
3: wlan0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether e4:5f:01:e2:db:85 brd ff:ff:ff:ff:ff:ff
inet 192.168.178.132/24 brd 192.168.178.255 scope global dynamic noprefixroute wlan0
valid_lft 863330sec preferred_lft 755330sec
inet6 2001:9e8:24af:4e00:ae11:1f5d:3932:f27e/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 6525sec preferred_lft 2925sec
inet6 fe80::1179:e9b1:bb7c:e89/64 scope link
valid_lft forever preferred_lft forever
4: can0: mtu 16 qdisc pfifo_fast state UP group default qlen 10
link/can
21. Okt. 2022 um 20:09
Hallo,
mein MCP2515 ist erkannt und ich kann auch die can-Schnittstelle aktivieren. Ich habe ein anderes Problem: Der chip hat Konfigurationsregister, z.B. für clock-output an weitere CAN-chips. Wenn der chip mittels dtoverlay eingerichtet wird, verschwindet /dev/spidev0.0. Ob das kernel-modul geladen wird oder nicht (habe es auf der blacklist und lade es manuell), spielt keine Rolle mehr. Ich möchte also über die SPI-Schnittstelle den chip konfigurieren (natürlich nach dem booten, vorher geht’s schlecht ;)), habe aber keinen Zugriff mehr auf das spi-device. Hat hier jemand eine Idee?
Viele Grüße,
Simon
30. Okt. 2022 um 16:49
Vermute der Treiber/Kernel wird sich hier den exklusiven Zugriff auf die SPI-Schnittstelle sichern, um eine reibungslose Kommunikation sicherzustellen.
Eventuell könnte man den Treiber anpassen, dass er das entsprechende Register beim Init mit setzt.
mcp251x Treiber:
https://github.com/torvalds/linux/blob/master/drivers/net/can/spi/mcp251x.c
Angepasster Treiber mit HW-Filter:
https://github.com/craigpeacock/mcp251x
30. Mrz. 2023 um 9:02
Hallo Peter,
ich habe mal eine einfache (dumme) Frage.
ich möchte mit einem Raspi zero mit einer
Platine MCP 2515 mit TJA 1050 ( die billigen Platinen die man bei ebay für 3 EUR bekommt) betreiben.
Geht das überhaupt ? die hat nur ein 5 V Anschluss.
Die teuren Platinen haben ein 3,3 V und 5V anschluss !
mfg
auch Peter
30. Mrz. 2023 um 10:49
Hallo auch Peter ,
wie Rainer schon geschrieben hat, bräuchtest du dabei dann noch einen Levelshifter für die Datenleitungen, der die Anpassung zwischen 5V und 3,3V macht. Einfacher wäre auf jeden Fall ein Modul, dass direkt mit 3,3V auf den Datenleitungen arbeitet.
30. Mrz. 2023 um 9:09
Hallo auch Peter,
ich weiss jetzt zwar nicht wie Tolerant der der Zero mit 5V Volt ist, aber ein 5V Versorung, eine DC-DC 5V zu 3,3V (gibt es kleine mit Festspannung) und ein 5 zu 3,3V vice versa Wandler sollten alles lösen
Gruß
Rainer
30. Mrz. 2023 um 9:54
Hallo Rainer,
danke für die Info !
Ich habe keine Anleitung im Netz gefunden wo einer ein Raspi (2,3,4 oder zero )
mit dieser Platine betreibt !
Doch !!! einen
Der lötet einmal zusätzlich 3,3 V leitung an.
Das ist mir zu gefährlich ! Platine kaputt Raspi Kaputt !
da kauf ich mir lieber eine neu Platine mit zwei Anschlüssen !
(3,3V und 5 V )
mfg
auch Peter
30. Mrz. 2023 um 11:06
Hallo an Peter und Peter,
hab da nochmal nachgedacht, der MSP2515 hat ja zwei Spannungseingänge umd kann eine Pegelconvertierung. Fertig Module kann man modifizieren, siehe https://forums.raspberrypi.com/viewtopic.php?t=141052 .
War mir damals bei meiner Schaltung noch nicht klar.
Gruß
Rainer
10. Apr. 2023 um 10:03
Hallo ihr beiden Peter(se),
fertige Canmodule mit 3V3 und 5V gibt es unter anderem bei Reichelt.
https://www.reichelt.de/entwicklerboards-can-modul-mcp2515-mcp2562-debo-can-modul-p239277.html
oder bei ELV
https://de.elv.com/joy-it-can-modul-mit-spi-interface-252241
aber leider sind sie recht teuer.
Wer sich intensiver mit Hausautomation über Can auseinandersetzen möchte,
dem empfehle ich diese sehr sehr gute DOKU :
http://doku.canathome.de/
@PETER — thx für den IOB-CanAdapter…
lg
Kalli