Warn on DBC signal name usage across multiple messages #132
Conversation
sophokles73
force-pushed
the
prevent_usage_of_duplicate_signal_names
branch
from
141e6ca
to
88d72bd
Compare
…sages During startup, the DBC Feeder reads in CAN message definitions from arbitrary database files. When using the same signal name in different message definitions, care needs to be taken that the semantics of the signal are the same across all messages. The DBC Feeder has been changed to detect such cases and issue a corresponding warning if the signal is being mapped to a VSS datapoint. Signed-off-by: Kai Hudalla <[email protected]>
sophokles73
force-pushed
the
prevent_usage_of_duplicate_signal_names
branch
from
88d72bd
to
b16c193
Compare
| dbcfile: str, | ||
| mappingfile: str, | ||
| dbc_default_file: str, | ||
| candumpfile: str = None, |
There was a problem hiding this comment.
Mypy check fails in CI, here I believe that it want optional[str] as typehint
dbcfeeder.py:138: error: Incompatible default for argument "candumpfile" (default has type "None", argument has type "str") [assignment]
dbcfeeder.py:138: note: PEP 484 prohibits implicit Optional. Accordingly, mypy has changed its default to no_implicit_optional=True
Briefly looked through other chanegs and think it looks good as soon as the mypy errors are addressed. Seems most could be fixed by type annotations with optional. Maybe some of them would require extra tweeks, please let me know if you need help or want me to address the mypy issues @sophokles73
|
Conflicts now as well |
|
We are migrating CAN Provider (dbcfeeder) to a new repo. Discussion may continue in this PR, but there is no point in updating this PR, if so rather create a new PR in the new repository. |
|
@sophokles73 - I think it would be bad if we would loose this PR. Do you intend to work something on it within the next months, or should I try to do some work to make it up-to-date for the new repo? |
|
@erikbosch let me see if I find the time to migrate the PR to the new repo ... |
|
@erikbosch I have rebased this PR locally. Once #122 has been migrated to the new repo, I will recreate the PR in the new repo ... |
|
I created a new issue in the new repo, see eclipse-kuksa/kuksa-can-provider#8 |
During startup, the DBC Feeder reads in CAN message definitions
from arbitrary database files. When using the same signal name in
different message definitions, care needs to be taken that the semantics
of the signal are the same across all messages.
The DBC Feeder has been changed to detect such cases and issue a
corresponding warning if the signal is being mapped to a VSS datapoint.
This addresses #122