mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik "CAN - CAN Bridge" Prinzip


Autor: Armin O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Wenn ich von einem CAN Netz die Daten in ein anderes CAN Netz senden 
will und ich als Vermittler ein anderen Bus benutzte (z.B. Ethernet), 
wie gehe ich dann vor?
Meine Idee war so:

1) Lese eingehende CAN Nachricht
2) Blockiere CAN Eingang für weitere Nachrichten
3) Sende empfangene Nachricht an Ziel Netz
4) Warte auf Bestätigung, dass am Ziel Netz die Nachricht auf den Bus 
gelegt wurde (bei entsprechender Buslast kann dies etwas dauern)
5) Wenn erfolgreich arbitrierte wurde, wieder Eingang am Quell CAN 
aktivieren

So ist sichergestellt das sich keine Nachrichten anhäufen.

Wird das so gemacht?

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm...ich hab das jetzt nicht im Detail durchdacht, aber warum willst du 
den CAN sperren?

Eine Nachricht muss auf dem physical Layer so und so im ACK Bit "sofort" 
innerhalb des jeweiligen Subnetzwerkes bestätigt werden. Der Sender 
weiss also nur, dass innerhalb des Subnetzes die Nachricht definitiv 
richtig und fehlerfrei versendet wurde (oder auch nicht). Ob das Senden 
durch das Gateway ins andere Netz auch erfolgreich war kann nicht 
sichergestellt werden (oder nur durch entsprechende Programmierung in 
der darüber liegenden Anwendung).

Der einfachste Fall wäre wirklich, ein Gateway mit Ein- und 
Ausgangspuffer zu bauen, und dann alle empfangenen Daten sofort ins 
andere Netzwerk zu senden (oder zumindest auf den Ausgangspuffer zu 
legen). Wenn dabei unterschiedliche Busgeschwindigkeiten zu 
Schwierigkeiten führen können, muss man sich weitere Gedanken machen. 
Beispielsweise nur die Nachrichten "routen" die wirklich in beiden 
Subnetzen notwendig sind. Auch die darüber liegende Anwendung sollte mit 
fehlenden/verzögerten Nachrichten zurecht kommen können und tollerant 
auf solche Fehler reagieren. Achja, Echtzeit, so es sie denn bei CAN 
wirklich gibt, muss in solch einem Fall natürlich nochmal untersucht 
werden.

Torsten.

Autor: Armin O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du meinst es gibt ein Problem, wenn die Nachricht im Ziel Netz nicht 
gesendet werden kann (warum auch immer), und trotzdem schon am Quell 
Netz ein ACK gegeben wurde?

Autor: Armin O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meine Überlegung wäre sinnvoll z.B. bei folgendem Szenario:

Quell-Netz: Anwender sendet "Motor an" und irgendwann wieder "Motor 
aus".
Also 2 verschiedene CAN Nachrichten.

"Motor aus" kann jedoch nur abgeschickt werden wenn "Motor an" am Ziel 
bestätigt wurde, sonst gibt es kein ACK und der Benutzer versucht 
solange bis es endlich klappt.

Mit Puffern kann es passieren dass "Motor an" und danach sofort "Motor 
aus" hinternander folgen.

Ich frage mich nur inwieweit der Benutzer mitkriegt dass es für eine 
Nachricht kein ACK gab. Wahrscheinlich garnicht.

Angenommen der Sendeknoten sendet unaufhörlich (bis ein ACK kommt) und 
der Benutzer entscheidet ein anderes Siganl zu senden. Reiht dich das 
"andere Signal" hinten dran (FIFO) oder wird das vorherige Signal 
einfach storniert und mit dem neuen überschrieben?

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn wir von "ACK" reden, reden wir dann von dem CAN-Bus-ACK-Bit oder 
von einem aus der Anwendung???

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Mit Puffern kann es passieren dass "Motor an" und danach sofort "Motor
aus" hinternander folgen."

