Does the FreeRTOS kernel supports execution of multiple binaries on a single uC core under control of the FreeRTOS . I am looking for something similar to a very simplistic time and space segregation solution. Sometimes also called modules or partitions. The main focus is not security. Moreover independent developing, versioning, testing and deployment of separate binaries. I am looking for something that includes the following elements:
The platform core binary:
Contains the RTOS implementation.
Contains services and all drivers.
Exports functionality usable by application logic binaries.
Can be developed, versioned, tested, deployed without compile time or runtime dependency to any application logic binary. This with the exception that during initialization time, the platform core binary detects and starts a present application logic binary. During runtime the platform core binary schedules tasks within the application logic binaries.
A application logic binary:
Contains application logic.
Has no direct access to peripherals.
Can be developed, versioned, deployed without access to source code or object code used to create the platform core binary.
Can use at runtime functionality provided by the platform binary.
Shall be replaceable within deployment. This includes: Product variant binaries, OEM binaries and end customer created binaries.
The following figure might help what we try to achieve:
Not studied your post in detail (time constraint right now) but other than the “has no direct access to peripherals” requirement, from my first read I would say this can be done. It is not the default way of using FreeRTOS though so would require some effort - restricting access to peripherals can be done too but require more effort as that can only be achieved using the memory protection unit. It would be interesting to provide an out of the box way of doing this though.
The reason I say it can be done is because years ago we put an RTOS (actually SafeRTOS) into the ROM of a chip. The application writer didn’t link to the RTOS APIs directly by compiling the source code, but indirectly through a header file that mapped API calls to known addresses in the chip’s ROM. Sort of like a jump table. The mechanism is opaque to the application writer - they still call the API functions as normal, but “linking” (not really linking in the normal sense of the word) was achieved by the preporcessor replacing the API calls with fixed addresses at which the API resided in ROM.
In your description, you want FreeRTOS to be part of loader as well. Each component has an header at the beginning which provides the loader necessary information to load the component:
The way loader discovers various components is that FLASH and RAM are pre-partitioned for each component and therefore, the starting location of each component is fixed. Here is a sample partition:
The loader is the first image that boots up and then loads all the components. The way you enable communication between components is by adding one indirection. The loader maintains a list of all the functions exported by each component. The loader has a function GetProcAddress which always resides at a fixed address and therefore, any component can all it. When a component wants to call a function exported by another component, it calls GetProcAddress to get the address of that function and then calls the function using the obtained address.
