cFS portability on baremetal platforms #374
Replies: 3 comments 1 reply
-
I'm not aware of anyone who has attempted to run cFS on "baremetal". You would basically need to provide many of the capabilities an OS provides (task management, semaphores/mutexes, timers, message queues, etc) or give up/replace major functionality provided by cFS when run with an operating system. It's more common to select a configurable OS intended for embedded use and reduce it down to only what you need, and configure cFS for a minimal footprint (not actually "baremetal", but easier than writing your own). Interested to hear minimum sizes the community may have achieved if anyone wants to share. A major goal of OSAL/PSP and the new modular cFE structure is to support portability/customization. So other than the significant task of writing or assembling whatever minimum capabilities you require that are typically provided by an OS, there shouldn't be anything preventing this approach in the cFS design. Folks have completely replaced the table implementation, and it could be converted to use blocks of memory vs a file system for example. You could set up a static routing table (or use the hash implementation), build as a static image, etc. You could use a custom or alternative file system if needed (I know of a few cases where this has been done). Many of the logs and other structures can be reduced in size down to just what you need. We have had a goal of adding a minimally configured system to CI for testing, but haven't had a chance to implement yet (in the roadmap but not specifically funded/scheduled, definitely encourage/support contributions or collaboration in this area). Looks like using VxWorks on PPC based processor with the default cFS config produces about a 2 MB core image. I've flown software images in the ~220 kB range that use RTEMS (no file system, didn't use cFS). It may be possible to hit 1 MB with some work if you are OK with minimal to no margin? I'm not sure what OS would provide the smallest footprint that provides the minimum set of capabilities, @acudmore may have a better idea? |
Beta Was this translation helpful? Give feedback.
-
From @skliper:
@dmccomas it appears to me that you quickly talked to me about porting cFS to small hardware platforms but that the benefit of doing so was not compelling enough? After thinking about it, I don't remember if you said the word "baremetal," so I may have assumed it was, but I guess not. |
Beta Was this translation helpful? Give feedback.
-
The smallest cFS deployment I have done is a CubeSat with a 32 bit ARM microcontroller, 2 Megabytes of SRAM, 4 Megabytes of Flash using the FreeRTOS OS. It was not pretty, but it worked. The Code executed in flash (xip) and we had to use some hacks to fit the cFE core and a selection of apps to run in the 2MB of RAM. Some reuse apps were linked with the cFE core, and some mission apps were loaded into RAM so they could be replaced (that ended up being a good decision, because we had to replace apps during the mission) It can be done, but I would prefer to have at least 8 MB of RAM to deploy an un-modified cFS system and RTOS. |
Beta Was this translation helpful? Give feedback.
-
Hi everyone,
I'm interested in the actual portability of cFS to space hardware platforms and the products that can use it.
I'll take the liberty of providing a little context/reminder to explain my problem; I'll use shortcuts to keep it brief.
The hardware platform has a significant impact on software resources in the space environment.
The main sources of natural radiation in this environment are the planetary radiation belts (electrons and protons), the sun (protons and ions), and cosmic rays (protons and ions).
These particle emissions cause single event effects (SEE) such as upset (SEU) or latchup (SEL), some of which are classified as SEFI and can degenerate and cause failure of processors, ASICs, FPGAs, memories and other devices.
One solution is to use radiation-hardened components, which results in a hardware platform with minimal memory (a few MB).
Consider a stakeholder, a startup that provides equipment/instruments for Earth-orbiting missions as well as space exploration projects in much harsher radiation environments.
The memory resources of its equipment will vary depending on the mission and thus the different radiation environments: some software will have to run on baremetal, while others will have an operating system with a file system.
In order to reduce recurring costs and development time, the startup wants a software framework that is as portable as possible, allowing it to be used in missions with as little as one MB of memory as well as in missions with hundreds of MB.
Currently, cFS does not support baremetal, and its full capabilities would only be available in the presence of a file system. I have heard that with enough effort and a significant loss of capacity, it is possible to run cFS without a file system or operating system.
Because of this significant drawback, the startup will logically abandon the implementation of cFS in its company in favor of a more operational and suitable solution.
Does the cFS roadmap plan to address the needs of this space community, which requires the development of baremetal software systems?
Do you have any educational resources, tutorials, suggestions or best practices for running cFS on baremetal please?
Beta Was this translation helpful? Give feedback.
All reactions