Public Support

Supportanfrage

Ich habe wie vorgeschlagen (siehe #12513#note-12) den User in einer Config-Datei den Struct-Namen angeben lassen. Aus einer DDL wird dann das property "md_definitions" extrahiert.
Das funktioniert gut, solange ich nicht bestimmte StreamTypes gleichzeitig in der DDL haben will.

Konkret gibt es Probleme, wenn man CAN und CANFD in der DDL nutzt. Da beide das Enum "eDataFlags" nutzen. Dieses Enum hat bei CANFD jedoch ein Element mehr als bei CAN. Somit erstelle ich für eines der beiden immer ein falsches "md_definitions" und in meinem StreamType-Check wird dieser Stream dann abgelehnt.
Da mein Filter generisch sein soll, kann ich intern nicht einfach auf die "md_definitions" Definition für CAN oder CANFD aus der Devicetoolbox gehen. Allerdings fällt mir aktuell auch keine sinnvolle Lösung ein, wie ich das Problem mit der doppelten Definition von "eDataFlags" in einer DDL lösen kann.
Habt ihr hierfür Tipps?

Ein weiteres Problem habe ich mit dem SomeIP Typen. Laut der Beschreibung in der Devicetoolbox (3.3.0) ist "md_struct" bei diesem Typen "tSomeIpSampel". Im "md_definitions" wird das Struct jedoch "tSomeIpSampleHeader" genannt.
Mein Filter würde folglich nach dem Struct "tSomeIpSampel" suchen, es nicht finden und somit eine falsche "md_definitions" erstellen.
Ist diese ungleiche Benennung des Structs von euch beabsichtigt oder ein Versehen, was künftig noch behoben wird?
Wenn es so bleibt, müsste ich wohl die Anpassung des Namens hardcoden. Dies fände ich allerdings äußerst unschön. Daher würde ich mich über eine Anpassung freuen. Cool wären dann auch unterschiedliche Enum-Namen bei CAN und CANFD :)

Lösung

Thema 1: tCANFDData / tCANData und eDataFlags ...
Du hast recht, das ist an der Stelle wirklich unglücklich. Ich habe dafür ein Ticket erstellt: https://www.cip.audi.de/jira/browse/ADEVTB-1925.
Das werden wir ändern. Bis dahin habe ich folgenden Workaround für dich:

• Mehrere DDL Dateien verwenden, die der Nutzer angeben kann. Dann kommen sich diese nicht gegenseitig in die Quere. Der Code, den ich Dir geschickt hatte im letzten Ticket ist fähig dazu, da innerhalb von ADTF auf den Streamtypen und deren MediaDescription immer getrennt voneinander betrachtet werden.
• Du "patched" du immer zu den Typ des Enums "eDataFlags" von tCANFDData bevor Du den Vergleich machst bzw. bevor Du den StreamType auf den Input oder Output Pin setzst

Thema 2: tSomeIpSample / tSomeIpSampleHeader
Das ist wirklich besonders unglücklich. Ich habe auch dafür ein Ticket erstellt: https://www.cip.audi.de/jira/browse/ADEVTB-1924.
Als Workaraund kann ich leider nur eine Sonderbehandlung vorschlagen momentan, sodass du in deinem Code tSomeIpSample und tSomeIpSampleHeader als synonyme behandelst.