CAN InteractionLayer / CANoe / Zyklisches Senden/Empfangen

Gast #6333027
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?
Gast #6333082
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.
Gast #6333084
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.
Gast #6333215
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.

Antwort schreiben

Eine eigene Frage? Dieser Thread ist über 6 Jahre alt. Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.

Neuen Thread starten

Eine Lösung, Ergänzung oder Rückmeldung zu diesem Thread? Dann antworte hier.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.