Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Default MsgIds are not the same as historically-assigned MsgIDs #72

Closed
jphickey opened this issue Dec 12, 2023 · 0 comments · Fixed by #73
Closed

Default MsgIds are not the same as historically-assigned MsgIDs #72

jphickey opened this issue Dec 12, 2023 · 0 comments · Fixed by #73
Assignees

Comments

@jphickey
Copy link
Contributor

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.

@jphickey jphickey self-assigned this Dec 12, 2023
jphickey added a commit that referenced this issue Dec 14, 2023
Fix #72, adjust MsgId logic to match historical use
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant