Fix markdown formatting across documentation

Drv/ByteStreamDriverModel/docs/sdd.md

@@ -34,6 +34,7 @@ This status is an enumeration whose values are described in the following table:
 | ByteStreamStatus::OTHER_ERROR | Receive produced an error and buffer contains no valid data. |
 
 The following components implement the byte stream model using the synchronous interface:
+
 - [`Drv::TcpClient`](../../TcpClient/docs/sdd.md): a F´ component wrapper of the tcp client
 - [`Drv::TcpServer`](../../TcpServer/docs/sdd.md): a F´ component wrapper of the tcp server
 - [`Drv::Udp`](../../Udp/docs/sdd.md): a F´ component wrapper of the udp

Drv/LinuxUartDriver/docs/sdd.md

@@ -39,6 +39,7 @@ The component consists of the following key elements:
 ### 3.2 Send Operation
 
 When data is sent via the `send` input port:
+
 1. The component validates the file descriptor and buffer
 2. Data is written to the UART device using the Linux `write()` system call
 3. Bytes sent counter is updated for telemetry
@@ -47,6 +48,7 @@ When data is sent via the `send` input port:
 ### 3.3 Receive Operation
 
 The receive operation runs in a separate thread:
+
 1. A buffer is allocated from the buffer manager
 2. The thread blocks on `read()` waiting for incoming data
 3. Received data is packaged in the buffer and sent via `recv` output port
@@ -56,6 +58,7 @@ The receive operation runs in a separate thread:
 ### 3.4 Threading Model
 
 The component uses a single dedicated thread for receive operations (`serialReadTaskEntry`). This thread:
+
 - Runs continuously until `quitReadThread()` is called
 - Allocates buffers for each receive operation
 - Handles timeouts and errors gracefully
@@ -164,6 +167,7 @@ The receive thread can be configured with:
 ### 5.4 Events and Telemetry
 
 The component generates the following events:
+
 - **OpenError**: UART device open failures
 - **ConfigError**: UART configuration failures
 - **WriteError**: Data transmission errors
@@ -173,5 +177,6 @@ The component generates the following events:
 - **BufferTooSmall**: Insufficient buffer size
 
 The component reports the following telemetry:
+
 - **BytesSent**: Total bytes transmitted
 - **BytesRecv**: Total bytes received

Os/Generic/docs/sdd.md

@@ -3,6 +3,7 @@
 This package provides generic implementations of various OSAL modules. These are implemented using generic data structures, other OSAL types, and C++ code. These specifically avoid calls down into any underlying operating system.
 
 Available implementations:
