c4deszes / ldfparser

LIN Description File parser written in Python

Home Page:https://c4deszes.github.io/ldfparser/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Support for LIN version 1.3 "Diagnostic_addresses" token

CsurillaK opened this issue · comments

I have a LIN (protocol version 1.3) database with the standard-compliant "Diagnostic_addresses" token (see LIN Specification Package 1.3: 7.5 - Node Diagnostic Address definition), to which "ldfparser.parse_ldf()" throws an "UnexpectedToken" exception (ldfparser version 0.16.0).

To me, "grammars/ldf.lark" only seems to support LIN specification 2.1, with no support for backward incompatible (?) version 1.3 tokens like "Diagnostic_addresses".

To Reproduce:

  1. Try to parse a protocol version 1.3 LDF database file which contains the "Diagnostic_addresses" token.

Expected behaviour:

  1. The tool should be able to parse the database file.

Environment:

  • OS: Windows 10
  • Python: 3.7
  • ldfparser: 0.16.0

Started working on a PR that resolves this issue, the grammar part is already done so installing that version should get rid of the errors pip install git+https://github.com/c4deszes/ldfparser.git@feature/diagnostic-addresses. With this if you're using the LDF to JSON feature you can already access these attributes.

What's remaining is loading these values into Python objects and I'm not yet sure where these properties should be set, partially due to the lack of documentation about diagnostics in LIN 1.3. I would also want to make sure that the APIs are not that different for older style LDFs, but maybe they have to be.

Thank you for the quick reply!

If it helps you come up with a minimal viable release, I would be happy with only the node/frame/signal content of the database, and capturing the diagnostics part in a wildcard format (or ignoring it completely).

Fix has been released in 0.17.0, the diagnostic addresses are loaded under the intial_nad and configured_nad attributes. I would have liked to separate the node classes for 1.3 and 2.0+ standards but it would have made some incompatible changes, so this is going to be changed once the library is out of the prerelease state.