Forum: Mikrocontroller und Digitale Elektronik CAN-Netzwerk mit XE16x, Verteilung der MessageObjekte


von Holger B. (rst-el)


Lesenswert?

Hallo,

ich plane ein CAN-Netzwerk zwischen einer Zentralsteuereinheit (Master) 
und 64 IO-Einheiten (Slaves). Der Informationsaustausch ist gegliedert 
in folgende Nachrichtengruppen:
EINGÄNGE
AUSGÄNGE
Meldeaufforderung vom Master an die Slaves (Broadcast)
Rückmeldung von den Slaves zum Master

Für den Master verwende ich den XE167 von Infineon. Dieser unterstützt 
128 Message Objekte (MO).

Damit ich mit diesen klarkomme habe ich folgendes überlegt:

Senden:
Beim Senden der Telegramme (AUSGÄNGE) vom Master zu den Slaves reicht 
mir ein M0 im XE167, welches ich vor dem Senden mit dem jeweiligen 
Identifier beschreibe. Das heißt, ich kann alle Slaves ansprechen mit 
nur einem Message Objekt im Master.

Empfangen:
Die Slaves arbeiten ereignisgesteuert, senden also nur bei Bedarf Infos 
zum Master. Es kann also passieren, daß mehrere Slaves ihre 
Eingangszustände gleichzeitig übertragen wollen. Damit hier keine 
Telegramme verlorengehen, muß für jeden Knoten eine eigene Nachricht 
reserviert werden. Das heißt, die zu übertragenen Objekte der Knoten 
müssen je einen eigenen Identifier erhalten. Das würde bedeuten, ich 
benötige im XE167 64 MO für die EINGÄNGE.

Ich weiß jetzt nicht genau, wie ich das mit der Reaktion der Slaves auf 
die Meldeanforderung vom Master realisieren soll. Die vom Master 
gesendete Meldeaufforderung hat einen Identifier, welcher von allen 
Slaves gelesen wird. Daraufhin sollen sich diese beim Master melden. Ich 
denke, ich muß hierfür dieselben M0 verwenden wie für die EINGÄNGE, da 
ich keine weiteren 64 Identifier mehr frei habe, um für jeden Slave eine 
eigene Nachricht für die Knotenrückmeldung zu reservieren.

Hat jemand eine bessere Idee bzw. entsprechende Erfahrungen?

Gruß Holger

von TManiac (Gast)


Lesenswert?

Hallo Holger,

Ich verstehe deinen letzten Absatz nicht ganz. Haben die Slaves zwei 
Arten von Nachrichten die sie verschicken? Einmal eine 
Ereignisgetriggerte, wei du sie im Absatz "Empfangen" beschreibst. Und 
eine zweite, welche so zusagen die Reaktion auf die Anfrage vom Master 
ist?

Du kannst auf alle Fälle in einer Messagebox (MO) mehrere CAN-Ids 
annehmen. Jedes MO hat ein Overflow flag, wenn du nur zwei Ids auf ein 
MO appst erkennst du also recht zuverlässig welche ID verloren 
gegegangen ist.
Man könnte aber auch per PEC eine eingegangene Nachricht sehr schnell 
aus dem MO heraus holen und danach bearbeiten.

Noch als Tip: man könnte das Senden mit einer HW-Queue aus MOs (es sind 
ja noch welche übrig) vereinfachen und sicherer gestalten.

Was aber ein anderes Problem noch ist: Willst du wirklich 65 CAN-Knoten 
an einem Bus betreiben. Mir fehlt kein Transceiver ein der das 
zuverlässig schafft. Da der XE167 aber 4 Nodes hat könnte man den als 
Gateway/Master nutzen und verteilt die 64 Slaves auf vier getrennte 
(nicht zwingend symetrische) Busse.

Gruß,
TManiac

von Holger B. (rst-el)


Lesenswert?

Hallo TManiac,
erstmal Danke für Deine Tips ! Das mit den 64 Knoten muß ich mal mit
unserem Hardwareentwickler besprechen.

