CAN InteractionLayer / CANoe / Zyklisches Senden/Empfangen

[Thorben (Gast)]

Hallo, ich hab eine kleine CAN ECU Hardware gebaut und steuere diese 
mittels CANoe inklusive Panel Designer an.

Dazu hab ich eine DBC Datei mit InteractionLayer erstellt und es 
funktioniert alles wunderbar. Im CANoe Panel Designer wurden die Signale 
auf verschiedene Controls gelegt. Die CAN Frames werden zyklisch nach 
der DBC Beschreibung gesendet. Meine CAN ECU Hardware überprüft den 
Identifier und gibt den Payload entsprechend an die SPI oder I2C 
Schnittstelle.

Jetzt hätte ich gerne dazu ein paar Fragen:

- Wieso werden CAN Nachrichten in vielen Produkten zyklisch gesendet, 
reicht es nicht bei einer Änderung das Frame zusenden? Es würde doch den 
Traffic auf dem CAN Bus reduzieren oder nutzt man das Zyklischesenden 
als Deadlockerkennung?


- Wie behandelt Ihr zyklische Nachrichten, legt Ihr den Payload in ein 
Buffer und vergleicht diesen Buffer mit der Nachricht davor und wenn 
sich nix geändert hat verwerft Ihr die Daten? So würde ich es machen um 
SPI,I2C und CPU zuentlasten oder spricht etwas dagegen?

[Heinz (Gast)]

Thorben schrieb:
> Wieso werden CAN Nachrichten in vielen Produkten zyklisch gesendet,
> reicht es nicht bei einer Änderung das Frame zusenden?

In der dbc kannst du Signale onChange definieren. Dann wird nur bei 
Wertänderung geschickt.

Viele Anwendungen brauchen aber zyklische Daten um bspw. eine
Timeouterkennung durchzuführen und Ersatzreaktionen anzustossen,
Werte als veraltet zu erkennen, Funktionen einzufrieren usw...

Oft spielt auch die ISO26262 eine Rolle: Wenn bspw der Empfänger 
ASIL-Funktionen implementiert, für die er gültige und vertrauenswürdige 
Daten in ASIL-Qualität vom Sender benötigt, geht das meines Wissens nur 
mit zyklischem Senden sowie Sequenzzähler und CRC.

[Heinz (Gast)]

Thorben schrieb:
> Wie behandelt Ihr zyklische Nachrichten, legt Ihr den Payload in ein
> Buffer

Man könnte einen Buffer anlegen und ein memcmp machen oder eine CRC 
rechnen.
Ich würde vermutlich die Daten 1 zu 1 an SPI, I2C weitergeben, 
vorausgesetzt die CAN-Wiederholrate ist nicht zu hoch. 10ms Sende-Raster 
würde ich als absolut problemlos betrachten.

[Thorben (Gast)]

Danke Heinz für deine Erklärungen, damit ergibt alles einen Sinn.

[rcc (Gast)]

Thorben schrieb:
> - Wieso werden CAN Nachrichten in vielen Produkten zyklisch gesendet,
> reicht es nicht bei einer Änderung das Frame zusenden? Es würde doch den
> Traffic auf dem CAN Bus reduzieren oder nutzt man das Zyklischesenden
> als Deadlockerkennung?

Nachdem CAN per Definition nicht deterministisch ist und manchmal 
Messages einfach auch mal verloren gehen (Bus grad voll, Störung von 
außen) müsste man sich für reines onChange oft noch irgend einen 
Handshake basteln. Da ist stupide zyklisch senden der einfachere Weg. 
Der Traffic kostet ja nichts solange man den Bus nicht ans Limit fährt.