search

nasa / SBN

37 stars 23 forks source link

remap table defaults for system HK? #14

Open CDKnightNASA opened 4 years ago

CDKnightNASA commented 4 years ago

The lazy me, when configuring multiple CPU's in the build, is to copy cpu1_msgids.h to cpu2_msgids.h and cpu3_msgids.h. But this means that all three CPU's are listening to the same system commands such as CFE_TIME_CMD_MID but these really should not transit between CPU's.

Option 1 is to just live with this behavior, as in missions folks will customize these MIDs to be unique between CPU's. Option 2 is to create a default remap table that "filters" these, but currently the remap table entries have to be specified for each CPU ID (so for a 3-CPU environment, the remap table would have 3 entries for each CMD MID.) Option 2.a. would be to alter the remap logic to allow for "wildcard CPU ID", where if the CPU ID field is "0", the remap/filter rule applies for all CPU ID's. The table is sorted and searched, so this would require two searches for every lookup instead of one. Or else the sort order should be switched to be MID + CPUID.

jphickey commented 4 years ago

This is the notion of a "Topic ID" which is a value which is fixed (compile-time) but is translated at run time depending on the CPU number it is actually running on. It provides a very useful way to allow the same binary code to be loaded onto multiple CPUs (the core apps are prime examples of this) and also send/subscribe to non-conflicting software bus Msg IDs.

CDKnightNASA commented 4 years ago

well...that and CCSDS extended headers :)

jphickey commented 4 years ago

The topic ID concept is fully implemented in the EDS branch but it is probably useful by itself, so maybe its worth backporting these functions that convert between topic ID and CFE_SB_MsgId_t values.