Zur Software:
Du hast das richtig verstanden. Ich habe geplant, daß die Slaves 2 Arten
von Nachrichten haben:
a) Ereignisgetriggert
b) Bestätigungstelegramm als Reaktion auf eine Masteranfrage

Und wegen b) habe ich jetzt folgendes Problem:
Das Bestätigungstelegramm sollen alle Slaves zum Master schicken, sofern
dieser eine entsprechende Anfrage gesendet hat. Das heißt, es werden im
Worst Case zeitgleich 64 Telegramme von den Slaves gesendet - als
Reaktion auf eine Masteranfrage.
Hierbei muß jedes Telegramm mit einem eigenen Identifier versehen
werden, damit über die Arbitrierung sichergestellt wird, daß alle
Telegramme ordnungsgemäß zum Master gelangen. Wenn die Nachricht zum
Master von allen Slaves mit demselben Identifier versehen wäre, kann die
Arbitrierung meiner Meinung nach nicht funktionieren.

Im Master selbst hätte ich kein Problem, wenn die Telegramme auf ein MO
sehr schnell nacheinander eintreffen, da über einen FIFO-Puffer
sichergestellt ist, daß keine verloren geht.

Eventuell kann ich auch auf diese Anfragebestätigungen der Slaves ganz
verzichten.

Zum CAN allgemein habe noch eine generelle Frage:
Das Protokoll an sich bietet ja eine hohe Fehlersicherheit. Ist es da
erforderlich, daß irgendwelche Bestätitungen auf eingegangene Telegramme
versendet werden oder kann davon ausgegangen werden, daß ein fehlerfrei
abgesendetes Telegramm auch beim Empfänger ankommt ?

Wie wird das allgemein in CAN-Netzwerken gehandhabt?

Gruß Holger

von (prx) A. K. (prx)


Lesenswert?

Holger Betz schrieb:

> Telegramme ordnungsgemäß zum Master gelangen. Wenn die Nachricht zum
> Master von allen Slaves mit demselben Identifier versehen wäre, kann die
> Arbitrierung meiner Meinung nach nicht funktionieren.

Korrekt. Aber üblicherweise sind CAN Controller in der Lage, die 
Handhabung gleichartiger aber aus besagtem Grund verschieden 
nummerierter IDs über eine Bitmaske zusammenzufassen. Dann ist das nur 
noch ein Objekt, sind nicht mehr 64. Ist dann nur noch ein Tempoproblem, 
weil der Controller die fix genug abfischen muss (evtl. können die 
Slaves mit zufälligem oder aus der ID abgeleitetem Delay antworten).

von TManiac (Gast)


Lesenswert?

Hallo Holger,

Laut CAN Spec muss sowieso jeder verschiedenartige Nachricht eine eigene 
ID haben (Multiplexnutzung ausgenommen). Ist ja auch klar, weil die ID 
ja den Inhalt der Nachricht beschreibt.

Die ganzen Bestätigungen über einen FIFO abzufangen ist natürlich auch 
eine Möglichkeit. Du brauchst aber auch für den FIFO mehrere MOs (je 
nach Größe) aber eben nicht unbedingt 64 Stück. Deine 64 Antworten 
werden ja wegen der Arbitierung nicht zeitgleich eintreffen, sondern 
schön den IDs folgenden (wenn alle Slaves gleich schnell sind).

Die Bestätigung über den Bit-Richtigen Erhalt einer CAN-Nachricht ist in 
der Hardware schon integriert. Das heißt der Sendende Knoten weiß schon 
bevor er das letzte Bit gesndet hat, ob die Daten korrekt bei mindestens 
einem Empfänger angekommen sind und das kein Empfänger die Daten als 
fehlerhaft erkannt hat.
Du könntest also deinen angedachten Bestätigungsmechanismus direkt zur 
Bestätigung zur Bearbeitbarkeit der Anforderung (Ähnlich dem UDS 
Protokoll im Fahrzeugsektor) nehmen.

Gruß
TManiac

Bitte 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
Noch kein Account? Hier anmelden.