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.

[timcanham]

I am studying FreeRTOS in preparation for a port, but I haven't done the port yet. Stay tuned...

[ErynQian]

Hi Tim, I work on CubeRover Flight Software at CMU. We are ready to flash code onto Hercules, but I'm stuck at compiling issues. I was trying to compile the sample app GpsApp with armcl and ccs link rules, but the weird thing is that the compile errors are from /usr/include (my laptop is a linux machine). I'm suspecting that either I don't have the right libc package installed, or there's problems with my link rules. This is the error message: "/usr/include/machine/_types.h", line 51: fatal error #35: #error directive: this file needs sys/cdefs.h as a prerequisite error0.log

The error directive is printed from the following snippet in /usr/include/machine/_types.h: `#ifndef _SYS_CDEFSH

error this file needs sys/cdefs.h as a prerequisite

endif`

Though I do have sys/cdefs.h file under /usr/include, it defines_SYS_CDEFS_H instead of _SYS_CDEFS_H_ `#ifndef _SYS_CDEFS_H

define _SYS_CDEFS_H 1

`

The only difference is the trailing underscore. So I added a few lines to fix the issue: `#if defined(_SYS_CDEFS_H) && !defined(_SYS_CDEFSH)

define _SYS_CDEFSH

endif

` Maybe it's not a good idea to edit these default C libraries in /usr/include... I compiled again, now the compiler is complaining about stuffs undefined and invalid redeclarations.

The compiling errors are pasted into the log here: error.log

So at this point, I suspect maybe the problems are with my link rules?

My CCS linking rules, including the following files: mk/configs/build/TIR4.mk mk/configs/compiler/ccs7.0_r4_common.mk mk/configs/compiler/ccs7.0-common.mk mk/configs/compiler/ccs7.0-debug-opt.mk mk/configs/compiler/ccs7.0-debug-ut.mk mk/configs/target/cortex_r4.mk

are packed into this zip file: CCS link rules.zip

Can you help us take a look? What C library package do you use?

[timcanham]

@ErynQian: Can you push it to a fork, and then send me the link? It lets me look at all the files.

[timcanham]

The issue may be that it doesn't look like you are invoking the TI compiler:

make[1]: Entering directory '/home/erynqian/FreeRTOS_fprime/fprime/GpsApp/Top'
mkdir -p /home/erynqian/FreeRTOS_fprime/fprime/GpsApp/Top/tir4-hercules-debug-opt-ccs7.0-bin
/usr/bin/armcl -DASSERT_FILE_ID=0x50FBE2FA  -ppa -ppd=/home/erynqian/FreeRTOS_fprime/fprime/GpsApp/Top/tir4-hercules-debug-opt-ccs7.0-bin/Topology.d -g -O2 --opt_for_speed=5 --display_error_number --diag_warning=225 --diag_wrap=off --c++14 --include_path=/usr/include/ -DISF -DBUILD_TIR4  -mv7R4 --code_state=32 -me --abi=eabi --enum_type=packed -D TGT_OS_TYPE_FREERTOS_REAL -D_POSIX_C_SOURCE  -I/home/erynqian/FreeRTOS_fprime/fprime -I/home/erynqian/FreeRTOS_fprime/fprime/gtest/include -I/home/erynqian/FreeRTOS_fprime/fprime/gtest --include_path=/home/erynqian/FreeRTOS_fprime/fprime/Fw/Types/StdIntInc --include_path=/home/erynqian/FreeRTOS_fprime/fprime/R4/HAL/include -I/home/erynqian/FreeRTOS_fprime/fprime/Fw/Types/Linux -I /usr/include -I/home/erynqian/FreeRTOS_fprime/fprime/Os/FreeRTOS/FreeRTOS-Real/HAL/include -I/home/erynqian/FreeRTOS_fprime/fprime/Os/FreeRTOS/FreeRTOS-Real/HAL/source -I/home/erynqian/FreeRTOS_fprime/fprime/Os/FreeRTOS/FreeRTOS-Real/include -I/home/erynqian/FreeRTOS_fprime/fprime/Os/FreeRTOS/FreeRTOS-Real/source -I/home/erynqian/FreeRTOS_fprime/fprime/Os/FreeRTOS/FreeRTOS-Real/targetConfigs -I/home/erynqian/FreeRTOS_fprime/fprime/Os/FreeRTOS -I/home/erynqian/FreeRTOS_fprime/fprime/Os -I/home/erynqian/FreeRTOS_fprime/fprime -I/home/erynqian/FreeRTOS_fprime/fprime/Os/FreeRTOS/TraceRecorder/config -I/home/erynqian/FreeRTOS_fprime/fprime/Os/FreeRTOS/TraceRecorder/include -I/home/erynqian/FreeRTOS_fprime/fprime/Os/FreeRTOS/TraceRecorder/streamports/File/include --include_path=/home/erynqian/FreeRTOS_fprime/fprime/GpsApp/Top/  --compile_only --output_file /home/erynqian/FreeRTOS_fprime/fprime/GpsApp/Top/tir4-hercules-debug-opt-ccs7.0-bin/Topology.o /home/erynqian/FreeRTOS_fprime/fprime/GpsApp/Top/Topology.cpp

