Fprime on FreeRTOS #7
Comments
|
@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. |
|
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. |
|
Can you give me a little background as to how you would like to use F'? |
|
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. |
|
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. Thanks for the suggestion about building Fprime. Can you please put some more light on it and help us in taking it forward ? |
|
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.
Add a name to the BUILDS := \
DARWIN \
LINUX \
CYGWIN \
RASPIAN \
RASPIAN-CROSS \
TIR4
COMPILER := compiler-name
TARGET := target-nameThese variables are used to define variables for the compiler and target respectively.
The target variable is used to include a file from the target configuration directory:
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. |
|
The next step is to write implementation classes for the OS classes in the Specifically:
The new files can be added to the For the name I suggested above, it would be: |
|
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! |
|
@ichomas: If you can identify a fork I can do a pull request from, I can check it in. |
|
Soham's (@donwalkarsoham ) fork would be great. https://github.com/donwalkarsoham/fprime |
|
Why don't you make a branch for my PR? |
|
I've forked this again and made a branch for the TMS57 https://github.com/PlanetaryRobotics/fprime/tree/TMS57 |
|
PR is created. Note that there are references inside to HalCoGen created files. If you haven't used HalCoGen yet, I highly recommend it. |
|
I created a new branch, |
|
Is it proceed developing to bring the FreeRTOS port into Fprime? |
|
I am studying FreeRTOS in preparation for a port, but I haven't done the port yet. Stay tuned... |
|
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. The error directive is printed from the following snippet in /usr/include/machine/_types.h: Though I do have sys/cdefs.h file under /usr/include, it defines The only difference is the trailing underscore. So I added a few lines to fix the issue: 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: are packed into this zip file: Can you help us take a look? What C library package do you use? |
|
@ErynQian: Can you push it to a fork, and then send me the link? It lets me look at all the files. |
|
The issue may be that it doesn't look like you are invoking the TI compiler: I would expect something like |
|
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. The C include library I'm using for TI arm compiler is: /usr/arm-linux-gnueabihf/include/ |
|
My CCS linking rules involve the following files: Can you help me take a look at them to see if they seem alright? |
|
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. |
|
I'm using this And yes, I have generated HalCoGen project. Its in my repo, under |
|
You need the headers, yes, but you also need to link to the libraries: |
|
I did. |
|
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 |
|
I changed to --c++03 and the error message says
|
|
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? |
|
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. |
|
Also did you change anything in Fw/Types/BasicTypes.hpp when using TI ARM compiler? 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? |
|
We did this on our project: |
|
Any update concerning this port? I would be very interested in using F' on FreeRTOS. Not sure how far the development went ? |
* Create tutorial-support.yml * Update tutorial-support.yml GpsApp tutorial to be pulled for build test and submodules to be pulled recursively * Implementation of tutorial workflow * typo in repo address * Added missing github action file * Changed workflow path * Changed dir paths * Work around for workflow * work around * troubleshooting * troubleshoot * troubleshoot * Performance update * Path correction * troubleshoot * Dockerfile correction * path change * path change * path fix * path fix * path fix * path fix * paht fix * Revert to changes * Completed workflow for tutorial support * troubleshoot * Build path error * Optimization of workflow * Path fix * Path fix * Path fix #1 * path fix #2 * path check * Workflow test * Workflow test #2 * Added logging feature * Logs Troubleshoot * Typo fix * Troubleshoot #1 * Troubleshoot #2 * Corrected typo on path * Troubleshoot #3 * Troubleshoot #4 * Troubleshoot #5 * Removed log archive feature * Changed repo path to conform pull request merge * Test run #1 * test #2 * test #3 * added branch for workflow test * test #4 * test #4 * test #5 * test #6 * Test #7 * test #8 * test #8 * Test #9 * Test #9 * Test #10 * Test #11 * Test #12 * Test #13 * Test #14 * Test #15 * Test #16 * Test #17 * Test #18 * Test #20 * Test #21 * Test #22 * Test #23 * Test #24 * Test #25 * Split test files * Split tests #2 * Added executable permissions * Delete RPI.bash * Delete Ref.bash * Delete Framework.bash * exe files * Make Framework.bash executable * Make RPI.bash and Ref.bash executable * Test #26 * Test #27 * Test #28 * Attached Integration test to Ref test * Test #29 * Test #30 * Test #31 * Test #32 * Test #33 * Test #34 * Test #35 * Test #35 * Test #37 * Test #38 * Test #39 * Test #40 * Test #41 * Test #42 * Test #43 * Test #43 * Test #44 * Test #45 * Cleaned up files to remove commented code * Remove CI test branch from workflow * Incorporated comments for PR * Modified path for framework job test * Incoporate reviewer comment for PR * Incoporated reviewer comment for PR * Was using incorrect directory for the test * Revised args call for jobs * Passing args #1 * Define entrypoint directly from workflow * Changed entrypoint method * Changed entrypoint method #2 * Corrected test path * Syntax correction * Path Test #1 * Path test #2 * Path Test #4 * Path Test $5 * Test Path #6 * Path Test #6 * Path Test #7 * Path Test #8 * Refactored scripts to remove master.bash * Corrected test path * Fixed log problems * Entrypoint alternative * Bypassed master.bash file * Added line for better CI error messages
|
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. |
|
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. |
|
@yash-chaudhary Can you give some details on your Cubesat project? We are trying to keep a list of users. |
|
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:
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. |
|
If you would like to talk more offline, connect with me on LinkedIn. We could arrange a teleconference to hear more about your projects. |
|
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. |
|
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? |
|
Hi. Are there any updates/solution on this topic? |
|
Hi @timcanham, Are there any updates on this development? |
|
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! |
// 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
|
|
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. 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! |
|
The Os_File interface is one of F Prime's key OS abstraction layers.
set(FPRIME_USE_STUBBED_DRIVERS ON)
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:
|
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 ?
The text was updated successfully, but these errors were encountered: