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!
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.
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.
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.
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?
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 ;).
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.
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.
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
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.
! 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.
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.
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.
@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.
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.
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.
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/CanOpenMonitorhttps://github.com/CANopenNode/CANopenNodehttps://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
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
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
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
Announcement: there is an English version of this forum on 
Thread beobachten
Seitenaufteilung abschalten