Project

General

Profile

Actions

Support Request #13288

closed

Doubled defintion in DDL regarding CAN/CAN FD and differences between struct and media description regarding SOME/IP

Added by hidden about 3 years ago. Updated about 2 years ago.

Status:
Closed
Priority:
Normal
Customer:
AUDI
Department:
EF
Requester's Priority:
Normal
Support Level:
3rd Level
Resolution:
Product Issue Opened
Affected Products:
Platform:
Windows 10 64bit
Topic:
ADTF::MediaDescription
FAQ Links:

Description

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.

Actions #2

Updated by hidden about 3 years ago

  • Status changed from New to In Progress
Actions #3

Updated by hidden about 3 years ago

  • Author changed from hidden to hidden
Actions #4

Updated by hidden about 3 years ago

  • File deleted (image001.png)
Actions #5

Updated by hidden about 3 years ago

Hallo Claudia,

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.

Die Produkttickets werden in einer zukünftigen Version gelöst.

Viele Grüße Pierre

Actions #6

Updated by hidden about 3 years ago

  • Status changed from In Progress to Customer Feedback Required
Actions #7

Updated by hidden about 3 years ago

Hi Pierre,

vielen Dank für die Lösungsvorschläge.

Sonderbehandlungen sind nicht besonders toll, daher habe ich mir überlegt, dass ich nicht die DDL zum im "md_struct" angegebene Struct ermittel, sondern dass in der ConfigDatei das property "md_definitions" mit dem korrekten Struct befüllt wird (also tSomeIpSampleHeader").
Dies hat gleichzeitig den Vorteil, dass ich nur die DDL ermittel, wenn das property "md_definitions" in der Config auch gesetzt ist. Sonst hätte ich nämlich wieder Probleme mit Streams, welche dieses Property gar nicht haben - z.B. Image oder Audi Stream.

Das Ticket kannst du jetzt gern schließen :)

Viele Grüße
Claudia

Actions #8

Updated by hidden about 3 years ago

  • Project changed from 11 to Public Support
  • Description updated (diff)
  • Status changed from Customer Feedback Required to To Be Closed
  • Private changed from Yes to No
  • Resolution set to Product Issue Opened
  • Product Issue Numbers set to https://www.cip.audi.de/jira/browse/ADEVTB-1925; https://www.cip.audi.de/jira/browse/ADEVTB-1924
  • Support Level changed from 2nd Level to 3rd Level

Hallo Claudia,

Actions #9

Updated by hidden about 3 years ago

Hallo zusammen,

ich hoffe, es ist ok, wenn ich nochmal in diesem Ticket was zum Thema frage...

Wir haben mit der Definition der StreamTypes nun doch noch ein Problem, da mein Workaround nicht für Kollegen aus anderen Projekten funktioniert.
Aktuell fragen wir uns auch, in wie weit, ADTF künftig noch die .description Dateien verwendet bzw. in welche Richtung sich diese entwickeln werden und ob es sinnvoll ist, euer DDL-Format für unsere Config zu nutzen.

Die Schilderung unserer derzeitigen Probleme im Detail ist per Mail eher schwierig. Wäre es möglich mit euch zusammen mal eine Telko zu machen?

Viele Grüße
Claudia

Actions #10

Updated by hidden about 2 years ago

  • Status changed from To Be Closed to Closed
Actions

Also available in: Atom PDF