Describe the bug
EDS uses MsgID values based on a topic ID. Although CFE uses a similar paradigm (and always has) the EDS implementation uses a different base value/pattern.
Historical pattern was to split the 11 bit APID into 8 bits topicid + 3 bits processor ID, and the latter being 0-based. Thus msgIDs become 0x18xx on CPU1, 0x19xx on CPU2, etc. up to CPU8.
EDS currently defaults to 6 bits topic ID + 5 bits processor ID, with the latter being 1-based. Although this is fine and valid, it makes it impossible to match the historical MsgID values when moving to EDS.
To Reproduce
Build mainline GSFC code and then switch to EDS.
MsgIds will be different, even if the topic IDs were defined the same way.
Expected behavior
By default, should use the same logic -- 8 bits of topic ID + 3 bits of processor ID, 0-based. This way the MsgIds should remain the same in a plain-vanilla build. The user can customize to different logic as needed.
System observed on:
Debian
Reporter Info
Joseph Hickey, Vantage Systems, Inc.
Describe the bug EDS uses MsgID values based on a topic ID. Although CFE uses a similar paradigm (and always has) the EDS implementation uses a different base value/pattern.
Historical pattern was to split the 11 bit APID into 8 bits topicid + 3 bits processor ID, and the latter being 0-based. Thus msgIDs become 0x18xx on CPU1, 0x19xx on CPU2, etc. up to CPU8.
EDS currently defaults to 6 bits topic ID + 5 bits processor ID, with the latter being 1-based. Although this is fine and valid, it makes it impossible to match the historical MsgID values when moving to EDS.
To Reproduce Build mainline GSFC code and then switch to EDS. MsgIds will be different, even if the topic IDs were defined the same way.
Expected behavior By default, should use the same logic -- 8 bits of topic ID + 3 bits of processor ID, 0-based. This way the MsgIds should remain the same in a plain-vanilla build. The user can customize to different logic as needed.
System observed on: Debian
Reporter Info Joseph Hickey, Vantage Systems, Inc.