xtce converter doesn't support LocationInContainerInBits #285

Closed
severn opened this Issue Apr 18, 2016 · 2 comments

Comments

Projects
None yet
2 participants
@severn

severn commented Apr 18, 2016

(I removed the EnumerationAlarmLIst because this is not supported ---- do you really want me to make each unsupported xtce element an separate issue?).

Now for my 1 packet scenario I'm down to (I believe) the absolute addressing (LocationInContainerInBits) in container parameter entry.

Does the cosmos target DB support addressing its packet/container definition? (I'm poking around for documentation)

@severn

This comment has been minimized.

Show comment
Hide comment
@severn

severn May 1, 2016

The answer is that if you use the ITEM keyword, the bit offset is required. The current xtce importer however calculates this for you based on the (implied) "previous entry" and ignores/complains about any offset set explicitly in xtce using LocationInContainerInBits.

One reason I want this supported -- that is fixed absolute addressing -- is that over time we've come to put the offset in all the entries for all our xtce files that are the product of a conversion. One reason is that certain missions that shall remain nameless like to use "union" style constructs & so can have overlapping in terms of address, mnemonic definitions.

This is especially true with mnemonics that consist of lots of contiguous 1 bit flags. These may for example be 16 1-bit flag mnemonics and then in conjunction with this a "union" will be defined with a single 16-bit "all flags" mnemonics encompassing this same set of flags.

So many of our real XTCE databases have the offset set explicitly for this reason -- and so it would be a big effort to try go through and pick out these "weird" union items... to strip them out so as to generate a relative addressed "packed" entry list... which could then processed by the importer tool.

(At one time we tried to mix addressing techniques -- only supplying the fixed addresses when needed, otherwise leaving it as relative style 'packed' addressing but this proved to be confusing so it was abandoned)

severn commented May 1, 2016

The answer is that if you use the ITEM keyword, the bit offset is required. The current xtce importer however calculates this for you based on the (implied) "previous entry" and ignores/complains about any offset set explicitly in xtce using LocationInContainerInBits.

One reason I want this supported -- that is fixed absolute addressing -- is that over time we've come to put the offset in all the entries for all our xtce files that are the product of a conversion. One reason is that certain missions that shall remain nameless like to use "union" style constructs & so can have overlapping in terms of address, mnemonic definitions.

This is especially true with mnemonics that consist of lots of contiguous 1 bit flags. These may for example be 16 1-bit flag mnemonics and then in conjunction with this a "union" will be defined with a single 16-bit "all flags" mnemonics encompassing this same set of flags.

So many of our real XTCE databases have the offset set explicitly for this reason -- and so it would be a big effort to try go through and pick out these "weird" union items... to strip them out so as to generate a relative addressed "packed" entry list... which could then processed by the importer tool.

(At one time we tried to mix addressing techniques -- only supplying the fixed addresses when needed, otherwise leaving it as relative style 'packed' addressing but this proved to be confusing so it was abandoned)

ryanatball added a commit that referenced this issue May 3, 2016

@ryanatball

This comment has been minimized.

Show comment
Hide comment
@ryanatball

ryanatball May 5, 2016

Member

closed by pull request #291

Member

ryanatball commented May 5, 2016

closed by pull request #291

@ryanatball ryanatball closed this May 5, 2016

@ryanatball ryanatball modified the milestone: v3.8.1 May 12, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment