Website update: How-To Organization, Automated Landing Pages

docs/how-to/data-products.md → docs/how-to/develop/data-products.md

@@ -1,4 +1,4 @@
-# How-To: Generate Data Products
+# Generate Data Products
 
 This How-To describes **when to use data products**, **how to generate them in flight software**, **how to test them**, and provides guidance for **topology integration** and **ground decoding**. It is intended for engineers who are comfortable with F Prime components and want to add structured, store-and-forward mission data to their system.
 

docs/how-to/define-state-machines.md → docs/how-to/develop/define-state-machines.md

@@ -1,4 +1,4 @@
-# How-To: Define State Machines in F Prime
+# Define State Machines in F Prime
 
 This guide shows how to define and use state machines in F Prime using the F Prime Modeling Language (FPP). State machines help capture component behavior by modeling modes (states) and transitions explicitly, making complex logic easier to implement, test, and maintain. FPP provides autocoding capabilities to allow users to quickly implement state-defined behavior.
 

docs/how-to/develop-device-driver.md → docs/how-to/develop/develop-device-driver.md

@@ -19,7 +19,7 @@ Before starting, you should have:
 
 A "device driver" traditionally refers to the entire stack of software that manages a hardware device. In F´, the driver-manager pattern splits this in two components: the device manager component and the bus driver component. The bus driver handles the platform-specific implementation of communications on a specific bus (e.g., LinuxI2cDriver, LinuxUartDriver). The device manager handles the operations and logic for a specific device. This enhances modularity and reusability: for example the same device manager can be ported to different platforms by switching the bus driver component.
 
-Please refer to the [Application Manager Driver pattern documentation](../user-manual/design-patterns/app-man-drv.md) for more details on the design pattern used in F Prime for device drivers.
+Please refer to the [Application Manager Driver pattern documentation](../../user-manual/design-patterns/app-man-drv.md) for more details on the design pattern used in F Prime for device drivers.
 
 ### Example and reference
 
@@ -65,7 +65,7 @@ Use `fprime-util new --component` to create a new component for your device mana
 
 This component will translate device-specific operations into bus transactions. Identify the bus type (I2C, SPI, UART, etc.) and the operations needed (read, write, configure, etc.). These should be reflected in the component's ports by mirroring the bus driver's interface.
 
-For our `ImuManager` component, we are using an I2C bus, therefore we need to define ports that mirror the `Drv.I2c` interface (see [Drv/Interfaces/I2c.fpp](../../Drv/Interfaces/I2c.fpp)).  
+For our `ImuManager` component, we are using an I2C bus, therefore we need to define ports that mirror the `Drv.I2c` interface (see [Drv/Interfaces/I2c.fpp](../../../Drv/Interfaces/I2c.fpp)).  
 For example, a `Drv.I2c` component provides an ***input*** port of type `Drv.I2cWriteRead`, so we need to define an ***output*** port of that type in our component in order to connect to a bus driver component. We mirror each Bus Driver port that we need to use in our Device Manager.
 
 ```python
@@ -280,7 +280,7 @@ We learn the following:
 
 ### Step 2 - Define the Bus Driver Component
 
-Use `fprime-util new --component` to create a new component for your bus driver. The set of ports that a bus driver needs to expose depends on the bus communication protocol (I2C, SPI, UART, etc.). F Prime provides standard interfaces for common bus types in the `Drv/Interfaces/` directory. For I2C, we can use the existing `Drv.I2c` interface (see [Drv/Interfaces/I2c.fpp](../../Drv/Interfaces/I2c.fpp)).
+Use `fprime-util new --component` to create a new component for your bus driver. The set of ports that a bus driver needs to expose depends on the bus communication protocol (I2C, SPI, UART, etc.). F Prime provides standard interfaces for common bus types in the `Drv/Interfaces/` directory. For I2C, we can use the existing `Drv.I2c` interface (see [Drv/Interfaces/I2c.fpp](../../../Drv/Interfaces/I2c.fpp)).
 
 ```python
 # In: ZephyrI2cDriver.fpp