I would expect something like /opt/ti/....

[ErynQian]

I installed my armcl using ti_cgt_tms470_18.1.5.LTS_linux-x64_installer, so I guess it's still a TI compiler but without a ti directory?

Sorry for late response, I've been trying to fix it myself but still didn't get anywhere. This is my forked repo: https://github.com/ErynQian/fprime.git

The C include library I'm using for TI arm compiler is: /usr/arm-linux-gnueabihf/include/ errors.log A lot of undefined errors...

[ErynQian]

My CCS linking rules involve the following files: mk/configs/build/TIR4.mk mk/configs/compiler/ccs7.0_r4_common.mk mk/configs/compiler/ccs7.0-common.mk mk/configs/compiler/ccs7.0-debug-opt.mk mk/configs/compiler/ccs7.0-debug-ut.mk mk/configs/target/cortex_r4.mk

Can you help me take a look at them to see if they seem alright?

[timcanham]

It looks like you are missing C/C++ libraries. Also, did you generate a HalCoGen project? If you don't, even if it links, the software won't execute since it needs the HalCoGen hardware initialization routines.

[ErynQian]

I'm using this/usr/arm-linux-gnueabihf/include/ C/C++ library for TI arm compiler. Normally I would assume such debian packages are complete, esp the very basic things like memchr... Am I missing something else?

And yes, I have generated HalCoGen project. Its in my repo, under Os/FreeRTOS/FreeRTOS-Real/HAL directory.

[timcanham]

You need the headers, yes, but you also need to link to the libraries:

-l$(TI_CCS_DIR)/lib/libc.a

[ErynQian]

I did. In ccs7.0_r4_common.mk file, I linked the library as following:

LINK_LIBS :=    -l /usr/arm-linux-gnueabihf/lib/libc.a \
                $(BUILD_ROOT)/Os/FreeRTOS/FreeRTOS-Real/HAL/source/sys_link.cmd

[timcanham]

I took a second look, and my mistake. It isn't the link stage, it's the compile stage. This looks like there is some macro in the compiler header files that isn't set right so it can't find the definitions it's looking for. The only obvious thing I can see that's different is the C++ dialect. Try CCS_CXXFLAGS_COMMON := $(CCS_COMMON) --c++03 instead of your CCS_CXXFLAGS_COMMON := $(CCS_COMMON) --c++14 and see if that makes a difference.

[ErynQian]

I changed to --c++03 and the error message says error #24040-D: C++03 is no longer supported I checked the doc for TI ARM C/C++ compiler (http://www.ti.com/lit/ug/spnu151r/spnu151r.pdf). From section 1.3:

The compiler uses the C++14 version of the C++ standard. Previously, C++03 was used.

[ErynQian]

Thank you for patiently helping me with the compilation issues. Actually I'm coming over to JPL FSW workshop in June. Would it be easier if we can talk face to face? I'm now working on the FSW of CubeRover project at CMU. We are struggling with fprime development and would appreciate any insights you may have. Do you have time to meet up during June 3-5?

[timcanham]

No problem - we can talk then. I am using CCS 8.3 and the compiler that comes with it - I was having issues with 9.0. I would recommend going back to that older version.

[ErynQian]

Also did you change anything in Fw/Types/BasicTypes.hpp when using TI ARM compiler? This is a snippet from BasicTypes.hpp in nasa/fprime repo. Neither GNUC nor llvm would be defined when compiling with TI ARM compiler, so the code here would print "Unsupported compiler".

#if defined __GNUC__ || __llvm__ 

// This is used to cast pointers to integers
// when a pointer needs to be stored generically.
// In order to avoid chopping off bits,
// the integer bit size needs to match
// the pointer bit size.

#ifdef __SIZEOF_POINTER__
 #if __SIZEOF_POINTER__ == 8
  #define POINTER_CAST U64
 #elif __SIZEOF_POINTER__ == 4
  #define POINTER_CAST U32
 #elif __SIZEOF_POINTER__ == 2
  #define POINTER_CAST U16
 #else
  #define POINTER_CAST U8
 #endif
#elif __i386 == 1 // GCC 4.1.2
  #define POINTER_CAST U32
#elif __x86_64 == 1 // GCC 4.1.2
  #define POINTER_CAST U64
#elif CPU == PPC604 // VxWorks 6.7 RAD750
  #define POINTER_CAST U32
#elif CPU == SPARC
  #define POINTER_CAST U32
#else
 #error Cannot get size of pointer cast!
#endif

#else
 #error Unsupported compiler!
#endif

How did you resolve this issue? I simply hardcode it to be true. Will it cause any problems? Do I need to write something like this?

#ifdef  __TI_ARM__ 
  //do something
#endif

[timcanham]

We did this on our project:

#if defined BUILD_TIR5
  #define POINTER_CAST U32
#else

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

[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?