Funktion eines CAN to Ethernet Gateway ?

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)

Gut. Diese Methode ähnelt Lösung 2 von mir.
Danke.

hallo m4444x

geht es eigentlich auch umgekehrt? UDP-Frame nach CAN ?
Wie geht man dort mit dem Identifier um?

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

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.

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.