@@ -292,7 +292,7 @@ passive component ZephyrI2cDriver {
 ```
 
 > [!TIP]
-> Our I2C bus driver will only be responding to read/write requests from a device manager, therefore we define it as a `passive component` and the `Drv.I2c` ports are sufficient. If your bus driver needs to perform scheduled tasks (e.g., polling, timeouts, etc.), you may consider adding a scheduling port (`Svc.Sched`) to hook to a [Svc.RateGroup](../../Svc/ActiveRateGroup/docs/sdd.md), and potentially switching to an `active` component. `queued` components can also be used but need careful design to ensure messages are dispatched.
+> Our I2C bus driver will only be responding to read/write requests from a device manager, therefore we define it as a `passive component` and the `Drv.I2c` ports are sufficient. If your bus driver needs to perform scheduled tasks (e.g., polling, timeouts, etc.), you may consider adding a scheduling port (`Svc.Sched`) to hook to a [Svc.RateGroup](../../../Svc/ActiveRateGroup/docs/sdd.md), and potentially switching to an `active` component. `queued` components can also be used but need careful design to ensure messages are dispatched.
 
 Run `fprime-util impl` to generate the component C++, including the port handler to fill out. In our case, we will need to implement the `write`, `read`, and `writeRead` port handlers.
 
@@ -405,9 +405,9 @@ void configureTopology() {
 
 ## Additional Resources
 
-- [Application Manager Driver Pattern](../user-manual/design-patterns/app-man-drv.md)
+- [Application Manager Driver Pattern](../../user-manual/design-patterns/app-man-drv.md)
 - [fprime-sensors Repository](https://github.com/fprime-community/fprime-sensors) - A collection of ready-to-use device managers for specific devices
 - [fprime-sensors-reference Repository](https://github.com/fprime-community/fprime-sensors-reference) - Reference project that uses sensors defined in fprime-sensors
-- [F´ core Linux Bus Drivers](../../Drv/)
+- [F´ core Linux Bus Drivers](../../../Drv)
 - [fprime-zephyr package](https://github.com/fprime-community/fprime-zephyr) - F Prime support for Zephyr RTOS, including common bus drivers for Zephyr
 

docs/how-to/develop-fprime-libraries.md → docs/how-to/develop/develop-fprime-libraries.md

@@ -59,7 +59,7 @@ add_fprime_subdirectory("${CURRENT_CMAKE_LIST_DIR}/MyLibrary/MyTopology")
 
 F´ libraries share F´ code through modules. These module directories are created by `fprime-util new --component` or by hand and may include any F´ code (Components, Ports, Topologies, Data Types, etc.).  These types are made available to users of the library by ensuring that they are added to the `library.cmake` file.  The only restriction is that these component should be placed under a namespacing directory for the library (e.g. `MyLibrary`) to avoid collisions with other libraries and F´ code.
 
-Developing component, ports, topologies, etc. are the subject of our [tutorials](../tutorials/index.md).
+Developing component, ports, topologies, etc. are the subject of our [tutorials](../../tutorials/index.md).
 
 
 ## Optional: Toolchain Folder and Toolchain Files

docs/how-to/develop-subtopologies.md → docs/how-to/develop/develop-subtopologies.md

@@ -1,13 +1,13 @@
 # Develop a Subtopology
 
-Subtopologies are topologies for smaller chunks of behavior in F Prime. It allows for grouping bits of topology architecture that fit together, to then be imported into a base deployment's topology. The use case for this is seen when working with shareable components, specifically in the form of [libraries](./develop-fprime-libraries.md).
+Subtopologies are topologies for smaller chunks of behavior in F Prime. It allows for grouping bits of topology architecture that fit together, to then be imported into a base deployment's topology. The use case for this is seen when working with shareable components, specifically in the form of [libraries](develop-fprime-libraries.md).
 
 *Contents*
 1. [Subtopology Structure](#subtopology-structure)
 2. [Individual File Contents](#individual-file-contents)
     1. [Example Scenario](#example-scenario)
 3. [Integration into a "Main" Deployment](#integration-into-a-main-deployment)
-4. [Subtopology Autocoder](#the-subtopology-autocoder)
+4. [Adding Subtopology Configuration](#adding-subtopology-configuration)
 5. [Conclusion](#conclusion)
 
 ## Subtopology Structure

docs/how-to/implement-radio-manager.md → docs/how-to/develop/implement-radio-manager.md

@@ -1,6 +1,6 @@
-# How-To: Implement a Radio Manager Component
+# Implement a Radio Manager Component
 
-This guide provides step-by-step instructions for implementing a radio manager component using the [Svc.Com Communications Adapter Interface](../reference/communication-adapter-interface.md). A radio manager handles communication with radio hardware, managing both outgoing transmissions (downlink) and incoming receptions (uplink).
+This guide provides step-by-step instructions for implementing a radio manager component using the [Svc.Com Communications Adapter Interface](../../reference/communication-adapter-interface.md). A radio manager handles communication with radio hardware, managing both outgoing transmissions (downlink) and incoming receptions (uplink).
 
 ---
 
@@ -11,13 +11,13 @@ Before starting, you should have:
 - Completed the [LedBlinker Tutorial](https://fprime.jpl.nasa.gov/latest/tutorials-led-blinker/docs/led-blinker/).
 - A general understanding of [FPP component modeling](https://nasa.github.io/fpp/fpp-users-guide.html).
 - Experience creating commands, events, and telemetry in FPP.
-- Read the [Communication Adapter Interface](../reference/communication-adapter-interface.md) reference documentation.
+- Read the [Communication Adapter Interface](../../reference/communication-adapter-interface.md) reference documentation.
 
 ---
 
 ## Overview
 
-A radio manager component bridges the F´ communication stack and radio hardware. To integrate with F´ standard uplink and downlink components, the radio manager must implement the [Communications Adapter Interface](../reference/communication-adapter-interface.md).
+A radio manager component bridges the F´ communication stack and radio hardware. To integrate with F´ standard uplink and downlink components, the radio manager must implement the [Communications Adapter Interface](../../reference/communication-adapter-interface.md).
 
 A common approach is to use an intermediate driver component (e.g., `Drv.ByteStreamDriver`) to communicate with radio hardware. This provides modularity and allows the same radio manager to work across different platforms by swapping the underlying driver.
 
@@ -26,7 +26,7 @@ A common approach is to use an intermediate driver component (e.g., `Drv.ByteStr
 
 ## Step 0 - Read the Reference Documentation
 
-Before starting, read the [Communication Adapter Interface](../reference/communication-adapter-interface.md) reference documentation. This How-To Guide is essentially walking through the implementation of the interface, and much of the information we are going to cover is explained at length in the reference documentation.
+Before starting, read the [Communication Adapter Interface](../../reference/communication-adapter-interface.md) reference documentation. This How-To Guide is essentially walking through the implementation of the interface, and much of the information we are going to cover is explained at length in the reference documentation.
 
 ## Step 1 - Component Definition
 
@@ -45,7 +45,7 @@ module MyProject {
 }
 ```
 
-See [`Svc.ComStub`](../../Svc/ComStub/ComStub.fpp) for a complete reference implementation.
+See [`Svc.ComStub`](../../../Svc/ComStub/ComStub.fpp) for a complete reference implementation.
 
 ---
 
@@ -57,8 +57,8 @@ Run `fprime-util impl` to generate the component implementation files. Implement
 
 This port is receiving data from the communication stack and sending it to the hardware for outgoing communications. When done sending the data:
 
-- the input buffer **must** be returned through the `dataReturnOut` port (for memory ownership, see [Design Pattern: Return-To-Sender](../user-manual/framework/memory-management/buffer-pool.md#design-pattern-return-to-sender)) 
-- a status **must** be sent via `comStatusOut`. Only a `Fw::Success::SUCCESS` value will trigger the ComQueue to send new outgoing data. `Fw::Success::SUCCESS` is valid in three contexts: (1) at start-up to initiate data flow, (2) in response to a successful transmission, and (3) after a previous `Fw::Success::FAILURE` to indicate recovery. See [Communication Adapter Protocol](../reference/communication-adapter-interface.md#communication-adapter-protocol) for more detail.
+- the input buffer **must** be returned through the `dataReturnOut` port (for memory ownership, see [Design Pattern: Return-To-Sender](../../user-manual/framework/memory-management/buffer-pool.md#design-pattern-return-to-sender)) 
+- a status **must** be sent via `comStatusOut`. Only a `Fw::Success::SUCCESS` value will trigger the ComQueue to send new outgoing data. `Fw::Success::SUCCESS` is valid in three contexts: (1) at start-up to initiate data flow, (2) in response to a successful transmission, and (3) after a previous `Fw::Success::FAILURE` to indicate recovery. See [Communication Adapter Protocol](../../reference/communication-adapter-interface.md#communication-adapter-protocol) for more detail.
 
 **Example:**
 
@@ -116,7 +116,7 @@ void RadioManager::dataReturnIn_handler(FwIndexType portNum, Fw::Buffer& fwBuffe
 
 ### Initiate downlink data flow
 
-As detailed in the [Communication Adapter Protocol](../reference/communication-adapter-interface.md#communication-adapter-protocol), the F´ downlink stack expects to receive an initial `Fw::Success::SUCCESS` message via our Com Adapter component's `comStatusOut` port to initiate data flow. This initial SUCCESS is not in response to any data — it tells `Svc::ComQueue` that the adapter is ready to accept its first message. Similarly, after a `Fw::Success::FAILURE`, the adapter must eventually emit a recovery `Fw::Success::SUCCESS` to resume data flow. Projects may implement this as is relevant for their specific radio.
+As detailed in the [Communication Adapter Protocol](../../reference/communication-adapter-interface.md#communication-adapter-protocol), the F´ downlink stack expects to receive an initial `Fw::Success::SUCCESS` message via our Com Adapter component's `comStatusOut` port to initiate data flow. This initial SUCCESS is not in response to any data — it tells `Svc::ComQueue` that the adapter is ready to accept its first message. Similarly, after a `Fw::Success::FAILURE`, the adapter must eventually emit a recovery `Fw::Success::SUCCESS` to resume data flow. Projects may implement this as is relevant for their specific radio.
 
 In our example, we will leverage the ByteStreamDriver's `ready` port, which signals when the driver is ready to receive data.
 
@@ -129,7 +129,7 @@ void RadioManager::drvConnected_handler(const FwIndexType portNum) {
 }
 ```
 
-Refer to [`Svc.ComStub` implementation](../../Svc/ComStub/ComStub.cpp) for detailed examples of each handler
+Refer to [`Svc.ComStub` implementation](../../../Svc/ComStub/ComStub.cpp) for detailed examples of each handler
 
 
 ---
@@ -140,7 +140,7 @@ As discussed in the Overview, new deployments are by default created with a `Svc
 
 ### Remove ComStub
 
-First, we need to take out ComStub of our topology. This is done by using the `ComCcsds.FramingSubtopology` instead of the default `ComCcsds.Subtopology`. Refer to the [ComCcsds definition](../../Svc/Subtopologies/ComCcsds/ComCcsds.fpp) for more detail
+First, we need to take out ComStub of our topology. This is done by using the `ComCcsds.FramingSubtopology` instead of the default `ComCcsds.Subtopology`. Refer to the [ComCcsds definition](../../../Svc/Subtopologies/ComCcsds/ComCcsds.fpp) for more detail
 
 ```diff
   # ----------------------------------------------------------------------
@@ -228,17 +228,17 @@ void teardownTopology(const TopologyState& state) {
 
 ### Asynchronous Transmission
 
-For asynchronous byte stream drivers, use the async send ports and store the context for the callback. See [`Svc.ComStub` async implementation](../../Svc/ComStub/ComStub.cpp) for a complete example.
+For asynchronous byte stream drivers, use the async send ports and store the context for the callback. See [`Svc.ComStub` async implementation](../../../Svc/ComStub/ComStub.cpp) for a complete example.
 
 ### Retry Logic
 
-Implement retry logic for transient failures. See [`Svc.ComStub::handleSynchronousSend`](../../Svc/ComStub/ComStub.cpp) for an example with retry limits
+Implement retry logic for transient failures. See [`Svc.ComStub::handleSynchronousSend`](../../../Svc/ComStub/ComStub.cpp) for an example with retry limits
 
 ---
 
 ## Best Practices
 
-- **Follow the protocol**: Review the [Communication Adapter Protocol](../reference/communication-adapter-interface.md#communication-adapter-protocol) requirements carefully.
+- **Follow the protocol**: Review the [Communication Adapter Protocol](../../reference/communication-adapter-interface.md#communication-adapter-protocol) requirements carefully.
 
 - **Return buffers promptly**: Return ownership via `*Return*` ports immediately after transmission.
 
@@ -247,7 +247,7 @@ Implement retry logic for transient failures. See [`Svc.ComStub::handleSynchrono
 
 ## Additional Resources
 
-- Reference: [Svc.ComStub](../../Svc/ComStub/docs/sdd.md) - Com Adapter implementation passing through data from a ByteStreamDriver
+- Reference: [Svc.ComStub](../../../Svc/ComStub/docs/sdd.md) - Com Adapter implementation passing through data from a ByteStreamDriver
 - Reference: [XBeeManager](https://github.com/fprime-community/fprime-sensors/tree/devel/fprime-sensors/XBee/Components/XBeeManager) - Com Adapter implementation for a [XBee radio](https://www.digi.com/products/embedded-systems/digi-xbee/rf-modules)
-- [Communication Adapter Interface Reference](../reference/communication-adapter-interface.md) - Complete protocol specification
-- [Byte Stream Driver Model](../../Drv/ByteStreamDriverModel/docs/sdd.md) - Driver interface documentation
+- [Communication Adapter Interface Reference](../../reference/communication-adapter-interface.md) - Complete protocol specification
+- [Byte Stream Driver Model](../../../Drv/ByteStreamDriverModel/docs/sdd.md) - Driver interface documentation

docs/how-to/python-development.md → docs/how-to/develop/python-development.md

@@ -1,4 +1,4 @@
-# How-To: Develop Components in Python
+# Develop Components in Python
 
 This guide is a starting point for developing Python-based F Prime applications by constructing select components using Python.
 
@@ -15,8 +15,8 @@ For a working reference project, see the [F Prime Python Reference](https://gith
 - [Prerequisites](#prerequisites)
 - [Python in F Prime](#python-in-f-prime)
 - [Modeling](#modeling)
-- [Project Structure](#project-structure)
-- [Development Environment](#development-environment)
+- [Project Setup](#project-setup)
+- [Modeling](#modeling)
 - [Development Workflow](#development-workflow)
 - [Testing](#testing)
 - [Packaging and Distribution](#packaging-and-distribution)