Skip to content

Improve consistency and reduce duplication in various BSP/PSP implementations #261

@skliper

Description

@skliper

Currently in the CFE/OSAL world we have at least four different platform-specific abstraction methods, all of which basically do the same thing of getting common code to run on a different platforms. All of these provide three very basic bits of functionality, in different flavors:

  • provide a well-known entry point symbol for the platform (main, Init, etc)
  • get the system into a proper state for running the app
  • Invoke OS_Application_Startup() -- or whatever the real app entry point is
  • Do something for idle time while the app runs (a shell, or just an idle loop).
  • Shut it down when complete

Provider 1:

On the OSAL side this is provided by the "BSP". It has genppc-vxworks6.4, pc-linux, pc-rtems, sparc-vxworks6.7, sis-rtems, and mcf5235-rtems (the latter 3 are somewhat unmaintained/untested).

Provider 2:

When running Unit tests, an alternative OSAL BSP is used which has extra functionality for running the tests. The idea is that any platform capable of running applications should also be capable of running Unit tests.

Unfortunately, to avoid changing existing BSP functions, this was "cloned" and therefore this has basically morphed into a second duplicate provider of the entry point/startup/shutdown logic, because UT needs a slightly different setup from a regular app. There still is, however, a considerable amount of overlap between the "UT" BSP and the regular application BSP.

//Proposal//: These should be made into an extension of the basic OSAL BSP.

Provider 3:

The CFE PSP also provides many of the same services. On the CFE PSP repo, there are "pc-linux", "pc-rtems", and "mcp750-vxworks6.4".

These are basically extended versions of the OSAL BSP, and also provide entry point/shutdown logic, but they also do ADDITIONAL configuration that is specific to CFE before calling the CFE entry point.

//Proposal//: like the unit tests, the CFE PSP should be an extension of the OSAL BSP, not a replacement for it. The PSP already defines a CFE_PSP_Main() entry point for itself, and this can be invoked as a second-stage after OS_Application_Startup to do the additional startup tasks required for CFE.

Provider 4:

The JSC-provided unit tests residing in the osal/src/unit-tests directory contain their own platform abstractions by way of preprocessor macros and alternate header/source files. The source/header file choice is based off the _LINUX_OS_, _VXWORKS_OS_, and OSP_ARINC653 compile-time macros. In turn, this defines additional macros for platform-specific routines like sleep / logging / taskDelay, etc.

These tests are already using an entry point provided by the UT-BSP described in (2) above, the macros supplement this. The problem is that not all platforms are provided. Most notably, there is no implementation for RTEMS_OS, so these tests are currently unbuildable on PC-RTEMS.

//Proposal//: Functions like sleep/delay and other platform-specific bits should be changed from a macro to an API call provided by the UT-BSP. Logging functions are already provided by the UT-BSP. Furthermore, all the test cases should use UtAssert calls to make the output consistent with everything else.

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions