Grüß Gott Ich will ein Gateway bauen um von CAN auf Ethernet zu kommen und auch umgekehrt. Meine offene Frage ist eigentlich nur wie die beste Strategie ist, möglichst zeitsparend die Konvertierung zu machen. Es sollte ja verschiedene Möglichkeiten geben: 1. Gateway-Funktion in einem festen Zyklus ausführen (z.B. x millisekunden) D.h. Während des "Wartens" alle eingehenden CAN Nachrichten im Puffer sammeln. Bei Warte-Ende prioritätsweise die Nachrichten behandelt auf je 1 Ethernet Frame konvertierenund absenden. Danach die zweitwichtigste CAN Nachricht usw. 2. Bei jeder eingegangenenn CAN Nachricht gleich den Konvertierunszyklus aufrufen. IDs werden dabei nicht beachtet. Es wird immer die gesendet die sich gerade am CAN durchgesetzt hat. Ich denke dass diese Methode langsamer ist. Gibt es weitere Strategien? Auf dem Markt sind sehr viele dieser Umsetzter aber man weis ja nicht wie diese im inneren funktionieren. Vielleicht liege ich auch mit meinen 2 Vorschlägen komplett daneben...
eigentlich geht es um CAN nach .... Gateway. Es muss kein Ethernet sein. Wie geht man mit dem ID um?
mist...kennt sich niemand aus? Welche Infos fehlen von meiner Seite ?
Ich mach es so: eingehende CAN Nachrichten werden in einem Puffer gespeichert sobald der Puffer nicht leer ist und der Ethernet NIC bereit ist zum senden werden die Nachrichten im Puffer in ein UDP Datagram verpackt und abgeschickt Funktioniert bisher tadellos. (CAN Bus 125kBps, Ether 10MBps full duplex, AVR 4MHz, Puffer mit bis zu 16 Nachrichten)
hallo m4444x geht es eigentlich auch umgekehrt? UDP-Frame nach CAN ? Wie geht man dort mit dem Identifier um?
Hallo m4444x, wie hast du das mit Ethernet gelöst? Habe momentan eine CAN <-> RS232 Lösung. Hast du den Ethernet Controller von Microchip verwendet? Gruß Philipp
Hi Philipp Hast du deine CAN <-> RS232 Version selbst entwickelt? Wie hast du das gemacht? V.a. Rs232->CAN interessiert mich. Nimmst du dann ein Terminal programm? Welche Parameter übergibst du? xiao Hans
Ich habe einen Mega8 genommen und ein MCP2515. Ich benutze das ganze für meinen CAN Bus im Auto. Die Paramter sind deshalb fest. Der Bus läuft mit 125kbit/s und der UART mit 115k2. Das Protokoll ist binär um nicht nochmehr Bandbreite zu verlieren. Ich sende 2 Bytes als Startcode, dann kommen 2 Byte für ID, 1 Byte für RTR und Length und dann die Datenbytes am Ende kommen noch 2 Bytes die das ganze abschließen. Senden funktioniert genauso. Am PC läuft ein kleines Programm zu dem man sich per TCP/IP verbinden kann und so die CAN Nachrichten erhält und auch welche senden kann. Leider ist die PC Software noch nicht sonderlich gut. Gruß Philipp
Hallo, der LPC2368 sollte für dich ein interessanter Chip sind. Der Preis mit knapp 8 Euro ist ganz ok. Der LPC2368 bietet CAN2.0, Ethernet, USB uvm., falls der interne Ram nicht ausreicht koennte man auf den LQFP144 ausweichen und ein externes Sram anschliessen. Ich wuerde die CAN Messages per Interrupt in ein Array (FIFO) legen und wenn Zeit ist einfach die Daten auf das Ethernet geben.
Angehängte Dateien:
-
can_gateway.jpg
130 KB
Hier mal ein Bild von meinem CAN Gateway. Hardware ist im wesentlichen von Ulrich's Webserver übernommen hab bloß zusätzlich noch den MCP2515 drangehöngt. Als Software hab ich den Netzwerkstack der Procyon AVRLib bis hinauf zu UDP und einen selbstgebastelten Treiber für den CAN Chip eingespielt. Hab' schon überlegt die riesige Netzwerkkarte durch einen ENC28J60 zu ersetzen. Dann wirds aber eventuell etwas zu eng auf dem SPI Interface. LPCxy ist für mich keine Option (zu viele zu kleine Pins). Eventuell wäre so ein PIC mit CAN von Microchip interessant.. jetzt hab ich mich aber schon auf die AVRs eingestellt und bin zu faul nen neuen Compiler zu installieren.
Die empfangenen CAN-Frames nach Prioritäten umsortieren würde ich nicht. Bei einigen Protokollen wie z.B. CANopen ist die Reihenfolge der Nachrichten sehrwohl von Bedeutung.
Wenn Du die Prioritäten richtig verteilst müsste das sortieren schon möglich sein. (Message A muß vor Message B auf den Bus: also bekommt A eine höhere Priorität) Aber im Grunde hast Du schon recht. Am einfachsten und sichersten ist es wohl die Nachrichten in der gleichen Reihenfolge auszugeben in der sie empfangen wurden. Also beim MCP2515 zum Beispiel nur einen der drei TX Register verwenden.
Ich wöllte es so machen, dass ich einen festen Zyklus habe um die CAN Nachrichten abzuholen. Ich sage mal beispielhaft Zyklus = 3ms. Jetzt überlege ich wie groß ich das Datasegment festlege. Das hängt doch davon ab wieviele CAN Nachrichten in den 3ms maximal eintreffen können oder? wenn ich von 500kbps ausgehe und im Worst Käse Fall nur Extended Frames bekomme, dann errechnet sich die Dauer eines eingehenden Frames: Extended Frame Länge = 128 Bit (mit 8 DataBytes) Dauer= 128Bit/500kBit/s = 256µs In 3ms können sich dann 11,72 also 12 Frames maximal ansammeln. D.h. ich lege meinen Nutzbereich (z.B. im Ethernet Frame) auch auf maximal 12*128Bit = 192Byte. Sieht jemand einen Fehler in der Denksweise?
Könnte schon funktionieren. Allerdings musst du dann sicherstellen dass der NIC nach den 3ms auch wirklich bereit ist zum Senden. Wenn wir beim Beispiel CAN over UDP bleiben könnte es ja passieren dass gerade zu dem Zeitpunkt ein ARP Request eintrudelt. Außerdem würden bei dieser Methode alle Nachrichten im Mittel um 1,5ms verzögert. Musst Du überlegen ob das was ausmacht bei Deiner Anwendung.
12*128Bit = 192Byte stimmt ja garnicht. den CRC Block kann ich ja abrechnen. Müsste dann ja etwas weniger Platz beanspruchen.
Habt ihr das realisiert, dass eingehende Remote Frames beantwortet werden? Ich stelle mir das etwas schwierig vor. Geht das überhaupt?
Öhm, der Gateway sollte ja eigentlich die Nachrichten erstmal einfach nur weiterleiten. Egal ob RTR oder nicht. Wenn es ein bidirectionaler Gateway ist sehe ich kein Problem mit RTR Frames. Eventuell müsste man nochmal überprüfen wie das mit dem Auto-Answer-Modus geregelt ist. Aber so wie ich das verstanden hab tut der Controller dann einen neuen Frame mit der Antwort erzeugen und der wird dann vom Gateway wieder weitergeleitet.
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.