diaglayer: refactor the communication parameter handling #142
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
andlaus
force-pushed
the
untangle_diaglayer_4
branch
from
6b0799e
to
8192544
Compare
it turns out that the names of the communication parameters are not unambiguous: e.g., "CP_UniqueRespIdTable" parameter is not so unique in the sense that it exists for CAN (comparam subset "ISO_15765_2") as well as for DoIP (CP subset "ISO_13400_2_DIS_2015") and both parameters have a completely different definition. (The same issue applies to e.g., "CP_TesterPresentTime", but this being a simple integer parameter, at least the returned value is of the same type.) To get out of that pickle, the full parameter ID now has to be specified for `DiagLayer.get_communication_parameter()` (e.g., "ISO_15765_2.CP_UniqueRespIdTable"). Signed-off-by: Andreas Lauser <andreas.lauser@mbition.io> Signed-off-by: Gerrit Ecke <gerrit.ecke@mbition.io>
andlaus
force-pushed
the
untangle_diaglayer_4
branch
from
8192544
to
37eba3a
Compare
kayoub5
reviewed
Jun 12, 2023
kayoub5
reviewed
Jun 12, 2023
|
@kayoub5: do you see any problems with this? |
…he comparams this is rather unfortunate because we have to rely on the stars to align correctly (only a single comparam of a given name must be defined for an individual (protocol, is_functional) combination) to retrieve the correct comparam. Unfortunately the IDs of comparams (and the comparam subsets?) do not seem to be sufficiently standardized accross the vendors to rely on them (CANdela and the comparams that are shipped with the standard us the convention <COMPARAM_SUBSET>.<COMPARAM_NAME> as their convention for IDs, other editors seem to use random strings)... thanks to [at]kayoub5 for pointing this out. Signed-off-by: Andreas Lauser <andreas.lauser@mbition.io> Signed-off-by: Gerrit Ecke <gerrit.ecke@mbition.io>
kayoub5
reviewed
Jun 14, 2023
we reverted back to short names... thanks to [at]kayoub5 for the catch. Signed-off-by: Andreas Lauser <andreas.lauser@mbition.io> Signed-off-by: Gerrit Ecke <gerrit.ecke@mbition.io>
andlaus
force-pushed
the
untangle_diaglayer_4
branch
from
c353954
to
594154d
Compare
kayoub5
approved these changes
Jun 15, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This continues the long quest to clean up
DiagLayer:it turns out that the names of the communication parameters are not unambiguous: e.g., "CP_UniqueRespIdTable" parameter is not so unique in the sense that it exists for CAN (comparam subset "ISO_15765_2") as well as for DoIP (CP subset "ISO_13400_2_DIS_2015") and both parameters have a completely different definition. (The same issue applies to e.g., "CP_TesterPresentTime", but this being a simple integer parameter, at least the returned value is of the same type.)
To get out of that pickle, the full parameter ID now has to be specified for
DiagLayer.get_communication_parameter()(e.g., "ISO_15765_2.CP_UniqueRespIdTable").Andreas Lauser <andreas.lauser@mercedes-benz.com>, on behalf of MBition GmbH.
Provider Information