ARXML: fix determining signal lengths their initial value and its range #242
Conversation
|
No tests needed? |
|
as usual, coverage results are strange, but this time in a different sense: there's a significant regression in `arxml.py'. I'll fix that tomorrow... |
actually, there are, but I screwed up a bit: I put the these tests into the patch for autosar 3 (next PR) and surgically separated these patches later, while not adding proper tests for this to the existing AR4 infrastucture. sorry for the mess, I'll fix it ASAP. |
|
Great work overall! |
|
Btw, which features in cantools are Daimler using? |
|
@andlaus Any updates? |
|
I think, the fixing took longer. Because of other work, it will probably be mid-January until a follow-up. Sorry for the delay. Oliver Kopp oliver.kopp@mbition.io, Mercedes-Benz AG on behalf of MBition GmbH. |
|
Ok! |
a1cf940
to
297900f
Compare
|
ok, I finally managed update this. Note that I'm not 100% sure if determining the initial value of signals is correct (it is certainly not complete because it only includes the saner ways), but at least the |
297900f
to
f2e1804
Compare
this is kind of pointless as a stand-alone change, but it will be necessary for ARXML-3 because AR3 supports specifying a lot of data which AR4 expects in the ISignal via the system signal. Besides this, make ignoring references to system signal groups more explicit...
f2e1804
to
a99af19
Compare
|
@eerimoq : I guess this PR is ready to go in. I have no idea where the huge drop in coverage asserted by coveralls is supposed to come from: the PR only touches |
I can't speak for Daimler as a whole, but I personally use it to read the bus description files for various vehicles. Once the database object is read, it depends on the concrete application: sometimes I need to generate C++ code to decode frames, convert the descriptions to some simpler formats (like e.g. DBC) and sometimes I use the decoded data directly in python for some calculations. Overall I'm quite impressed by the overall code quality of cantools :) |
This only supports specifying the numerical value in the I-SIGNAL as well as a reference to to constant in the I-SIGNAL. There seem to be quite a few additional methods which remain unsupported. As far as I'm concerned, this is *way* too complicated in ARXML. Also note that I do not really have any tools to verify that these values are specified correctly. I verified that system-4.2.arxml still validates against the XSD for autosar 4.3, but this seems to only be a necessary precondition for correctness, not a sufficient one...
a99af19
to
57af083
Compare
This PR continues the quest for ARXML-3 support, cf https://github.com/andlaus/cantools/tree/arxml_refactor
This PR adds support for determining the length of a given signal via the system signal if the length is not specified by the i-signal itself (first patch), it corrects determining the possible range of signals (second patch; the possible value range of the signal is the range over all COMPU-SCALEs, not just the first one) and it implements loading the initial value of signals (third patch).
The next PR will contain the changes for the differences between ARXML-3 and ARXML-4.
Andreas Lauser andreas.lauser@mbition.io, Mercedes-Benz AG on behalf of MBition GmbH.
Imprint