Fprime on FreeRTOS

[donwalkarsoham]

I wanted to know whether fprime is compatible with FreeRTOS operating system.
If so, is there any tutorial or reference guide on how to integrate and use fprime with FreeRTOS ?

[timcanham]

@donwalkarsoham We haven't done a port yet to FreeRTOS. I think it would be great for more deeply embedded applications. It is in our plans to write a porting guide, but we haven't gotten there yet. If you want to fork the devel branch of the repo, I could help you walk through the process. It essentially consists of providing implementations for the classes defined in the Os directory. It would be for tasks, threads, mutexes, etc.

[donwalkarsoham]

Sure, I have forked the repo to "donwalkarsoham / fprime". It would be really helpful if you could walk us through the process of porting fprime on FreeRTOS.
Thanks

[timcanham]

Can you give me a little background as to how you would like to use F'?

[timcanham]

Note that F` requires running its own build system to generate the code, so you won't be able to build through Code Composer. We have done that here at JPL with another TI MCU.

[donwalkarsoham]

This is the "Cube Rover" project for which we had an SDR presentation on 3rd August and you were a part of the reviewing committee.
We are planning to use Fprime for its publish subscribe utility to manage the various tasks of the rover from sensor readings to motor control and telemetry operation.
Also, we want the software to be modular so that any added components in the future like extra cameras or sensors can be used easily interfaced with the existing system.

Thanks for the suggestion about building Fprime. Can you please put some more light on it and help us in taking it forward ?

[timcanham]

There are a set of configuration files to navigate through. The can be a bit complicated, but they were set up that way to try and reuse settings across targets. It's actually helpful to see how the other ones in the repo were done to catch the pattern.

1. Run a build in Code Composer with a dummy hello world file so you can see what the compiler command line so we can update the compiler configuration for the build system.

2. Add a build target to:

mk/configs/builds/builds.mk

Add a name to the BUILDS that is indicative of the target name. (Maybe TIR4)

BUILDS := \
	DARWIN \
	LINUX \
	CYGWIN \
	RASPIAN \
	RASPIAN-CROSS \
        TIR4

3. Create a file in the mk/configs/builds directory that matches the target name and add the .mk extension.

TIR4.mk

4. Inside that build target configuration file, define the two variables:

COMPILER := compiler-name
TARGET := target-name

These variables are used to define variables for the compiler and target respectively.
The compiler name is used to include a file from the compiler configuration directory:

mk/configs/compiler/$(COMPILER).mk

The target variable is used to include a file from the target configuration directory:

mk/configs/target/$(TARGET).mk

5. The compiler configuration file mk/configs/compiler/$(COMPILER).mk needs to define the following variables:

CC - C compiler
CXX - C++ compiler
CFLAGS - C Compiler flags
CXXFLAGS - C++ compiler flags
COMPILE_ONLY - Generate object code, don't link (like -c on gcc)
COMPILE_TO - The destination object file (like -o on gcc)
INCLUDE_PATH - Not the include path itself, but the compiler argument to set it (like -I on gcc)
LINK_LIB - Tool to create libraries ( like ar)
LINK_LIB_FLAGS - arguments to library linker
LIBRARY_TO - argument specifying the file to create the argument (this is empty for ar)
POST_LINK_LIB - any post library linking needed (not needed for ar). If not needed, set it to: $(BUILD_ROOT)/mk/bin/empty.py
LINK_BIN - Link to an executable binary
LINK_BIN_FLAGS - Flags for binary linker
LINK_BIN_TO - flag to indicate binary output file
LIBS_START - argument to start a list of libraries, if needed
LIBS_END - argument to end a list of libraries, if needed
POST_LINK_BIN - tool that runs on binary, if necessary
POST_LINK_PRE_ARGS - arguments for post linker tool that go before binary file in tool command
POST_LINK_POST_ARGS - arguments for post linker tool that go after binary
SIZE - tool to dump file size

6. The target configuration file (mk/configs/target/$(TARGET).mk) has the following variables:

OUTPUT_DIR - output directory to put object/binary code
OBJ_PREFIX - any prefix needed for object files
OBJ_SUFFIX - any suffix needed for object files (ex. .o)

LIB_PREFIX - prefix needed for library files (ex. lib)
LIB_SUFFIX - suffix needed for library files (ex. .a)

BIN_PREFIX - prefix needed for binary files
BIN_SUFFIX - suffix needed for binary

We're working on a project using the TMS570 MCU, which is very similar to the R4. It takes a bit to tease out the Code Composer link rules. I can fork your repo and give you them, but you will have to modify them for the R4.

[timcanham]

The next step is to write implementation classes for the OS classes in the Os directory.

Specifically:

Task.hpp
Queue.hpp
Mutex.hpp
IntervalTimer.hpp
InterruptLock.hpp

The new files can be added to the OS/mod.mk file by adding the following variable:

SRC_<Target> = ....

For the name I suggested above, it would be:

SRC_TIR4 = ... ...

[lchomas]

Hi Tim. I work with Soham at CMU on this. Would be able to give us the setup you have for the TMS570? We'd like to have an example of what we need to put together. Thank you so much for all your help on this!

[timcanham]

@ichomas: If you can identify a fork I can do a pull request from, I can check it in.

[lchomas]

Soham's (@donwalkarsoham ) fork would be great. https://github.com/donwalkarsoham/fprime

[timcanham]

Why don't you make a branch for my PR?

[lchomas]

I've forked this again and made a branch for the TMS57 https://github.com/PlanetaryRobotics/fprime/tree/TMS57

[timcanham]

PR is created. Note that there are references inside to HalCoGen created files. If you haven't used HalCoGen yet, I highly recommend it.

[timcanham]

I created a new branch, feature/freertos to bring the FreeRtos port into Fprime.

[nasigoren]

Is it proceed developing to bring the FreeRTOS port into Fprime?
I'd like to use Fprime on FreeRTOS.

[jonathanmichel]

Any update concerning this port? I would be very interested in using F' on FreeRTOS. Not sure how far the development went ?

[yash-chaudhary]

Hi there, I was wondering if fprime is compatible with RTEMS real time operating system in addition to FreeRTOS.

[timcanham]

Hi there, I was wondering if fprime is compatible with RTEMS real time operating system in addition to FreeRTOS.

Yes, it is, since RTEMs has a POSIX API.
It is on our list to do a demo port at some point

[yash-chaudhary]

Awesome! We were thinking this was the case, we just wanted to confirm it. Very keen to get your FSW up and running as its going to be used in our 2nd generation cubesat.

[timcanham]

@yash-chaudhary Can you give some details on your Cubesat project? We are trying to keep a list of users.

[yash-chaudhary]

Sure thing! Just a little bit about us. We are the Melbourne Space Program (MSP) based in Melbourne, Australia. We were established in 2016 as a non-for-profit and are entirely student-run and extremely motivated to inspire more students to explore space and technology. Our teams comprise of university students that dabble in many areas of study, although mainly engineering.

In 2019, we launched a 1U cubesat called ACRUX-1 in June of 2019 on board Rocket Lab’s “Make it Rain” rocket. After a successful mission, MSP has spun-off many other STEM projects which are all developed by students which include:

• ACRUX-2 (our second generation 3U cubesat)
• Autonomous Rover (for the University Rover Challenge in Utah, USA)
• Humanoid (a robot companion to explore computer vision and bipedal motion of robots)
• SmartSat CRC (payload for natural disaster preparation, response and recovery specifically for bushfires)

You can see more details on our website: MSP

With respect to our cubesat ACRUX-2, I am personally the on-board computer (OBC) subsystem co-lead. The goal of this mission is to use machine learning diagnostics algorithms, which aims to autonomously detect damage to the spacecraft and optimise on-board operations to increase cubesat survivability. For the OBC, we are currently exploring FreeRTOS and RTEMS for our OS and JPL’s F prime and NASA cFs for our FSW. However, I think it’s safe to say we have decided to use F prime and RTEMS. Here at MSP we are fabricating all our own parts from the chassis to PCBs as this provides a richer learning experience than just using COTS, so its pretty exciting. I am more happy to talk more about this in a more private setting as I am precluded from divulging specific mission details publicly. In addition, we are building our own ground station for communications with our cubesat which will eventually connect to a network of ground-stations and we’re looking for an external payload for our satellite that may come from a research team or commercial partner. Moreover, our internal payload will be used for educational purposes to give high-school students an opportunity to explore space tech.

Here at MSP we are very keen to connect with more student space teams internationally to share our passion for space and innovation and companies such as JPL and NASA to guide us curious students to explore the beauty of space. If there is a forum such as a discord or slack we are very interested in working more closely with you guys.

[timcanham]

If you would like to talk more offline, connect with me on LinkedIn. We could arrange a teleconference to hear more about your projects.

[yash-chaudhary]

That sounds great! I'm looping in the project leads to let them know. We are also heading into end of semester exams soon, so we'll try to figure out a time that works for both of us.

[yash-chaudhary]

Hi Tim. Just wondering if you've gotten around to that FreeRTOS port. If not, do we follow the steps you've laid out above?

[Gonta01]

Hi. Are there any updates/solution on this topic?

[NabeelxKraken]

Hi @timcanham, Are there any updates on this development?

[thomas-bc]

Hi all - we are planning to release F Prime v3.5.0 in a couple weeks (see milestone). This will come with a refactored OSAL with the goal that implementing new OSALs should be much easier (clean C++ interfaces to implement as well as clean a CMake setup to integrate into).

This should help with implementing a FreeRTOS OSAL!

[matt392code]

1. Build System Configuration Files:

/mk/configs/builds/builds.mk  - Add target name
/mk/configs/builds/[TARGET].mk - Create new target file
/mk/configs/compiler/[COMPILER].mk - Compiler settings
/mk/configs/target/[TARGET].mk - Target specific settings

2. Required Compiler Variables:

• CC: C compiler path
• CXX: C++ compiler path
• CFLAGS/CXXFLAGS: Compiler flags
• COMPILE_ONLY: Object code generation flag
• COMPILE_TO: Output file specification
• INCLUDE_PATH: Include directory flags
• LINK_LIB: Library creation tool
• LINK_BIN: Binary linking tool
• Various other linking and post-processing flags

3. OS Implementation Classes:
   Must implement these key interfaces:

• Task.hpp
• Queue.hpp
• Mutex.hpp
• IntervalTimer.hpp
• InterruptLock.hpp

4. Known Integration Challenges:

• C++ Library Compatibility: Teams encountered issues with C++ standard library support
• Header File Dependencies: Careful management of system headers needed
• Compiler Version Compatibility: Some teams found success with specific versions (e.g., CCS 8.3)
• BasicTypes.hpp modifications needed for different compilers

5. Common Issues Encountered:

• Missing C/C++ libraries
• Compiler header macro issues
• Pointer casting definitions for different architectures
• Build system path configurations

6. Integration Tips from JPL:

// Example of platform-specific code handling:
#if defined BUILD_TIR5
  #define POINTER_CAST U32
#endif

#if defined BUILD_TIR5
NATIVE_INT_TYPE strnlen(const char *s, NATIVE_INT_TYPE maxlen);
#endif

7. Upcoming Improvements (v3.5.0):

• New OSAL architecture
• Cleaner C++ interfaces
• Improved CMake integration
• More straightforward OS implementation process
• Better separation of OS-specific code

8. Important Considerations:

• Need to handle hardware initialization routines
• Must consider real-time constraints
• Memory management needs special attention
• Interrupt handling requirements
• Task priority management

[NabeelxKraken]

Thank you for sharing the preliminary version of OSAL documentation. I have been facing the following issue for the past 2 weeks regarding missing Os_File implementation when I am building a Ref project for FreeRTOS on STM32 uC.
Error:
CMake Error at /home/nabeel/start/OSAL_PORT/fprime/cmake/implementation.cmake:95 (message):
-- Configuring incomplete, errors occurred!
An implementation of Os_File is required. Choose from: Os_File_Stub

Can you provide insights about what are implementation, how they are configured and how can I deal with this error. Any help would be appreciated!

[matt392code]

The Os_File interface is one of F Prime's key OS abstraction layers.
For a FreeRTOS port on STM32, you have a few options:

1. Using Os_File_Stub

• The error message mentions this as an available option
• Good for initial development/testing
• Add to your CMake config:

set(FPRIME_USE_STUBBED_DRIVERS ON)

2. Implementing Os_File Interface

• Create custom implementation for FreeRTOS/STM32
• Must implement core file operations
• Place in platform-specific directory

Basic Implementation Structure Needed:

namespace Os {
    class File {
        public:
            static Status open(const char* path, Mode mode, File& file);
            static Status read(File& file, U8* buffer, Size size, Size& size_read);
            static Status write(File& file, const U8* buffer, Size size, Size& size_written);
            static Status close(File& file);
            // ... other required methods
    };
}

For STM32/FreeRTOS, you might want to:

1. Map to SD card operations if available
2. Use internal flash memory
3. Create RAM-based virtual filesystem

[ec21b1006]

Hey @matt392code have you used fprime with freeRTOS and tried uploading on an STM board ?
I am trying to upload fprime with FreeRTOS in stm32f769.