mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Funktion eines CAN to Ethernet Gateway ?


Autor: Der Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Der Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
eigentlich geht es um CAN nach .... Gateway. Es muss kein Ethernet sein.
Wie geht man mit dem ID um?

Autor: Der Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mist...kennt sich niemand aus?
Welche Infos fehlen von meiner Seite ?

Autor: m4444x (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Der Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gut. Diese Methode ähnelt Lösung 2 von mir.
Danke.

Autor: Der Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo m4444x

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

Autor: Philipp Co (ba4_philipp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Der Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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



Autor: Philipp Co (ba4_philipp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: m4444x (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: m4444x (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Der Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: m4444x (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hansi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
12*128Bit = 192Byte stimmt ja garnicht. den CRC Block kann ich ja 
abrechnen. Müsste dann ja etwas weniger Platz beanspruchen.

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habt ihr das realisiert, dass eingehende Remote Frames beantwortet 
werden? Ich stelle mir das etwas schwierig vor. Geht das überhaupt?

Autor: m4444x (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ö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.

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]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [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.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

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