ludubies / flashcontainer Goto Github PK

Adding a count to an xml field element would introduce the field X times in the struct.
This would allow for the efficient creation of larger arrays without repeating field tags and cluttering the file.

Parsing would only need to handle the additional naming of the singular fields (numbering?)

CrcParameter has an attribute crc_cfg that contains a CrcData object that has an attribute crc_cfg that contains a CrcConfig object...........
Look for clearer naming

CRC access is currently using bit specification (8, 16, 32 or 64).
This could imply that other values might be valid, a byte based specification (1, 2, 4 or 8) could remedy that

Host the new XSD once its not pending any more changes and adjust source from local to hosted.

Currently only start and end address definition for crcs is possible.
Because all fields are named, the CRC parsing could also work with a list of names.
CRC would then be calculated over listed fields. Could be slightly easier as defining address ranges in some cases.

Struct CRCs can currently only compute for data that is "before" them.
Parameter CRCs are currently used only in the same way, although the usage for later memory would in theory be possible.

Structs introduce more complexity as parameters need to reference them.
Working only with th XmlParser class leads to bloated function arguments.
Using an XmlParser instance for parsing would allow keeping references in the parser attrs

implement a CRC field, necessary for aurix bootmode headers,

need new XSD, new XML parsing, datamodel extension, writer extension

With Array, Padding and CRC fields, types have become abundant.

Review current approach (separate implementation for fields and parameters, separation of field types),
with a more generalized approach that implements a more general field class that features different types.

Running address does not seem to correctly update with alinment, investigate

idk throw more exceptions and stuff, just logging critical and returning none seams lazy, rather abort and escalate

XSD and comments define access width in bytes (1, 2, 4, or 8).
Implementation and aurix example handle the access width in bits (8, 16, 32 or 64).

Test cases for CRC also use bits notation, but a CRC with swap and default access width (1) should produce an error at the moment.

This can easily be fixed, but @nhjschulz has to decide which notation is preferred

What compilers do we need to support?
Accept a new flag/arg that allows flashcontainer to be configured for different compilers?

TYPE_DATA includes info for all basic types, but could be called with GAPFILL or COMPLEX parameter types.
Access the dict through a separate function that can cast paratypes to basic types and handle special types extra.

Extra enums were introduced to ensure the provided dictionaries are only called with valid keys.
But "subclassing" Enums really hinders code readability and clarity.

Better put guards around the TYPE_DICT stuff and have one type enum

we dont have char arrays per se
do we need utf-8 fields (they are fixed length)??
can we cope with unint8_t arrays??

maybe just add nice parsing from xml and handle internally as arrayfield of uint8_t

Can loop input content to fill the array.

Have to check if this is needed or just introduces possible error