Fix #608 - Add RTEMS 5.x support

[ghost]

Describe the contribution
Fix #608

This change adds support for RTEMS 5.1 in the OSAL.
The change provides defines and necessary ifdefs so RTEMS 4.11 can continue to be supported.

Testing performed
Following the instructions in the pc-rtems PSP:
https://github.com/nasa/PSP/blob/main/fsw/pc-rtems/README.txt
and the updated README_RTEMS_5.txt from PSP pull request 197, I built the RTEMS toolchains, the pc686 BSPs and cFS bundle for both RTEMS 4.11 and RTEMS 5.x. I then ran the bundle on both RTEMS 5.1 and RTEMS 4.11 on QEMU x86.
Note, that for RTEMS 5, the latest RTEMS 5.x git repository has to be used, since there was an RFS file system bug that prevented the bundle from working on the pc-rtems platform.

I did not run the complete set of tests yet on RTEMS 5.1.

Expected behavior changes
For RTEMS 4.11 there should be no behavior changes at all.
For RTEMS 5.1 there should be no behavior changes as well.

System(s) tested on

• Hardware: QEMU x86
• OS: RTEMS
• Versions: RTEMS 4.11 and RTEMS 5.1

Additional context
This change requires cFE Pull request 1031.
It is associated with PSP pull request 220, but since that contains readme files, it is not required to build.

Third party code
N/A

Contributor Info - All information REQUIRED for consideration of pull request
Alan Cudmore NASA/GSFC Code 582.0

[jphickey]

Good stuff! I was able to confirm the instructions and build myself an RTEMS 5 CFE system using this. So I can confirm it basically works.

However - I am still not completely comfortable with the _RTEMS_5_ ifdef. Just like on the VxWorks 7 changes it would be better for future maintenance if we can avoid this.

What I would suggest is perhaps making a "compatibility" source file that is only built on RTEMS 4.11 and provides wrappers/compatibility glue for the stuff that has been renamed or modified in RTEMS5.

Will say "approve" because this does build as is. We can discuss in CCB whether to transition to source selection here or in a follow on commit.

Note one difference from the vxworks7 stuff is that we don't have coverage tests for this. If we did, the _RTEMS_5_ macros would probably break (like they did on Vxworks7) .. so its not an immediate concern here, but still worthwhile to avoid, as we probably will want coverage test on RTEMS in the future.

[astrogeco]

CCB 20201202 - APPROVED

• Some changes to copyright notice handling