Forum: Fahrzeugelektronik Aufwand für CAN-Sniffer


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Michael B. (user_m)


Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,
ich habe folgende Anforderung, aber leider mit CAN keinerlei 
Erfahrungen. Gegeben sind zwei CANs:
- CANOpen -Bus
- CAN mit J1939
Auf beiden soll gesniffert werden, um spezielle Datenpakete 
herauszufischen und diese auf einem anderen Weg weiterzuleiten. Senden 
ist nicht notwendig und soll hardwaretechnisch unterdrückt werden. Ich 
würde gerne einfach nur mitlesen und vorgegebene Bitmuster erkennen und 
abgreifen.
Vorhanden ist ein LPC1830-FreeRTOS-System mit 2 UARTs. An denen könnten 
2 Transceiver (z.B. MCP2551) angeschlossen werden.
Genügt dies, um die heraus zu lesenden Records zu erkennen oder muss 
jeweils das komplette Protokoll implementiert werden?
Ist es sinnvoll oder notwendig, zusätzlich je einen CAN Controller (z.B. 
MCP2515) dazwischen zu schalten?

Vielleicht kann mir jemand von den CAN-Fachleuten hier etwas 
Orientierung geben. Wie würdet ihr vorgehen?

Danke!

von temp (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Michael B. schrieb:
> Vorhanden ist ein LPC1830-FreeRTOS-System mit 2 UARTs. An denen könnten
> 2 Transceiver (z.B. MCP2551) angeschlossen werden.
> Genügt dies, um die heraus zu lesenden Records zu erkennen oder muss
> jeweils das komplette Protokoll implementiert werden?
> Ist es sinnvoll oder notwendig, zusätzlich je einen CAN Controller (z.B.
> MCP2515) dazwischen zu schalten?

Meinst du ernsthaft du kannst einen MCP2551 an einen UART anschließen? 
Der LPC1830 hat 2 CAN-Controller, also auf keinen Fall sind da noch 
externe Controller nötig. Wie du das was du empfängst weiter 
transportieren willst, hast du auch noch nicht verraten. Vom Prinzip her 
besteht jede Nachricht ja nur aus einer Id und 0-8Byte Daten. Die 
spannende Frage ist halt ob du schon Ahnung vom konkreten Protokol hast 
oder nicht. Das reicht von einfach bis ziemlich komplitiert. Willst du 
ein Firmwareupdate über CAN belauschen und interpretieren ist das was 
anderes als wenn in einer Nachricht mit einer bestimmten ID simple 
Sensorwerte übertragen werden.
Wenn du hier mit 0 Ahnung einsteigst, würde ich wenigstens einen 
USB-CAN-Adapter mal kaufen um das Henne-EI-Problem zu umgehen.

von Harald (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Michael B. schrieb:
> 2 UARTs. An denen könnten
> 2 Transceiver (z.B. MCP2551)

Du hast vermutlich RX und TX gesehen. Das hat aber mit UART nichts zu 
tun. CAN ist komplett anders aufgebaut.

von Florian (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Kauf dir ein Lawicel Interface vom Chinesen

von Thomas F. (igel)


Bewertung
1 lesenswert
nicht lesenswert
Michael B. schrieb:
> Vorhanden ist ein LPC1830-FreeRTOS-System mit 2 UARTs. An denen könnten
> 2 Transceiver (z.B. MCP2551) angeschlossen werden.

UART ist nicht CAN! Die Transceiver müssen schon an die CAN-Pins CANx-RD 
und CANx-TX angeschlossen werden.

> Genügt dies, um die heraus zu lesenden Records zu erkennen oder muss
> jeweils das komplette Protokoll implementiert werden?

Das reicht so aus. Allerdings muss da trotzdem noch einiges zum CAN 
programmiert werden.

von Michael B. (user_m)


Bewertung
0 lesenswert
nicht lesenswert
Danke, das hilft mir tatsächlich schon weiter. RX und TX habe ich 
tatsächlich so verstanden, dass man da mit UART ran gehen kann und die 
Bits geliefert bekommt, die auf dem CAN unterwegs sind. Wie gesagt, 
keine Ahnung, soll aber was dazu sagen...
Von den beiden CAN-Ports im LPC1830 ist nur einer nutzbar, beim zweiten 
sind die Ports bereits anders belegt. Weiterhin weiß ich auch nicht, ob 
mit der dafür angegeben CAN 2.0 Spezifikation auch CANOpen und J1939 zu 
machen ist.
Ja, es geht um Sensorwerte, angeblich reicht ID und data aus.
Zum Hintergrund: Bei einer Baumaschine werden bisher die Daten per 
USB-Stick gesammelt und von Hand in eine Zentrale gebracht. Andererseits 
gibt es ein GPRS/LTE-Funkmodul mit LPC1830 (bisher ohne CAN), das sich 
bidirektional mit der Zentrale verbinden könnte. Das sollte dann "auf 
Zuruf" mit dem Sniffern anfangen, die ausselektierten Frames übertragen 
und auf Kommando dann wieder aufhören können. Zu prüfen ist der Aufwand 
für die Anbindung.
Meine UART-Illusion war, dass ich dort über die SIO den Bitstream 
bekomme und diesen dann nach den gewünschten IDs absuche. Ohne das 
Protokoll als ganzes zu implementieren. Wahrscheinlich zu naiv, oder?

von Paul (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Kauf dir ein PEAK CAN und lerne erstmal den Protokollaufbau kennen.

Schritt zwei ist dann die Implementierung auf dem µC.

Den Peak CAN brauchst du auch zum debuggen, wenn es auf dem µC mal nicht 
so läuft ;).

von temp (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Michael B. schrieb:
> Ja, es geht um Sensorwerte, angeblich reicht ID und data aus.

Wenn du die eine odere mehrerer IDs schon kennst ist es relativ trivial.

Nochmal (und zu letzten mal): Wie sollen denn die Daten wohin geschickt 
werden? UART, Ethernet, WLAN oder was weiss ich? Übers Internet?
Da wird dann wohl auch die Hauptaufgabe drin liegen. Das bischen CAN ist 
da nur Nebensache. Ohne weitere Infos keine Hilfe.

von Michael B. (user_m)


Bewertung
0 lesenswert
nicht lesenswert
Sorry "temp", das Weiterleiten ist überhaupt kein Problem. Der ganze 
Teil ist fertig, es handelt sich um ein Modul, das analoge und digitale 
Eingänge sowie zwei UARTs hat, diese überwacht, Zustandsänderungen 
speichert und per GPRS/LTE an ein Gateway schickt. Das funktioniert 
alles. Im Grunde geht es darum, sowas wie einen "CAN-Sensor" daran 
anzuschießen. Für die UART ist sowas bereits implementiert: wenn 
bestimmte Zeichenfolgen darauf erkannt werden, werden diese ausgewertet 
und abgeschickt. Ich kann das gerne weiter beschreiben, aber ich wollte 
hier niemanden mit Daten belästigen, die er in diesem Zusammenhang gar 
nicht haben will.

von Kevin M. (arduinolover)


Bewertung
1 lesenswert
nicht lesenswert
Dann bau doch einfach ein CAN zu UART Interface. Das ist ein µC + 2 
Transceiver und ein bisschen Hühnerfutter.

von BerndB (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Du benötigst warscheinlich für jeden CAN BUS einen eigenen CAN 
Controller von deinem µC. Dann fängst Du die passenden IDs ab und 
verarbeitest die weiter.

Gruß Bernd

von NichtWichtig (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Dann nimm halt einen weiteren µC mit 2 CAN Interfaces und konzentrier 
Dich da nur auf den CAN Teil.
Ergebnisse von dort dann per UART an den bereits vorhandenen.

Selbst son kleiner BluePill bläst am UART mit fast 1MBaud, das sollte 
reichen.

Denk dran es galvanisch getrennt zu machen CAN Transeiver floaten da so 
vor sich hin.
Damals wurde das mit DCDC-Wandler und Optokopplern gemacht, heute finden 
man wohl schon integrietre Chips.

Ein PC-CAN Interface ist empfehlenswert, bieten einige Hersteller doch 
passende Viewer - oder man schreibt sich eben einen selbst was auch 
nicht wirklich problematisch ist. (Wenn man denn GUIs programmieren 
kann)


Und es ist löblich unnützes Zeug beim Beschreiben weg zu lassen, auch 
wenn hier manche ohne alle Hintergründe keinen Rat raus lassen 
wollen/können.

von Michael B. (user_m)


Bewertung
0 lesenswert
nicht lesenswert
! DANKE ! Leute, ich habe jetzt Licht im Dunkeln. Werde euren 
Vorschlägen genauer nachgehen und überlegen, welche Strategie die beste 
für die vorgegebene Situation ist. Ein PC-CAN Interface und das 
Beobachten der Signale erscheint mir unverzichtbar. Allerdings wird das 
mit dieser Baumaschine wohl irgendwelche Simulatoren benötigen.

von NichtWichtig (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Wenn Du einen µC gewählt hast beachte etwaige Erratas, beim LPC2119 gab 
es damals bei CAN derbe Einschränkungen bzgl. gebotenen Möglichkeiten 
und deren Fehlerfreiheit.
Ich mußte dann wohl eine Empfangsqueue selber bauen weil die Hardware 
nicht zuverlässig nutzbar war.

Unterm Strich lief CAN aber absolut unauffällig solang Bitrate zu 
Kabellänge paßte.

von Kevin M. (arduinolover)


Bewertung
0 lesenswert
nicht lesenswert
Um ggf. für die Zukunft gerüstet zu sein sollet auch über FDCAN 
nachgedacht werden.

von Thomas F. (igel)


Bewertung
2 lesenswert
nicht lesenswert
Michael B. schrieb:
> Ein PC-CAN Interface und das
> Beobachten der Signale erscheint mir unverzichtbar. Allerdings wird das
> mit dieser Baumaschine wohl irgendwelche Simulatoren benötigen.

Auch die Simulation eines CAN-Busses am Schreibtisch - ohne Baumaschine 
-kann man mit einem PEAK PCAN machen. Für die Software-Entwicklung fast 
unverzichtbar.

von TestX (Gast)


Bewertung
2 lesenswert
nicht lesenswert
@TO

Dein Problem sind nicht die rohen CAN Daten sondern J1939 und CANOpen - 
das sind ziemliche Protokoll-Monster (und "open" sind die nicht 
wirklich) - insbesondere da du dazu noch die jeweiligen Dictionaries der 
zu überwachenden Geräte benötigst um Daten auszulesen.

Habe soetwas ähnliches mal vor ca. 10Jahren gemacht und ohne die nötigen 
Entwicklungstools (VECTOR CANoe) war es absolut unmöglich den Software 
Stack zu entwickeln.

von Bentschie (Gast)


Bewertung
3 lesenswert
nicht lesenswert
Thomas F. schrieb:
> UART ist nicht CAN! Die Transceiver müssen schon an die CAN-Pins CANx-RD
> und CANx-TX angeschlossen werden.

Prinzipell hast Du recht. Bei Can braucht es auch als reiner Empfänger 
den TX  um das Ack zus setzen sonst gibt es einen Fehler.

Da er aber nur passiv lauschen will, könnte es auch sinnvoll sein den TX 
am Transceiver hart auf inaktiv zu klemmen. Das hat den Vorteil, das er 
mit seiner Software den Bus nicht stören kann. Ich würde es zumindest so 
machen.

von Kevin M. (arduinolover)


Bewertung
2 lesenswert
nicht lesenswert
Bentschie schrieb:
> Da er aber nur passiv lauschen will, könnte es auch sinnvoll sein den TX
> am Transceiver hart auf inaktiv zu klemmen. Das hat den Vorteil, das er
> mit seiner Software den Bus nicht stören kann. Ich würde es zumindest so
> machen.

Dafür wurden Transceiver mit Silent Mode erfunden....
Außerdem kann jeder halbwegs anständige CAN Controller onehin im Silent 
Mode betrien werden.

von Sven L. (sven_rvbg)


Bewertung
0 lesenswert
nicht lesenswert
Wenn Du was über CAN lernen willst, hole dir einen USBtin, von 
https://www.fischl.de/usbtin/

Da gibt es auch Sniffingsoftware.

von Klaus D. (Firma: MHS-Elektronik GmbH & Co. KG) (mhs-elektronik)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael

- CANOpen -Bus
- CAN mit J1939
Bist Du dir bei den Protokollen wirklich sicher ?
CANOpen stammt aus der Industrie und J1939 aus dem
Nutzfahrzeuge Bereich, zwei vollkommen unterschiedliche
Anwendungsbereiche.

J1939 ist eigentlich sehr einfach aufgebaut, bei CANopen wirds da wenn
Du aus dem SDO Verzeichnis lesen musst schon etwas komplizierter.

Infos zu J1939:
https://rbei-etas.github.io/busmaster/
https://github.com/MHS-Elektronik/J1939Display
Die beiden Programme kannst Du mit einen Tiny-CAN betreiben.

für CANopen:
https://github.com/robincornelius/CanOpenMonitor
https://github.com/CANopenNode/CANopenNode
https://canfestival.org/

Selbst ein wenig auf Github suchen, da gibt es eigentlich einiges

Wenn Du bei CANopen keine EDS Files für deine Hardware bekommst wirst Du
da nicht glücklich werden.

Grüße
Klaus

von Michael B. (user_m)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Klaus,
ja, das ist leider die Anforderung. Es handelt sich um große 
Baumaschinen, auf denen diese beiden BUS-Systeme parallel im Einsatz 
sind. Und beide sollen gesniffert werden. Zurzeit geht es noch um 
Machbarkeit und Aufwand. Das Telemetriegerät ist vorhanden, kann aber 
kein CAN - und ich auch nicht. Aber mit Hilfe der vielen Hinweise und 
Ratschläge hier habe ich jetzt schon eine erste Vorstellung, was da auf 
mich zukommen würde.

Danke, auch an alle anderen!
Michael

von neubi (Gast)


Bewertung
-2 lesenswert
nicht lesenswert

von Edgar S. (Firma: keine) (heinbloed1)


Bewertung
2 lesenswert
nicht lesenswert
TestX schrieb:
> @TO
>
> Dein Problem sind nicht die rohen CAN Daten sondern J1939 und CANOpen -
> das sind ziemliche Protokoll-Monster (und "open" sind die nicht
> wirklich) - insbesondere da du dazu noch die jeweiligen Dictionaries der
> zu überwachenden Geräte benötigst um Daten auszulesen.
>
> Habe soetwas ähnliches mal vor ca. 10Jahren gemacht und ohne die nötigen
> Entwicklungstools (VECTOR CANoe) war es absolut unmöglich den Software
> Stack zu entwickeln.

Das meinst Du nicht wirklich. Ich habe 20 Jahre lang Stacks für CANOpen,
DeviceNet und SAEJ1939 entwickelt und hatte nie mehr als einen 
Peakadapter.
Diese ganze Vectorgelumpe braucht man wirklich nicht

von rcc (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Edgar S. schrieb:
> Diese ganze Vectorgelumpe braucht man wirklich nicht

Es hilft aber zugegebenermaßen sehr beim Debuggen und Testen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.