search

c4deszes / ldfparser

LIN Description File parser written in Python
https://c4deszes.github.io/ldfparser/
MIT License
64 stars 26 forks source link

Support for LIN version 1.3 "Diagnostic_addresses" token #107

Closed CsurillaK closed 2 years ago

CsurillaK commented 2 years ago

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:

c4deszes commented 2 years ago

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.

CsurillaK commented 2 years ago

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).

c4deszes commented 2 years ago

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.