Hallo,
wie kann man über den CAN-Bus eine Adressierung realisieren. WEnn ich es
richtig verstanden habe, tragen alle Nachrichten eindeutige Identifier.
Diese Identifier regeln auch automatisch die Priorität der Nachricht (je
kleiner die numerische ID, desto höher die Priorität).
Angenommen ich habe ein Touchscreen, welches Eingabedaten für
verschiedene Geräte liefern kann, wie könnte ich denn sicherstellen,
dass eine Nachricht die für Gerät A gedacht ist, nicht von Gerät B
misinterpretiert wird.
Soweit ich gelesen habe, hat man im CAN-Netz keine Adressen, sondern der
Verkehr wird über die Identifier geregelt. Jeder hört alle Nachrichten
mit und kann anhand der Identifier relevante Nachrichten an höhere
Schichten weiterleiten.
1) Wer legt denn die Identifier fest?
2) Kann es passieren, dass zwei Nachrichten den gleichen Identifier
tragen?
3) Ist der Identifier unique für jede Nachricht oder beschreibt es eher
einen Nachrichten-Typ? Ich würde letzteres vermuten.
4) Wer schickt die ACK-Nachrichten? Nur die Knoten, die an den
Nachrichten interessiert waren oder alle Knoten, die generell eine
nicht-fehlerhafte Nachricht erhalten.
Weiterhin vermute ich, dass eine richtige Adressierung auf höhere
Schicht erfolgen muss? Also jeder Knoten bekommt eine eindeutige
Adresse. Ein Frame könnte eine Sender und Empfängeradresse tragen...Gibt
es da schon CAN-Protokolle für?
Haben eigentlich CAN-Geräte üblicherweise eine Nachrichten-Buffer? Was
passiert, wenn ein CAn-Gerät zu viele Anfragen bekommt und mit dem
Verarbeiten der Nachrichten/ Antworten nicht hinterher kommt?
Daniel Specht schrieb:> WEnn ich es richtig verstanden habe, tragen alle Nachrichten eindeutige> Identifier.
Ja.
> Diese Identifier regeln auch automatisch die Priorität der Nachricht (je> kleiner die numerische ID, desto höher die Priorität).
Ja.
> Angenommen ich habe ein Touchscreen, welches Eingabedaten für> verschiedene Geräte liefern kann, wie könnte ich denn sicherstellen,> dass eine Nachricht die für Gerät A gedacht ist, nicht von Gerät B> misinterpretiert wird.
Die ID dient nicht dazu, Quelle und Ziel zu definieren, sondern den
Inhalt. So kann z.B. die CAN-ID 0x123 die Temperatur enthalten, die ID
0x321 den Status aller Tasten eines Nummernblocks. Von dem Inhalt hängt
natürlich ab, wer sie dann tatsächlich sendet, also beim Tastenstatus
eine Tastatur, bei der Temperatur eben der Temperatursensor. Ziel ist,
wer immer sich für den Inhalt der Botschaft interessiert. Das ist dem
Absender aber wurscht. Es wird quasi immer ein Broadcast gemacht.
> Soweit ich gelesen habe, hat man im CAN-Netz keine Adressen, sondern der> Verkehr wird über die Identifier geregelt. Jeder hört alle Nachrichten> mit und kann anhand der Identifier relevante Nachrichten an höhere> Schichten weiterleiten.
Ja.
> 1) Wer legt denn die Identifier fest?
Du.
> 2) Kann es passieren, dass zwei Nachrichten den gleichen Identifier> tragen?
Was meinst du mit "zwei Nachrichten"? Du kannst natürlich eine Nachricht
mit einer bestimmten ID beliebig oft schicken, aber wenn du Werte mit
unterschiedlichen Bedeutungen hast, sollten die Botschaften auch
unterschiedliche IDs haben.
> 3) Ist der Identifier unique für jede Nachricht oder beschreibt es eher> einen Nachrichten-Typ? Ich würde letzteres vermuten.
Ja.
> 4) Wer schickt die ACK-Nachrichten? Nur die Knoten, die an den> Nachrichten interessiert waren oder alle Knoten, die generell eine> nicht-fehlerhafte Nachricht erhalten.
Kommt drauf an, wie du "interessiert" definierst. Der CAN-Controller
schickt das ACK automatisch. Du kannst also nicht bei einer Botschaft
sagen, daß du da kein ACK drauf schickst. Die CAN-Controller haben aber
meistens Message-Filter eingebaut, die dafür sorgen, daß gar nicht alles
Botschaften weitergereicht werden. Auf die rausgefilterten erfolgt
meines Wissens kein ACK.
> Weiterhin vermute ich, dass eine richtige Adressierung auf höhere> Schicht erfolgen muss?
Eine Adressierung sollte im Normalbetrieb nicht nötig sein, sonst ist
CAN eher der falsche Bus.
> Also jeder Knoten bekommt eine eindeutige Adresse. Ein Frame könnte eine> Sender und Empfängeradresse tragen...Gibt es da schon CAN-Protokolle für?
Es gibt Transportprotokolle für sowas. Damit könntest du sogar
IP-over-CAN machen. Aber wenn du das für die reguläre Kommunikation
brauchst, ist das irgendwie eine Zweckentfremdung des CAN.
> Haben eigentlich CAN-Geräte üblicherweise eine Nachrichten-Buffer?
Das kann ganz unterschiedlich sein. Manche Controller haben "Mailboxen",
also für jede ID, die empfangen werden soll, einen Puffer, so daß der
jeweils aktuelle Wert für den Inhalt jeder Botschaft gespeichert ist.
Andere haben einen kleinen Zwischenpuffer für ein paar Nachrichten. Um
die ID-Aufteilung muß man sich dann selber kümmern.
> Was passiert, wenn ein CAn-Gerät zu viele Anfragen bekommt und mit dem> Verarbeiten der Nachrichten/ Antworten nicht hinterher kommt?
Dann gehen sie eben verloren.
zu 4.) jedes Gerät, dass eine Nachricht empfängt, setzt das Akn-Bit.
Egal ob der Frame für dieses Gerät bestimmt war oder nicht. (also egal
ob die Filter im CAN-Controller die Nachricht zum µC durchlassen oder
nicht)
Vielen Dank für die Antworten.
zu 4)
Ich verstehe den Sinn des ACK-Bits net so richtig.
Wenn alle Empfänger eine ACK-Nachricht schicken, dann hilft es dem
Sender der ursprünglichen Nachricht nur soweit, dass er davon ausgehen
kann, dass seine verschickte Nachricht fehlerhaft war/ verloren gegangen
ist, wenn er im Prinzip überhaupt keine ACK-Nachricht bekommen hat.
Ob eine Nachricht von einem bestimmten Knoten empfangen wurde, kann
damit nicht festgestellt werden oder?
Zu 1) Auf welcher Schicht werden die Identifier festgelegt? Kann ich auf
der Applikationsschicht einen Identifier beliebig legen? Kann ich den
Identifier eine Nachricht auf der Applikationsschicht auch lesen oder
wird dieser an die Applikationsschicht gar net weitergegeben?
Daniel Specht schrieb:> Wenn alle Empfänger eine ACK-Nachricht schicken, dann hilft es dem> Sender der ursprünglichen Nachricht nur soweit, dass er davon ausgehen> kann, dass seine verschickte Nachricht fehlerhaft war/ verloren gegangen> ist, wenn er im Prinzip überhaupt keine ACK-Nachricht bekommen hat.
Genau dazu ist es ja auch da.
> Ob eine Nachricht von einem bestimmten Knoten empfangen wurde, kann> damit nicht festgestellt werden oder?
Nein. Wie gesagt interessiert sich der Absender gar nicht dafür, wer
genau es empfängt. Nur daß es empfangen wurde, interessiert ihn. Es gäbe
ja nicht mal eine Möglichkeit, einen Empfangsknoten zu identifizieren,
das es ja keine Adressen gibt.
> Zu 1) Auf welcher Schicht werden die Identifier festgelegt? Kann ich auf> der Applikationsschicht einen Identifier beliebig legen?
Ja.
> Kann ich den Identifier eine Nachricht auf der Applikationsschicht auch> lesen oder wird dieser an die Applikationsschicht gar net weitergegeben?
Klar. Woher sollst du sonst wissen, was du mit dem Inhalt der Botschaft
anfangen sollst?
Daniel Specht schrieb:> Ob eine Nachricht von einem bestimmten Knoten empfangen wurde, kann> damit nicht festgestellt werden oder?
Dafür müsste man dann schon ein Protokoll aufm CAN fahren, also z.B.
Request-Response oder sowas in der Art.
> Ob eine Nachricht von einem bestimmten Knoten empfangen wurde, kann> damit nicht festgestellt werden oder?
Oder du guckst Dir das Thema CANopen mal an. Dort gibt es für jeden
Teilnehme eine (mehrere) CAN-ID.
Aber die Festlegung, das eine CAN-ID den Inhalt der Nachricht
beschreibt, kommt ja aus dem Entwicklungsgebiet des CAN: Auto.
Du kannst diese IDs doch frei vergeben und tun was du willst auf deinem
CAN-Bus.
Dieter M. schrieb:> zu 4.) jedes Gerät, dass eine Nachricht empfängt, setzt das Akn-Bit.> Egal ob der Frame für dieses Gerät bestimmt war oder nicht. (also egal> ob die Filter im CAN-Controller die Nachricht zum µC durchlassen oder> nicht)
Wobei manche einen stillen Modus unterstützen, in dem sie wirklich nur
lauschen und nichts (auch kein ACK) auf den Bus legen. Empfangen haben
sie die Nachricht dann trotzdem. Aber mindestens ein Teilnehmer im Bus
muss das ACK setzen, sonst wird die Nachricht wiederholt (je nach
Einstellung).
Rolf Magnus schrieb:>> Haben eigentlich CAN-Geräte üblicherweise eine Nachrichten-Buffer?>> Das kann ganz unterschiedlich sein. Manche Controller haben "Mailboxen",> also für jede ID, die empfangen werden soll, einen Puffer, so daß der> jeweils aktuelle Wert für den Inhalt jeder Botschaft gespeichert ist.> Andere haben einen kleinen Zwischenpuffer für ein paar Nachrichten. Um> die ID-Aufteilung muß man sich dann selber kümmern.>>> Was passiert, wenn ein CAn-Gerät zu viele Anfragen bekommt und mit dem>> Verarbeiten der Nachrichten/ Antworten nicht hinterher kommt?>> Dann gehen sie eben verloren.
Gibt es eigentlich eine Möglichkeit um den Zugriff auf ein bestimmtes
Steuergerät zu regeln?
Angenommen ich hab Steuergerät A,B,C,D.
B,C,D wollen ständig irgendwelche Information und broadcasten
Requestnachrichten, die nur A beantworten kann. A kann aber zeitgleich
nicht mehrere Anfragen beantworten...gibts eine Möglichkeit damit A
nicht überflutet wird? Meine erste Idee wäre, A hat einen großen Buffer
und speichert die ganzen Requests, so wie sie eintreffen und beantwortet
sie eins nach dem anderen. Eine andere Idee wäre eine
verbindungsorientierte Kommunikation. B,C,D müssen erst eine Session mit
A aufbauen, damit sie Daten austauschen können. Nur wenn eine Verbindung
ausgehandelt wurde, erfolgt der eigentlich Datenaustausch. Die
restlichen Steuergeräte warten solange, bis der Kanal frei wird und
versuchen wieder eine Verbindung aufzubauen. Gibts im CAN-Bus
irgendwelche Mechanismen hierzu?
Daniel Specht schrieb:> Gibts im CAN-Bus> irgendwelche Mechanismen hierzu?
Nein. Du hast immer noch nicht verstanden was ein CAN-Bus ist, wie er
funktioniert und wozu man ihn braucht.
Vielleicht ist CAN nicht das richtige für dich.
Daniel Specht schrieb:> Gibt es eigentlich eine Möglichkeit um den Zugriff auf ein bestimmtes> Steuergerät zu regeln?
CAN selbst bietet dazu keine Möglichkeit.
> Angenommen ich hab Steuergerät A,B,C,D.> B,C,D wollen ständig irgendwelche Information und broadcasten> Requestnachrichten, die nur A beantworten kann.
Normalerweise wird das so umgesetzt, daß A seine Daten einfach
regelmäßig sendet oder immer dann wenn sie sich ändern. Im Auto würde
dann z.B. das Steuergerät, an dem der Außentemperatursensor hängt,
einfach einmal pro Sekunde die Temperatur-Botschaft senden. Angefragt
werden muß da nichts.
> Eine andere Idee wäre eine verbindungsorientierte Kommunikation. B,C,D> müssen erst eine Session mit A aufbauen, damit sie Daten austauschen> können. Nur wenn eine Verbindung ausgehandelt wurde, erfolgt der> eigentlich Datenaustausch.
Im Fahzeug gibt es z.B. für das Flashen von Steuergeräten Protokolle wie
ISO_15765-2. Aber das gibt es nur für solche Sonderfunktionen. Im
Regelbetrieb wird das nicht genutzt.
> Die restlichen Steuergeräte warten solange, bis der Kanal frei wird und> versuchen wieder eine Verbindung aufzubauen. Gibts im CAN-Bus> irgendwelche Mechanismen hierzu?
Nein. Du versuchst hier offenbar, CAN für etwas anzuwenden, wofür es nie
gedacht war.
Hi
Ja, sowas gibt es z.B. in J1939 oder umfassender im darauf aufbauenden
ISO 11783. CAN war zwar nicht für sowas gedacht aber es wird trotzdem
gemacht und funktioniert. Genauso wie Ethernet nicht für
Maschinensteuerungen gedacht war. Es wird trotzdem dafür verwendet.
Matthias
Hi,
da wir hier im Mikrocontroller-Forum sind, solltest du deine
"Appliktionsschicht" mal beschreiben. Oft ist das der direkte Zugriff
auf die Register des CAN-Controllers im Mikrocontroller (oder per
SPI-angebunden, oder oder oder). Wenn du wirklich Angst hast, dass deine
Kommunikation zu schnell für einen Teilnehmer ist und dieser nicht in
der Lage ist alle Nachrichten abzuarbeiten, dann musst du selbst einen
Zwischenspeicher im RAM anlegen. Beispielsweise auf neue Nachrichten per
Interrupt reagieren, die Daten dann schnell aus den Registern des
CAN-Controllers in den Ram kopieren (z.B. ein Ringspeicher) und dann
diesen "langsam" abarbeiten.
Da der CAN mit seinen maximal 1MBit/s aber zur Zeit nicht soo schnell
ist (CAN FD ist noch nicht so verbreitet) und dann auch noch der
Großteil der Daten weggeschmissen wird, sollte eine overload so schnell
auch nicht auftreten.
Achja, wenn du inhaltlich nur PUnkt-zu-Punkt Verbindungen hast, dann
kannst du für dich ja die CAN-ID als Zieladresse deuten, falls du damit
besser zurecht kommst. Auch könntest du durch eine Aufteilung des
Identifiers eine Art Quelle und Ziel definieren. Ein Teilnehmer liest
dann alle Nachrichten die ein bestimmtes Muster in der Adresse haben.
Das ist dann glaube ich, so wie CANopen (weiter oben bereits von jmd.
erwähnt).
Zum ACK:
Es geht für den einzelnen Knoten nur um die Information "Hänge ich
(noch) am Bus" bzw. "Ist irgendjemand da, der mich empfängt".
Wenn er eine Message sendet und irgendjemand schickt ein ACK, dann gibt
es zumindest noch einen anderen Teilnehmer, der erreichbar ist, und um
mehr geht es auch gar nicht.
Da der CAN nicht für Sender-Empfänger-Kommunikation gedacht ist, bekommt
man kein ACK von einem bestimmten Empfänger, sondern quasi "vom Bus".
Der Sinn davon ist es, dass bei ausbleibendem ACK der Knoten aufhört,
aktiv auf den BUS einzuwirken. Damit soll vermieden werden, dass ein
einzelner Knoten, der irgendein Problem hat, den ganzen Bus blockieren
kann.
Es geht also nicht darum, dass Knoten A sicher gehen kann, dass seine
Messages richtig ankommen, sondern dass der Bus vor marodierenden Knoten
geschützt wird.
