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.
Im Auto werden die CAN-Botschaften übrigens meist periodisch wiederholt. Je nachdem alle 5ms bis alle 10s.
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
Nochmal zum ACK. Der 0-Pegel ist Dominant. Was bedeutet, wenn ein Empfänger kein ACK gibt, dass auch kein ACK im Frame existiert.
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.
Hat ein Knoten (in Error Active) die Nachricht falsch verstanden, ist er nicht still, sondern sendet ein Error Frame.
Hier gibts eine gute Einführung zum Thema CAN und auch CAN FD: https://elearning.vector.com/vl_can_introduction_de.html
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.