• View
• Edit
• History
• Print

CFETutorial

core Flight Executive Tutorial

August 11, 2014

NASA's core Flight Executive is open source and available at code.nasa.gov. It is a framework for writing flight software for embedded systems.

Should show the layers of the system... rt-OS -> OSAL -> cFE -> Apps & Libs

The applications form a Graph of nodes communicating by passing messages. For a starting example, I am going to create two applications; one to create and publish simulated sensor data and other to receive and process the data. This gives us a small enough problem to tackle while introducing most aspects of the system.

I'll be using the pc-linux version.

Part 1: sim_sensor

Why did no one tell me about the tree program?

Need to update picture: msg.h has to be in a directory that is available to other programs.

A) Basic Setup

This is modeled after the sample_app, which has the following directories / files shown to the right. We'll follow this, but swapping "sample" for "sim_sensor" for the file names and within the files.

• for_build/Makefile - Everything build related, sets the include and load paths. Need to change value of APPTARGET, ENTRY_PT, and OBJS.
• mission_inc/sim_sensor_app_perfids.h - Sets the applications performance id (priority).
• platform_inc/sim_sensor_app_msgids.h - Each message type must have a (unique?) id.
• src/* - These are the meaty bits.
  • /sim_sense_app_events.h - Defines ids to the events that the application may receive.
  • /sim_sense_app.h - The main program's header file. Needs to at least define the entry point for the code (ENTRY_PT in the Makefile).
  • /sim_sense_app_main.c - The main program's code. Should implement your functionality here.
  • /sim_sense_app_msg.h - Defines the structures used for the messages between applications.
  • /sim_sense_app_version.h - Each application has four version numbers, defined here.

Creating 8 new files for every single new application is a pain, so I made a python script to automate it: new_app.tar.gz. It includes the python script (new_application.py), a text file for defining the name of the new application (var.table), and template files (Template/*) which are modified from the sample_app files. To use:

• Untar into your cFE apps folder.
  > tar -xvf new_app.tar
• Edit var.table to have the name of the new application you are making (three times for three different formats). These are matched to tagged locations in the template files.
• Run with:
  python new_application.py var.table

 We are going to gut a lot of this to make an even simpler working example, and then add in functionality bit by bit once we have it building.

B) Building and Running

We should now have a sim_sensor application which is identical to the sample application in all but name. Soon we will modify it for our own example setup, but for now we can make sure that our build system is working.

• in build/pc-linux, edit Makefile, adding sim_sensor_app to all of the rules that deal with sample_app.
• Next edit the apps:: rule as such
  apps:: copy_apps

          $(MAKE) -C sample_lib
          $(MAKE) -C sample_app
          $(MAKE) -C sim_sensor_app

copy_apps::

          rm -rf sim_sensor_app
          mkdir sim_sensor_app
          cp ../../apps/sim_sensor_app/fsw/for_build/* ./sim_sensor_app/
          cp ../../apps/sim_sensor_app/fsw/platform_inc/* ./inc/
          cp ../../apps/sim_sensor_app/fsw/mission_inc/* ../mission_inc/

• To build: cd ..; make; make install
• Edit cfe_es_startup.scr in build/pc-linux/exe/
  • Add the following line to the start of the file:
    CFE_APP, /cf/sim_sensor_app.so, SIM_SENSOR_AppMain, SIM_SENSOR_APP, 50, 16384, 0x0, 0;
  • Comment out the next two lines (start with CFE_APP) by pre-pending with a !. This will prevent the sample application and library from running
• run with sudo core-linux.bin

In the output, you should see a line that reads: EVS Port1 66/1/SIM_SENSOR_APP 1: Sim Sensor App Initialized. Version 1.0.0.0

This means that the new application has been loaded and initialized.

App Life

An application will only be started in cFE if

Main run loop

Cleanup

Just run with printf()s.

Pub / Sub / Messages

A simple graph with two applications and their communication.

To do anything interesting, we need to set up communication between two different applications. We will add a control application that will receive data messages from the sensor application, as well as send commands to change the mode of the sensor. This will all be done with messages, although cFE also supports events.

Messages are defined in a header which must be included in all applications that use that type (thus the `/fsw/public_inc/` directory). This header defines the data types.

Look into automating this a bit, maybe even an Interface Description Language (but that would be a lot of work).

In the SimSensor application we define the messages data, and in the main code we occasionally publish a message. To receive the message, an application must first create a "pipe" (more accurately a "queue"), which subscribes to those messages. This pipe can then be checked periodically for new messages, which cFE delivers magically.

Part 2: sim_control

To receive the data from the sensor, we can make a new application: sim_control.

Common Errors

Undefined symbol.

Name of pipe was too long.

Include error defines.