Announcement: there is an English version of this forum on 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.
Dann bau doch einfach ein CAN zu UART Interface. Das ist ein µC + 2 Transceiver und ein bisschen Hühnerfutter.
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.
Um ggf. für die Zukunft gerüstet zu sein sollet auch über FDCAN nachgedacht werden.
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.
Wenn Du was über CAN lernen willst, hole dir einen USBtin, von https://www.fischl.de/usbtin/ Da gibt es auch Sniffingsoftware.
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
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
Edgar S. schrieb: > Diese ganze Vectorgelumpe braucht man wirklich nicht Es hilft aber zugegebenermaßen sehr beim Debuggen und Testen.
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.