severn
commented
8 years ago 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)
ghost
(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)