PSP Headers need a scrub/cleanup

[jphickey]

Is your feature request related to a problem? Please describe.
The cfe_psp.h header file puts its comments/description after the function declaration and does not use doxygen style. It also contains at least a few functions that are not used by CFE and also may not even be implemented

Describe the solution you'd like
Cleanup. At least fixup comments to be more readable - put before declaration and ideally also add some doxygen markup.

At least the CFE_PSP_Decompress() function appears to be not implemented at all - recommend removing this prototype.

Additional context
Other functions which are inconsistently implemented or too hardware specific to be useful, might be targets for deprecation/removal (These are not used by CFE, either):

• CFE_PSP_InitSSR() - why an init but no read/write/mount/etc? Seems like a thought that was never completed.
• CFE_PSP_Get_Timer_Tick() - note this is different than CFE_PSP_GetTimerTicksPerSecond()
• CFE_PSP_Get_Dec() - not well defined what this value really is, so not really usable in portable apps.

These are referenced but have some issues:

• CFE_PSP_GetTime() - The definition is inconsistent, sometimes it maps to a real clock and sometimes its more of an interval timer with an arbitrary wrap point, needs more info/definition at least because it is generally hard to use correctly.

Requester Info
Joseph Hickey, Vantage Systems, Inc.

[jphickey]

To further cleanup - it wouldn't hurt to split this single PSP interface into several "sub-interface" definitions:

• timer/clock access
• ram/port/eeprom access (note these are in the process of getting modularized for the implementation, but the interface/prototypes are still in cfe_psp.h)
• memory areas (reset area, cds, ramdisk, etc)
• watchdog control
• exception handling
• general system info - spacecraft/processor ID/name, version info, etc
• system control - panic/restart etc.

These should be separate sub-headers and could even become separate cmake interface libraries for more modularity.