Implement the ECU-CONFIG category #428
Conversation
this is used for variant coding. Signed-off-by: Andreas Lauser <andreas.lauser@mercedes-benz.com> Approved-by: Christian Hackenbeck <christian.hackenbeck@mercedes-benz.com>
whereas issues == "non-spec compliant behaviour in .odx-e files". That said, to me it rather seems like these two issues are mistakes in the spec... Signed-off-by: Andreas Lauser <andreas.lauser@mercedes-benz.com> Approved-by: Christian Hackenbeck <christian.hackenbeck@mercedes-benz.com>
Signed-off-by: Andreas Lauser <andreas.lauser@mercedes-benz.com> Approved-by: Christian Hackenbeck <christian.hackenbeck@mercedes-benz.com>
Signed-off-by: Andreas Lauser <andreas.lauser@mercedes-benz.com> Approved-by: Christian Hackenbeck <christian.hackenbeck@mercedes-benz.com>
| for sdg in self.sdgs: | ||
| result.update(sdg._build_odxlinks()) | ||
|
|
||
| return result |
There was a problem hiding this comment.
A bit off topic, but maybe _build_odxlinks, _resolve_odxlinks and _resolve_snrefs, can be simplified but have one function called _get_referenceable(self) -> list[Optional[LinkableElement]], that return all the objects that should have _build_odxlinks, _resolve_odxlinks and _resolve_snrefs called on them, the rest of the logic can be implemented in the base class.
There was a problem hiding this comment.
I guess the "leafs" of _build_odxlinks() should be moved into IdentifiableElement (#425). For resolving the references, I don't really see a good alternative to the current solution. Maybe we can introduce a proxy class like weakref.proxy but I'm not sure if this such a terribly good idea as it is quite "magical"...
|
|
||
| # at most one of the following two attributes is not None | ||
| datafile: Datafile | None = None | ||
| data: str | None = None |
There was a problem hiding this comment.
Maybe add helper method that returns actual data from either data or datafile ?
There was a problem hiding this comment.
good idea. this lead to me falling into a pretty deep rabbit hole about some arcane file formats for specifying flash blobs (Intel-HEX and S-RECORD/Motorola-S): 0f46228
There was a problem hiding this comment.
Don't re-invent the wheel, use https://github.com/TexZK/hexrec or https://github.com/eerimoq/bincopy/
There was a problem hiding this comment.
I'm not so sure if having a additional non-trivial dependency is a good idea (this can quickly degenerate into dependency hell like most NPM and Java projects). also, hexrec seems to have problems with one of the datasets which have been used internally at our company for ages (it raises a ValueError('non-contiguous data within range') exception). bincopy can handle the dataset, but it fills these gaps in the binary blob with 0xff bytes instead of 0x00. (That said, I'm not sure how "gaps" are supposed to be filled or if it even matters. I guess that using zeros might be advantageous, because the memory controller of the ECU's microchip might compress all-zero pages by pointing it to the same memory location...)
There was a problem hiding this comment.
also, if one needs to have more control when handling these datasets, one can always feed the "raw" data to the library of choice...
There was a problem hiding this comment.
okay, I've looked this up more closely: it seems like using 0xff as the fill bytes for gaps indeed seems to be the de-facto standard for the SREC and intel-hex formats. I thus changed the code to use the bincopy module.
|
I made the CI pass again: seems like mypy 1.16 was recently released and it looks like it is quite a bit pickier with @kayoub5: do you see any showstoppers left in this PR? |
i.e., deal with the nitty-gritty details of the Intel-HEX and Motorola-S file formats... also, provide processed versions of the values for some tags which specify a data type (ENCRYPT-COMPRESS-METHOD, VALIDITY-FOR, etc.) thanks to [at]kayoub5 for the nudge! Signed-off-by: Andreas Lauser <andreas.lauser@mercedes-benz.com> Approved-by: Katja Köhler <katja.koehler@mercedes-benz.com>
by far the biggest churn here was caused by the fact that mypy 1.16 is much pickier about distinguishing between `bytes` and `bytearray` than 1.15 is... Signed-off-by: Andreas Lauser <andreas.lauser@mercedes-benz.com>
this was meant to be as a to-do reminder. as [at]kayoub5 pointed out, this is better handled using a github issue... Signed-off-by: Andreas Lauser <andreas.lauser@mercedes-benz.com>
…-HEX data records and flash data thanks to [at]kayoub5 for bringing this up. Signed-off-by: Andreas Lauser <andreas.lauser@mercedes-benz.com>
|
@kayoub5: I switched to using the (BTW: ODX' process model for flashing is quite arcane IMO. Possibly we should add some additional logic to simplify user code w.r.t. filters, segments and all that jazz? something like: for address, blob in my_flashdata.chunks:
write_to_ecu_flash(address, blob)) |
This ODX category is used to hold variant coding information. Just like for the
FLASHcategory, the PR is relatively large, but it does not contain much logic on theodxtoolslevel.Andreas Lauser <andreas.lauser@mercedes-benz.com>, on behalf of MBition GmbH.
Provider Information