Wie schnell kann denn "Motor aus" auf "Motor an" folgen? Selbst wenn man 
einen Puffer hat, sollte sich das gesamte Senden im Millisekundenbereich 
abspielen, wenn nicht, dann sollte man das ganze Design noch mal 
überdenken.

Torsten.

Autor: Armin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit "ACK" meine ich das CAN-Bus-ACK-Bit

Autor: Armin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn ich die Puffer am Ausgang verwende, solltes dann ein FIFO sein?
Die CAN Nachrichten schicke ich dann in der Reihenfolge wie sie vorher 
empfangen wurden.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK. Also das ACK Bit muss während das Datenpaket gesendet wird gesendet 
werden. Man kann damit nicht warten bis es über Ethernet gesendet wurde 
und dann auf dem Ziel-Bus empfangen wurde. Das ACK ist wirklich nur dazu 
da, um die Übertragung der Nachricht innerhalb des Subnetzes 
abzusichern. Alles andere musst du über deine Applikation und weitere 
Nachrichten machen (z.B. Bestätigungsnachricht, wenn der Motor an oder 
aus ist). Eine Andere Möglichkeit ist es, ständig (alle 100ms) den 
aktuellen Zustand (ein/aus) zurück zu senden und anzuzeigen, damit weiss 
der Nutzer immer über den aktuellen Status bescheid (Status-LED oder 
Display...).

Ja ich würde ein FIFO verwenden, damit kann zumindest die Reihenfolge 
der Nachrichten eingehalten werden (nochmal: Zeitbedingungen können 
massiv durcheinander gewürfelt werden!!), aber zum Ein/Ausschalten des 
Motors sollte es reichen.

Endlich WE :-)
Torsten.

Autor: Dietmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit dem ACK-Bit im CAN-Frame kann man nicht wirklich viel anfangen, denn 
innerhalb der CAN-Bus-Topologie senden alle CAN-Knoten, die noch am Bus 
sind, ein ACK auf eine Message. Für den Sender kann das nur noch soweit 
ausgewertet werden, als daß er noch am Bus teilnimmt und irgend einer 
ihn empfangen hat. Denn, der CAN-Bus ist broadcastfähig.

Gruß

Dietmar

Autor: Dietmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Armin:

Wie echtzeitfähig ist denn so ein Ethernet?

Ich muß gestehen, daß ich von Ethernet überhaupt keine Ahnung habe, 
Echtzeitfähigkeit, vom CAN-Bus hingegen schon. Auch wenn meine 
CAN-Bus-Applikation nicht alle Möglichkeiten ausreizt, die eine 
CAN-Applikation haben kann.

Zu 1:) bis 7:) Blockieren auf gar keinen Fall. Ich habe in allen 
CAN-Knoten ein RX- und TX-FIFO implementiert.

>So ist sichergestellt das sich keine Nachrichten anhäufen.

Da werden die Messages so schnell sie können abgearbeitet. FIFO 
deswegen, um keine Message zu verlieren, anstatt Blockieren. Auch für 
ein CAN-Gateway macht das Sinn.

Wie sind denn die maximalen Reaktionszeiten, d.h., von der 
CAN-Steuer-Message bis zur Antwort an den CAN-Knoten, der die Auslösung 
verursacht?

Das wird sicher in CAN-Messages mit spezifizierten Identifiern verpackt 
werden müssen.

Also:
Sende CAN-Message an einen CAN-Controller mit Ethernet-Bridge

Warte auf eine CAN-Acknowledge-Message vom CAN-Controller mit 
Ethernet-Bridge

Dabei ist die Acknowledge Message eine Antwort vom Ziel-CAN-Controller 
mit spezifiziertem CAN-Identifier hinter der Ethernet-Bridge an den 
Quell-CAN-Controller mit spezifiziertem CAN-Identifier vor der 
Ethernet-Bridge.

Gruß

Dietmar

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.