Skip to content

The F Prime Book

F´ has a lot of documentation. This page is a guided reading order: each chapter introduces a set of concepts in a paragraph, then points to the existing documents that cover them. Read the chapters in order the first time through; come back later and use it as a map.

Assumed background: some knowledge of C/C++. No prior knowledge of CMake, flight software, or F´ is assumed.

How to read this book: Parts I–III are the core path and are meant for everyone, in order. Part IV is a set of independent chapters: pick the ones that match what you are building, in any order. Each Part IV chapter starts with who it is for. Links marked (reference) are for looking things up later; skim them the first time.

Check out the F´ Cheatsheet: it summarizes the core terms, component and port kinds, the fprime-util commands, and the day-to-day development workflow on two pages.

Tip

On the F´ website, use the documentation tree on the left to browse all pages, the table of contents on the right to jump to any chapter of this page, and the search bar at the top to search all of the documentation.

Part I: Getting Oriented

Chapter 1: What F´ Is

F´ is a component-based framework for flight and embedded software. A system is a set of reusable components that talk to each other only through typed ports, wired together into a topology. F´ provides the framework (threads, queues, an OS abstraction layer), a modeling language (FPP) that generates most of the boilerplate code, a library of ready-to-use flight components, and a ground data system (GDS) to command and monitor the software. Start by reading why F´ is designed this way; the rest of the book builds on that.

Chapter 2: Installing F´ and Your First Component

The fastest way to learn is to build something. The Hello World tutorial walks through installing the tools, creating a project, writing a small component, adding it to a deployment, and sending it a command from the GDS. Don't worry about understanding every step; the next chapters explain each piece.

Part II: The Building Blocks

Chapter 3: Ports, Components, and Topologies

These are the three constructs every F´ system is made of. Ports define typed interfaces; components implement behavior behind those interfaces; topologies instantiate components and connect their ports. Components come in three kinds (passive, queued, active) and ports can be synchronous or asynchronous. That choice determines which thread does the work, and it is one of the most important design decisions you will make.

Chapter 4: Commands, Events, Telemetry, Parameters, and Types

Flight software is operated from the ground: commands go up, events (log messages) and telemetry channels (periodic measurements) come down, and parameters are persisted settings that can be updated in flight. F´ supports all four directly in the component model and handles the routing for you. The data they carry is described with F´ types: fixed-width primitives plus enums, arrays, and structs defined in FPP.

Chapter 5: Modeling with FPP

FPP (F Prime Prime) is the language used to describe types, ports, components, and topologies. The FPP compiler generates the C++ base classes, the ground dictionary, and the topology setup code, so you only write the component behavior. The Math Component tutorial is a practical introduction: it defines custom types and ports, builds two components that talk to each other, adds telemetry and error handling, and writes unit tests. Afterwards, use the User's Guide to learn the language in depth and keep the spec for reference.

Chapter 6: Projects, Deployments, and the Development Process

You have now built components; this chapter zooms out. A project holds your code and configuration, and a deployment is one executable built from a topology. F´ has a recommended development process: requirements, then FPP design, implementation, unit testing, topology integration, and integration testing. The LED Blinker tutorial follows that process end to end on a more realistic component. For now, do Steps 1–7 and 9 on your development machine; Step 8 (running on hardware) is covered in Chapter 12.

Part III: Building a Complete System

Chapter 7: The Build System

F´ builds with CMake, plus a thin tool (fprime-util) that drives it. You don't need to be a CMake expert: most modules only call a single register_fprime_* function in their CMakeLists.txt. Learn how modules are registered and how settings.ini configures a project. The cheatsheet lists the fprime-util commands you will use every day, and fprime-util --help lists the rest. Toolchains and platforms come later (Chapter 13).

Chapter 8: Topologies and Subtopologies

A real deployment has dozens of component instances. F´ ships subtopologies, pre-wired groups of standard components, for command and data handling (CdhCore), communications (ComFprime / ComCcsds), and file handling. Most projects import these and connect their own components to them. Learn how instances and topologies are defined in FPP, then how to use and create subtopologies. Each standard component has a Software Design Document (SDD) describing its ports, commands, events, and behavior. Find SDDs under Reference → Software Design Documents in the navigation pane, or next to each component's source in docs/sdd.md.

Chapter 9: Scheduling, Threads, and Design Patterns

Flight software must run on time. F´ uses rate groups to call components periodically at fixed rates, and active components to move work onto their own threads. These building blocks combine into a few well-known design patterns; knowing them will make both the standard components and other projects much easier to read.

Chapter 10: The Ground Data System

The GDS is how you interact with running software during development and test: it sends commands, displays events and telemetry, transfers files, and runs sequences. It works from a browser or from the command line. The dictionary generated from your FPP model is what connects the two sides.

Chapter 11: Testing

F´ generates a test harness for every component, so unit tests can send commands, invoke ports, and check events and telemetry without a running deployment. Rule-based testing extends this to randomized sequences of actions. Integration tests then drive a full running deployment through the GDS from Python (pytest). You have already written some unit tests in the tutorials; this chapter covers the full toolset.

At this point you can design, build, test, and operate an F´ deployment on your development machine. Part IV covers specialized topics.

Part IV: Specialized Topics

Chapter 12: Running on Hardware

For: anyone deploying to an embedded target.

Running on a target means cross-compiling with the right toolchain and talking to hardware through driver components. F´ separates hardware access from application logic with the Application-Manager-Driver pattern, so most of your code stays portable and testable. Finish the hardware sections of the LED Blinker tutorial, then learn how drivers are structured. The two tutorials take different routes: LED Blinker runs on embedded Linux (such as a Raspberry Pi), while Arduino LED Blinker runs on a microcontroller without a full OS.

Chapter 13: Porting to a New Platform

For: anyone bringing F´ to an OS, RTOS, or board that isn't supported yet.

Porting F´ to a new platform involves four pieces: CMake toolchain and platform files (the compiler, build settings, and which implementations to use), platform types and configuration, drivers for the hardware, and an implementation of the OS Abstraction Layer (tasks, mutexes, files, and so on). F´ can also run without an OS.

Chapter 14: Communications

For: anyone connecting F´ to a radio, a different ground system, or a custom protocol.

Between the flight software and the ground sits a communications stack: framing and deframing, routing, queueing, and a driver for the physical link. F´ ships with an F´ protocol and a CCSDS protocol, and every layer can be replaced.

Chapter 15: Flight Services

For: anyone preparing a deployment for real operations.

The standard components cover command dispatch, event and telemetry management, parameters, time, file transfer, sequencing, and health monitoring. Most missions use them as-is. Understanding what they do (and their requirements) tells you what you get for free and what you still need to build.

Chapter 16: Memory Management and Data Products

For: anyone handling large data or needing strict memory control.

Flight software typically forbids dynamic allocation after startup. F´ allocates memory at initialization and passes large data around as buffers drawn from pre-allocated pools. Data products build on this to store and downlink bulk science or engineering data, with prioritization.

Chapter 17: Configuring and Extending F´

For: anyone tuning F´ for their mission or reusing code across projects.

Framework behavior (sizes, limits, feature flags) is set by configuration files that projects can override. Code can be packaged as F´ libraries and shared between projects, and third-party libraries can be pulled into the build. FPP also supports state machines, and components can be written in Python.

Chapter 18: Extending the Ground Data System

For: anyone customizing ground tooling or integrating another ground system.

The GDS is extensible through plugins (communication, framing, data handling, apps). The JSON dictionary generated by FPP is the interface for any other ground system.

Appendix: Where to Go Next