Is your feature request related to a problem? Please describe.
The default method of mapping topic IDs into MsgIDs works well enough, but it is not currently possible to use the exact same set of MsgID values that one would get with a baseline GSFC build (non-EDS).
The main issue is regarding the "Global" MsgID values used by CFE TIME and the fact that apps like CF and CI/TO use topicIDs that are greater than the offset of the global MsgID values.
In the baseline build, the "global" time commands get a MsgID of 0x1860 and 0x1862.
The local (normal, non-global) MsgIDs occupy the rest of the ID space, with basically no bitwise rules to identify the difference. That is, for example, ES gets 0x1806 and SAMPLE_APP gets 0x1884.
EDS attempted to put the global IDs into a different subsystem ID, such that the global time commands became 0x1F00 and 0x1F02.
Although this (arguably) makes a lot more sense, it doesn't match the traditionally-used IDs.
Describe the solution you'd like
Somehow the EDS build should be able to match this (lack of) logic.
Additional context
This is important as workflows might need a mixture of EDS and non-EDS as the tech gets refined. So EDS has to accommodate the traditional default MsgIDs, despite the lack of logic behind them.
Requester Info
Joseph Hickey, Vantage Systems, Inc.
Is your feature request related to a problem? Please describe. The default method of mapping topic IDs into MsgIDs works well enough, but it is not currently possible to use the exact same set of MsgID values that one would get with a baseline GSFC build (non-EDS).
The main issue is regarding the "Global" MsgID values used by CFE TIME and the fact that apps like CF and CI/TO use topicIDs that are greater than the offset of the global MsgID values.
In the baseline build, the "global" time commands get a MsgID of 0x1860 and 0x1862. The local (normal, non-global) MsgIDs occupy the rest of the ID space, with basically no bitwise rules to identify the difference. That is, for example, ES gets 0x1806 and SAMPLE_APP gets 0x1884.
EDS attempted to put the global IDs into a different subsystem ID, such that the global time commands became 0x1F00 and 0x1F02.
Although this (arguably) makes a lot more sense, it doesn't match the traditionally-used IDs.
Describe the solution you'd like Somehow the EDS build should be able to match this (lack of) logic.
Additional context This is important as workflows might need a mixture of EDS and non-EDS as the tech gets refined. So EDS has to accommodate the traditional default MsgIDs, despite the lack of logic behind them.
Requester Info Joseph Hickey, Vantage Systems, Inc.