+
 1. [Os::PriorityQueue](#ospriorityqueue)
 
 

Svc/BufferManager/docs/sdd.md

@@ -145,6 +145,7 @@ namespace Svc {
 ### 4.2 Runtime Setup
 
 To configure an instance of `BufferManager`, the following needs to be supplied to its `setup()` method:
+
 - `mgrID`: A unique manager ID for buffer checking
 - `memID`: ID passed to the memory allocator
 - `allocator`: An `Fw::MemAllocator` instance
@@ -155,6 +156,7 @@ The `setup` method configures the buffer bins, allocates memory for all buffers,
 ### 4.3 Buffer Bins Configuration
 
 Buffer bins are defined using the `BufferBins` structure, which contains an array of `BufferBin` entries. Each bin entry specifies:
+
 - `bufferSize`: The size of each buffer in the bin (in bytes)
 - `numBuffers`: number of buffers of `bufferSize` to allocate for this bin
 

Svc/ComQueue/docs/sdd.md

@@ -58,6 +58,7 @@ The diagram below shows the `Svc::ComQueue` component.
 
 ### 4.2. State
 `Svc::ComQueue` maintains the following state:
+
 1. `m_queues`: An array of `Types::Queue` used to queue per-port messages.
 2. `m_prioritizedList`: An instance of `Svc::ComQueue::QueueMetadata` storing the priority-order queue metadata.
 3. `m_state`: Instance of `Svc::ComQueue::SendState` representing the state of the component. See: 4.3.1 State Machine
@@ -81,6 +82,7 @@ Buffers are queued when in `WAITING` state.
 
 ### 4.3 Model Configuration
 `Svc::ComQueue` has the following constants, that are configured in `AcConstants.fpp`:
+
 1. `ComQueueComPorts`: number of ports of `Fw.Com` type in the `comPacketQueueIn` port array.
 2. `ComQueueBufferPorts`: number of ports of `Fw.BufferSend` type in the `bufferQueueIn` port array.
 
@@ -101,6 +103,7 @@ and an allocator of `Fw::MemAllocator`. The `configure` method foes the followin
 #### 4.5.1 bufferQueueIn
 The `bufferQueueIn` port handler receives an `Fw::Buffer` data type and a port number. 
 It does the following:
+
 1. Ensures that the port number is between zero and the value of the buffer size 
 2. Enqueue the buffer onto the `m_queues` instance 
 3. Returns a warning if `m_queues` is full
@@ -111,6 +114,7 @@ is added to the queue.
 #### 4.5.2 comPacketQueueIn
 The `comPacketQueueIn` port handler receives an `Fw::ComBuffer` data type and a port number. 
 It does the following:
+
 1. Ensures that the port number is between zero and the value of the com buffer size
 2. Enqueue the com buffer onto the `m_queues` instance
 3. Returns a warning if `m_queues` is full

Svc/ComStub/docs/sdd.md

@@ -9,6 +9,7 @@ radio manager component. The purpose of ComStub is to implement the communicatio
 to a [`Drv.ByteStreamDriver`](../../../Drv/Interfaces/docs/sdd.md) (e.g. `Drv.TcpClient` or `Drv.LinuxUartDriver`) to send and receive data.
 
 The `Svc::ComStub` is written to work with both `Drv.ByteStreamDriver` and `Drv.AsyncByteStreamDriver`. It will behave accordingly based on the connected ports:
+
 1. If `drvSendOut` is connected, it will attempt synchronous sends
 2. Else-If `drvAsyncSendOut` is connected, it will attempt asynchronous sends
 3. If neither is connected and a send operation is attempted, it will assert

Svc/FprimeDeframer/docs/sdd.md

@@ -15,6 +15,7 @@ The `Svc::FprimeDeframer` does not support deframing multiple packets in a singl
 ### Frame validation
 
 The passed-in `data` field (of type `Fw::Buffer`) of the `Svc.ComDataWithContext` input port is validated for the following conditions:
+
 - The buffer is large enough to contain the header and trailer
 - The buffer starts with the F´ start word
 - The buffer length is equal to (or larger than) the packet length field in the frame header

Svc/FprimeProtocol/docs/sdd.md

@@ -1,8 +1,9 @@
 # The F Prime communications protocol
 
-The F Prime protocol is a minimal communications protocol that is used by default in by F Prime applications. It is a protocol that is used for both uplink and downlink communications, designed to get started with the F´ GDS quickly. It does not provide any advanced features and is primarily meant for testing purposes. is used to encapsulate packets of data that are sent between the ground and the spacecraft. It is implemented on both the spacecraft and the Ground (GDS) side.
+The F Prime protocol is a minimal communications protocol that can be used in F Prime applications. It is a protocol that is used for both uplink and downlink communications, designed to get started with the F´ GDS quickly. It does not provide any advanced features and is primarily meant for testing purposes. It is used to encapsulate packets of data that are sent between the ground and the spacecraft. It is implemented on both the spacecraft and the Ground (GDS) side.
 
 A frame for F Prime protocol consists of 4 fields:
+
 - Start word: A 32-bit start word that is used to identify the start of a frame. The start word is always `0xDEADBEEF`.
 - Payload length: A 32-bit field that specifies the length of the payload data in bytes.
 - Payload data: A variable-length field that contains the payload data in the form of an [F Prime packet](../../../Fw/Com/ComPacket.hpp), of length specified by the payload length field. Note: an F Prime packet contains always at least a (configurable width) `FwPacketDescriptorType` field, which is used to identify the type of packet.

docs/how-to/custom-framing.md

@@ -9,6 +9,7 @@ Modern F´ deployments use the CCSDS protocol by default via the `Svc.ComCcsds`
 This guide demonstrates how to implement a custom framing protocol, referred to here as **MyCustomProtocol**. The protocol defines how data is wrapped (framed) for transmission and how frames are validated and unpacked (deframed) on reception. For a bi-directional framing implementation (uplink and downlink), you will need to implement both a framer and a deframer component. A framer is required for downlink (flight software → GDS). A deframer (and optionally a FrameDetector) is needed for deframing uplink messages (GDS → flight software).
 
 A reference implementation of a custom framing protocol (the "Decaf Protocol") is available in the `fprime-examples` repository:
+
 - [C++ CustomFraming Example](https://github.com/nasa/fprime-examples/tree/devel/FlightExamples/CustomFraming)
 - [GDS Plugin Example](https://github.com/nasa/fprime-examples/tree/devel/GdsExamples/gds-plugins/src/framing)
 
@@ -22,6 +23,7 @@ This guide is divided into two main sections: flight software implementation and
 **Important**: Before implementing custom framing protocols, you should familiarize yourself with F´ subtopologies. Modern F´ deployments ship with the `Svc.ComCcsds` subtopology by default, which provides a standard communication stack including framing/deframing components.
 
 To implement custom framing protocols, you will typically need to:
+
 1. **Understand the existing communication subtopology**: Review how the default `Svc.ComCcsds` subtopology is structured and integrated into your deployment
 2. **Manually import components**: Copy the relevant topology code from the subtopology into your main topology so you can modify the component connections as needed, and remove the old `import Svc.ComCcsds` statement.
 3. **Replace standard components**: Substitute the default framer/deframer components with your custom implementations
@@ -31,6 +33,7 @@ For more information on working with subtopologies, see the [Subtopologies Guide
 ## Flight Software Implementation
 
 To implement a custom framing protocol in F´, will need to implement the following:
+
 - **Framer**: An F´ component that wraps payload data into frames for transmission.
 - **Deframer**: An F´ component that unpacks received frames, extracts the payload data, and validates the frame.
 - **FrameDetector** Helper Class (optional): A C++ helper class (not an F´ component) that detects the start and end of frames in a stream of data, if your transport does not guarantee complete packets (e.g., TCP, UART).
@@ -112,6 +115,7 @@ Before implementing, consider these best practices:
 4. **Integrate Components into Your Topology**
 
     After implementing the framer, deframer, and optionally the frame detector, integrate these components into your main topology. This typically involves:
+
     - Removing the import statement for the existing communication subtopology (e.g., `import Svc.ComCcsds`).
     - Manually adding the topology code from the subtopology as needed. See [ComFprime.fpp](https://github.com/nasa/fprime/blob/devel/Svc/Subtopologies/ComFprime/ComFprime.fpp) for a reference code to add to your topology. You should be copy-pasting most of this code into your own topology, and adapt the C++ phase code as necessary.
     - Updating the `framer` and `deframer` instances to use your custom implementations.
@@ -238,7 +242,7 @@ Make sure to [package and install the plugin in your virtual environment](./deve
 fprime-gds --framing-selection MyCustomProtocol
 ```
 
-## References 
+## References
 
 - [C++ CustomFraming Example](https://github.com/nasa/fprime-examples/tree/devel/FlightExamples/CustomFraming)
 - [GDS Plugin Example](https://github.com/nasa/fprime-examples/tree/devel/GdsExamples/gds-plugins/src/framing)

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

@@ -138,6 +138,7 @@ Drv::I2cStatus ImuManager::read(ImuData& output_data) {
 ### Step 4 - Expose Behavior to Application layer
 
 Once the device-specific helper functions are implemented, integrate them into your component's behavior. For example, we can configure our ImuManager to:
+
 - a) Emit telemetry on a schedule by connecting to a RateGroup
 - b) Expose data to the application layer through additional ports
 
@@ -272,6 +273,7 @@ Before starting development, understand the bus communication protocol you are t
 In our case, we need to understand how to perform I2C read and write operations using Zephyr's I2C API. We look to the [Zephyr I2C documentation](https://docs.zephyrproject.org/latest/reference/peripherals/i2c.html) and [Zephyr I2C API](https://docs.zephyrproject.org/latest/doxygen/html/group__i2c__interface.html). It can also be useful to look at existing Zephyr code samples that use I2C.
 
 We learn the following:
+
 * Zephyr uses the [`device`](https://docs.zephyrproject.org/latest/doxygen/html/structdevice.html) struct to identify an I2C device. These can be retrieved from the Device Tree through macros (see [Zephyr Device Tree How-To](https://docs.zephyrproject.org/latest/build/dts/howtos.html)).
 * With a `device` instance, we can use the `i2c_write`, `i2c_read` and `i2c_write_read` functions to perform I2C write and read operations (see [API](https://docs.zephyrproject.org/latest/doxygen/html/group__i2c__interface.html#ga2cc5f49493dce89e128ccbfa9d6149a0)).
 

docs/how-to/develop-gds-plugins.md

@@ -71,6 +71,7 @@ classes also define a properly decorated class method for the registration funct
 methods used for CLI interaction.
 
 A basic framing plugin skeleton would thus look like:
+
 **`src/my_plugin.py`:**
 ```python
 from fprime_gds.common.communication.framing import FramerDeframer

docs/reference/fpp-json-dict.md

@@ -189,6 +189,7 @@ Example JSON of qualified name
 
 Type information for integer constant dictionary entries is determined by
 checking the sign of a constant and will always default to the maximum integer size (64 bits):
+
 - If the constant is positive, the type of the constant is U64.
 - If the constant is negative, the type of the constant is I64.
 

docs/tutorials/cross-compilation.md

@@ -221,6 +221,7 @@ Rancher Desktop is an alternative to Docker Desktop that allows users to run doc
 > Non-Macintosh users are advised to run without the below Docker container
 
 To install [Rancher Desktop](https://rancherdesktop.io/), follow the instructions for your operating system. When presented with a "Welcome to Rancher Desktop" dialog, choose the following settings:
+
 1. Disable Kubernetes
 2. Select `dockerd`
 3. Configure PATH Automatic

docs/user-manual/framework/ground-interface.md

@@ -84,6 +84,7 @@ nothing to retry.
 
 Uplink handles received data, unpacks F´ data types, and routes these to the greater F´ system. In a typical formation,
 these com buffers are sent to the command dispatcher and raw buffers are sent to the file uplink. Uplink is implemented by chaining multiple components:
+
 - a [Svc.FrameAccumulator](../../../Svc/FrameAccumulator/docs/sdd.md) component, accumulating bytes from the driver until it detects a full frame
 - a component implementing the [Svc.DeframerInterface](../../../Svc/Interfaces/docs/sdd.md) port interface to unpack the frame into F´ data types. F´ ships with implementations for various protocols:
   - [Svc.FprimeDeframer](../../../Svc/FprimeDeframer/docs/sdd.md) for the lightweight F´ protocol
@@ -94,6 +95,7 @@ these com buffers are sent to the command dispatcher and raw buffers are sent to
 
 Downlink takes in F´ data and wraps the data with bytes supporting the necessary protocol. This assembled data is then
 sent to the driver for handling. Downlink is implemented with a component implementing the [Svc.FramerInterface](../../../Svc/Interfaces/docs/sdd.md) port interface. F´ ships with implementations for two different protocols:
+
 - [Svc.FprimeFramer](../../../Svc/FprimeFramer/docs/sdd.md)
 - [Svc.Ccsds Package](../../../Svc/Ccsds) containing implementations for the CCSDS TM and Space Packet protocols
 

docs/user-manual/framework/memory-management/buffer-pool.md

@@ -138,6 +138,7 @@ Allocating more memory than available will result in buffers with size 0 being r
 buffers must be allocated and returned using the same instance of Svc.BufferManager. 
 
 Buffer manager will assert under the following conditions:
+
 1. A returned buffer has the incorrect manager ID (returned to the wrong instance).
 2. A returned buffer has an incorrect buffer ID (invalid buffer returned).
 3. A returned buffer is returned with a correct buffer ID but hasn't already been allocated.
@@ -175,6 +176,7 @@ The Svc::BufferManagerComponentImpl::BufferBins is a table specifying N buffers
 bins can be specified. The table is copied when setup() is called, so it does not need to be retained after the call.
 
 The rules for specifying bins:
+
 1. For each bin (BufferBins.bins[n]), specify the size of the buffers (bufferSize) in the bin and how many buffers for
    that bin (numBuffers).
 2. The bins must be ordered based on an increasing bufferSize to allow BufferManager to search for available buffers.

docs/user-manual/gds/gds-custom-dashboards.md

@@ -44,6 +44,7 @@ used to display our components.  HTML may be used to help the user achieve the d
 display can be configured from our custom components and thus no HTML knowledge is required.
 
 Here are some basic rules on how the layout will be displayed:
+
 - Components will stack top to bottom using 100% width, unless components are inside a `dashboard-row`
 - Components inside a `dashboard-row` will instead layout horizontally left to right.
     - If multiple components are inside a `dashboard-row` the elements will split the width. e.g. Four components each

docs/user-manual/gds/gds-dashboard-reference.md

@@ -82,6 +82,7 @@ border color. An example is shown below.
 ```
 
 `dashboard-box` supports the following properties:
+
 - `title`: A text label to give the box, appearing at the top-left corner (defaults to nothing)
 - `color`: The background color to give the box (defaults to transparent)
 - `border-color`: The color to give the border of the box (defaults to transparent)

docs/user-manual/overview/gds-introduction.md

@@ -270,6 +270,7 @@ in real time.
 ![Logs](../../img/gds_gui_logs.png)
 
 There are several standard logs that appear:
+
 - `ThreadedTCP.log`: log from the GDS middleware server linking comm to the GDS actual
 - `channel.log`: log of all channels received by the GDS
 - `command.log`: log of all commands sent by the GDS